the official landing page for my runtime installers is now www.VFPX.org This is the follow-up for the soon defunct Codeplex site.

wOOdy

-------- Ursprüngliche Nachricht -------- Von: Ted Roche tedroche@gmail.com Gesendet: Saturday, November 18, 2017 12:25 AM An: profox@leafe.com Betreff: Re: VFP9 latest service pack (9.0.0.7423)

http://www.foxpert.com/download/runtime.html

On Fri, Nov 17, 2017 at 5:40 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:

...

Installed VFP9 today on the corporate gig laptop. Trying to find the runtimes to get me to 9.0.0.7423 (the last/latest/greatest). Followed the links on https://www.berezniker.com/content/pages/visual-foxpro/vfp-90-versions.

I'm at the 9.00.0000.5815 runtime but want the 7423 to be current. (Yes, you can stop laughing now since "current" and "Visual FoxPro" haven't been in the same church in over 13 years!) lol

wOOdy's old site no longer is operational. (That's where I got them in the past.) I was on fox.wikis.com earlier which led me to the above sites.

Suggestions?

tia, --Mike

[excessive quoting removed by server]

---

Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4tSDANJUP4E2+Nt=7YkafDpG2PYR3Jc... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

On 2017-11-20 11:00, Jürgen Wondzinski wrote:

The VFP runtime installers have been on VFPX since 2014, and just have transitioned to www.VFPX.org (which will always point to the actual archives)

The current direct download link from there is https://github.com/VFPX/VFPRuntimeInstallers/blob/master/VFP9SP2RT.exe

wOOdy

Thanks to you and everyone else who helped on this. I was able to update my local dev machine to 9.0.0.7423. I wanted to update a client's installation but when I tried replacing the vfp9t.dll and vfp9r.dll, it made the installed app just throw C00000005 errors on startup. Their app was installed with Installshield (barf) back in 2009. Was hoping to upgrade them via this kind of change as I don't have access to the Installshield package.

Have a look at this message: https://leafe.com/archives/msg/492151

Tracy

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Jürgen Wondzinski Sent: Monday, November 20, 2017 11:17 AM To: profoxtech@leafe.com Subject: AW: AW: VFP9 latest service pack (9.0.0.7423)

Scan the disk for any VFP9*.dll and also the version of the MSVC*.DLLs.

-----Ursprüngliche Nachricht----- Von: ProFox [mailto:profox-bounces@leafe.com] Im Auftrag von mbsoftwaresolutions@mbsoftwaresolutions.com Gesendet: Montag, 20. November 2017 17:15 An: ProFox Email List profox@leafe.com Betreff: Re: AW: VFP9 latest service pack (9.0.0.7423)

Thanks to you and everyone else who helped on this. I was able to update my local dev machine to 9.0.0.7423. I wanted to update a client's installation but when I tried replacing the vfp9t.dll and vfp9r.dll, it made the installed app just throw C00000005 errors on startup. Their app was installed with Installshield (barf) back in 2009. Was hoping to upgrade them via this kind of change as I don't have access to the Installshield package.

Per wOOdy, check the Common Files location of Program Files for the runtime DLLs.

--

rk

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Monday, November 20, 2017 11:15 AM To: profoxtech@leafe.com Subject: Re: AW: VFP9 latest service pack (9.0.0.7423)

On 2017-11-20 11:00, Jürgen Wondzinski wrote:

The VFP runtime installers have been on VFPX since 2014, and just have transitioned to www.VFPX.org (which will always point to the actual archives)

The current direct download link from there is https://github.com/VFPX/VFPRuntimeInstallers/blob/master/VFP9SP2RT.exe

wOOdy

Thanks to you and everyone else who helped on this. I was able to update my local dev machine to 9.0.0.7423. I wanted to update a client's installation but when I tried replacing the vfp9t.dll and vfp9r.dll, it made the installed app just throw C00000005 errors on startup. Their app was installed with Installshield (barf) back in 2009. Was hoping to upgrade them via this kind of change as I don't have access to the Installshield package.

What is the directory of app not C:/Program Files (86) I hope Rgds Koen

Op ma 20 nov. 2017 om 18:02 schreef < mbsoftwaresolutions@mbsoftwaresolutions.com>

That's where I was at first. I replaced the PF(x86)\Common Files\Microsoft Shared\VFP files. Then after that failed, I put them directly in the App's folder (which I usually always do by default). No luck...C-5 errors either way.

I'm betting the problem is with a MCVCR7*.dll file mismatch perhaps.

On 2017-11-20 11:22, Richard Kaye wrote:

...

Per wOOdy, check the Common Files location of Program Files for the runtime DLLs.

--

rk

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Monday, November 20, 2017 11:15 AM To: profoxtech@leafe.com Subject: Re: AW: VFP9 latest service pack (9.0.0.7423)

On 2017-11-20 11:00, Jürgen Wondzinski wrote:

...

The VFP runtime installers have been on VFPX since 2014, and just have transitioned to www.VFPX.org (which will always point to the actual archives)

