I know this is a long shot but...
An application that I wrote back in the 1990's has been running flawlessly all these years. At the time WC 3.0 was the version. The application was a project for the State of California which is currently being rewritten by them. But in the meantime, I need to move the application from an old windows box on a T1 line to a VM machine at Vultr.
From the WConnect folder, I double click on Setup.exe and get the error message VFP libraries can't be found. The machine has a full copy of VFP9 SP2 installed and running. So I started VFP first and then ran Setup from within VFP and got to the step where I'm asked for selecting a Web Server. The choices include IIS for NT4/5 but also offer generic ISAPI or CGI options. Any suggestion which webserver might work with a 2019 VM system?
screen shot after scrolling the list of options:
I suspect it will work. The old ISAPI extension is really the only question and I think that will still work - ISAPI hasn't changed even from way back then so it should still work on a Win2022 server.
+++ Rick ---
Just to be clear... "Generic ISAPI Web Server (manual install)" ?
Okay so I installed the generic ISAPI (manual configuration).
In this 1990's Web Connection was installed to C;\WConnect and the Temp folder was c:\Temp. At some point as I had several applications all running on the same machine, I started installing WConnect into a folder under c:\Inetpub\Websites so I could separate modifications to your code. But I never changed the temp folder for this application.
So Web Connection is in c:\Inetpub\Websites\wconnect which is where the wc.dll lives and the temp folder is c:\temp. The script map was the default ".wc".
When I try to access the site, I get hte following error:
HTTP Error 500.0 - Internal Server Error Calling GetProcAddress on ISAPI filter "C:\inetpub\Websites\Farmers\wc.dll" failed
Not sure how Application Pool needs to be setup but when I created the site, I did set the pool to 32bit and LocalSystem. But since it is ISAPI this should not matter - right?
On the c:\temp folder I added the IUSR account. I also compaired to the old server and I don't see any other permissions that were set on the c:\temp or the c:\inetpub\websites\farmers\wconnect\ folders.
Any suggestions?
You should use Internet Information Server as the configuration. Make sure the Application Pool is configured for 32 bit.
I have no idea if this will work with the old files, but it is worth a shot.
The other option is:
- Create a new project
- Copy the old application into the Process classes
You'll need to enable the compatibility Response object functionality. I suspect there will still be some breakages with the really old code, but it heavily depends on what you were doing in the code. With 3.x code this may be a tough call - because most likely you were heavily relying on the old Response class features...
+++ Rick ---
Amazing, my application that has been running since 1998 on Windows NT, then 2000, 2003, 2008 and now on 2019 on Vultr still works! Fox Rocks - but Web Connect and your support over all these years is second to none - thank you for all your years of dedication and community support!!
So what ended up working? Did the original ISAPI extension (wc.dll) from way back then still work?
+++ Rick ---
Yea, sort of... by the time I was done, wc.dll is located in the Inetpub folder. It is dated 4/3/2013 and under properties > details the file version is 5.66.0.0 while the product version is 5.50.
IIS is configured to a Mapped Handler that is pointing to Westwind.WebConnection.WebConnectionHandler,WebConnectionModule.
I'm guessing the original WC3.x code is running with updates that were made in 2008 and again in 2013 but maybe you know better based on the wc.dll version.
What is awesome, the old CGI classes for request and response still run perfectly after all these years.
Oh, I now realize during the updates over the years, I never went back and deleted all the out of date stuff. As a result trying to figure out which version and folder some of the code was located in is what caused the install to take a lot more work than it should of. I had to relearn and step the code to see where it was failing. Now I need to make the time to clean it up but since it is running making time to do that just got a lot lower on the list of things to get done.
Happy Friday!