The current direct download link from there is https://github.com/VFPX/VFPRuntimeInstallers/blob/master/VFP9SP2RT.exe

wOOdy

Thanks to you and everyone else who helped on this. I was able to update my local dev machine to 9.0.0.7423. I wanted to update a client's installation but when I tried replacing the vfp9t.dll and vfp9r.dll, it made the installed app just throw C00000005 errors on startup. Their app was installed with Installshield (barf) back in 2009. Was hoping to upgrade them via this kind of change as I don't have access to the Installshield package.

[excessive quoting removed by server]

I agree with you, I do not install anything in Program Files or other Microsoft suggested locations. In fact, I've been building old school style for a while now. Where possible, I am installing all files in my own folders including avoiding installing anything in the Registry. You all will probably laugh at this strategy, but hear me out.

Yes, there is a Santa Clause and yes, I still store settings in .INI files. Here's why: I write software utilities that often have to be moved by clients either between computers or from local drives to network shares. All my data is stored in a sub-folder below the program installation folder as are all supporting files. Main program files and settings files are stored in the program installation folder, including MSVCR71.DLL and MSVCP71.DLL to support vfpcompression.fll and other elements like the VFP runtimes also stored in my main program folder. The only files I install outside of this main folder or subfolders are MSCOMCT2.OCX and MSCOMCT2.SRG which provide the Calendar popup I use (and one day when I have nothing else to do, I'll find a replacement I like and get rid of that too, but in the meantime I include an installer just for that if the user happens to move our program and need the OCX installed.)

The IT admins that I work with have told me explicitly that they love the flexibility our method of programming gives them particularly in a corporate environment where change is a given. They can move our programs by copying a single folder and updating a shortcut. They can add a new user by creating a shortcut and they can change a server or workstation out without breaking our program. AND, they can back up one folder and if there is a crash, copy that folder to a new hard drive and start running the application immediately.

I've never bought in to the whole idea of storing my stuff in someone else's environment. Laugh if you like, but it works for me and it works for my clients. Obviously, building a true Client-Server system requires different mindset since you'll need a database server, but for what I make the most money on today, my strategy works for me.

Paul H. Tarver Email: paul@tpcqpc.com

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Monday, November 20, 2017 11:20 AM To: profoxtech@leafe.com Subject: Installing in your OWN folder instead of under Program Files (was Re: AW: VFP9 latest service pack (9.0.0.7423))

On 2017-11-20 12:17, Koen Piller wrote:

What is the directory of app not C:/Program Files (86) I hope Rgds Koen

Oh hell no....I haven't deployed to Program Files for YEARS. Many here will tell you that you avoided so many M$ problems by installing in your own app folder off the root (C:\MBSS) instead of following M$'s advice. Chime in all, if you want to give an "amen" for that.

[excessive quoting removed by server]

Glad to know I'm not in the wilderness on that point! :)

Paul H. Tarver Email: paul@tpcqpc.com

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Monday, November 20, 2017 12:12 PM To: profoxtech@leafe.com Subject: Re: Installing in your OWN folder instead of under Program Files (was Re: AW: VFP9 latest service pack (9.0.0.7423))

On 2017-11-20 13:01, Paul H. Tarver wrote:

I agree with you, I do not install anything in Program Files or other Microsoft suggested locations. In fact, I've been building old school style for a while now. Where possible, I am installing all files in my own folders including avoiding installing anything in the Registry. You all will probably laugh at this strategy, but hear me out.

Yes, there is a Santa Clause and yes, I still store settings in .INI files. Here's why: I write software utilities that often have to be moved by clients either between computers or from local drives to network shares. All my data is stored in a sub-folder below the program installation folder as are all supporting files. Main program files and settings files are stored in the program installation folder, including MSVCR71.DLL and MSVCP71.DLL to support vfpcompression.fll and other elements like the VFP runtimes also stored in my main program folder. The only files I install outside of this main folder or subfolders are MSCOMCT2.OCX and MSCOMCT2.SRG which provide the Calendar popup I use (and one day when I have nothing else to do, I'll find a replacement I like and get rid of that too, but in the meantime I include an installer just for that if the user happens to move our program and need the OCX installed.)

The IT admins that I work with have told me explicitly that they love the flexibility our method of programming gives them particularly in a corporate environment where change is a given. They can move our programs by copying a single folder and updating a shortcut. They can add a new user by creating a shortcut and they can change a server or workstation out without breaking our program. AND, they can back up one folder and if there is a crash, copy that folder to a new hard drive and start running the application immediately.

I've never bought in to the whole idea of storing my stuff in someone else's environment. Laugh if you like, but it works for me and it works for my clients. Obviously, building a true Client-Server system requires different mindset since you'll need a database server, but for what I make the most money on today, my strategy works for me.

Hi Paul,

My strategy is very similar to yours. I still use INI files and they work great for the reasons you stated!

--Mike

[excessive quoting removed by server]

Hasn't anyone worked out a way to slipstream the sp's onto VFP9?