VFP 9 Runtime Engine for compiled FPW 2.6 code 4

[kit86]

I have a client who has a program written in FoxPro for Windows 2.6. I have the source code and the compiled FXP files. Can I create a Runtime engine with VFP9 to be installed on local systems and just run the current code? If I can, could someone tell me what I need to do. Thanks Kit

 

[Tore Bleken]

Sorry, but the answer is no, you can't.

 

[kit86]

Does anyone have any recommendations for my dilemma I have other versions of VFP 5 & 6. Basically they have a legacy system we need to keep going. I frequently need to fix previous coding errors or make changes. Because this is in FP Windows 2.6 it will not run on 64 Bit Windows 10. I am currently having them on a couple experimental systems run HyperV and a Win 10 32bit OS.

 

[Olaf Doschke]

You can port to VFP9, but with all disadvantages attached to it. Could be called "almost compatibility".
I never did such a port but I saw others say you have a porting assistant that either keeps the screen visually or functionally, but not both at the same time.
Perhaps you find a legacy FP2.6 kit on eBay, perhaps, to keep it at the original level. Of course, you will run in a VM with this.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

The short answer is: Yes. It is possible to build a VFP EXE from Foxpro 2.6 source code. You won't need your 2.6 FXPs for that. All you need is a copy of VFP itself on the development machine. Once you build the EXE, you can distribute it to your users, along with the required runtime files. The users won't need to install VFP.

But, although it is possible, it will look terrible, it will be hard to maintain, and you could be faced with numerous compatibility problems requiring debugging and modification of the code.

Olaf mentions the porting tools - the visual and functional versions. I tried using those when VFP was at 3.0, but I found them fairly useless, and eventually found it easier not to bother.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Mike,

okay, maybe I learn something new. So you can choose to keep all code as is. As far as I understand FPD and likely also FPW has the concept of screens and as far as I found out that's simply PRGs creating the UI with @DAY, @GET, also still available in VFP9 for downward compatibility. But I thought there was something you need to convert and can't keep as is. So the porting tools are there to help you migrate to winforms?

You can of course do that on a copy of all sources and see how you like the result, then still revert back.

FXPs won't help you as that's object code, you need the PRGs.

Things to set for compatibility:

SYS(2700,0) && turn off themes overall for VFP.
Set reportbehavior 80
set enginebehavior 70

It pays to read the help topic of the Sys(2700) function to see what the subtle difference to setting _screen.themes=.f., especially when you just read the setting with SYS(2700).

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

Olaf, the point is that virtually all of the commands and functions from foxpro 2.6x (and earlier) are sill supported in VFP, and the vast majority of them work in exactly the same way. In fact, you can even run a Foxbase program under VFP and expect it to work. I know that's right, because I once did it.

The point about visual vs. functional conversion mainly affects forms (known as screens in older versions). The functional conversion converts the old SPR files to PRGs, with all the code necessary to display the screen, retaining the original @/SAY and @/GET commands. The visual conversion actually creates a VFP form, but it puts the snippet code in a separate file; it is up to the developer to hand-modify that code and incorporate into the methods of the form.

Neither of those two processes are necessary. If you have an SPR file, it is enough to rename it to a PRG and then run it. The problem is that the old @/SAY and @/GET commands were designed for a character-based screen, and will look terrible on a modern monitor.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[kit86]

Mike & Olaf, Thank you so much. I do have FPW 2.6 & VFP9. Olaf the Code settings will help with output to the screen and I assume printing. Mike I did not know that I could just rename some of the SPR files to PRG’s. In the past I have edited them. I do have all the source code. I was brought into help back in 1995 when they got in over thier heads. It’s funny to see the source code as I documented everything including the weather Huricanes coming up the east coast to feet of snow in the winter.

 

[Olaf Doschke]

Themes is about form/screen display, yes. No pre VFP8 code could aware of themes, so this should be turned off. It helps with the most important problem of elements only showing up when you move the mouse over them.

Reportbehavior is about printing, Enginebehavior about the SQL engine, the latter setting might be totally unimportant for FPW code, as you might not use SQL at all pre 3.0

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[johngoebel]

I tested this some time ago so I may not have all the details correct...
1) You should use SET CPDIALOG OFF or VFP will add code page information to the tables. If that happens you can't open the tables is FPDOS. Not sure about FPW.
2) If VFP finds screen tables (SCT and SCX files) it will try to convert them, as Olaf mentioned. If you delete the SCT and SCX files VFP will compile the SPR files previously generated by FPW or FPDOS and the compiled APP or EXE should be functional. As everyone has mentioned it will be ugly, but can be made at least usable with the judicious use of FONT, STYLE etc. on the SAYs and GETs.

John Goebel

 

[Mike Lewis]

One other useful compatibility setting is [tt]SET STRICTDATE TO 0[/tt], to avoid posible compilation errors for ambiguous dates. You might also want to review your use of [tt]SET CENTURY[/tt], in case of any Y2K issues (although you presumably already dealt with those at some point).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[kit86]

John, Thanks for the SET CPDIALOG OFF or VFP will add code page. When I started converting things once I kept getting Add a Code Page. I do need to maintain compatiblity with FoxPro 2.5 DOS. My client run’s an SBT accounting package that this Bid System program reaches into.

I just want to thank everyone who has responded. I feel like it may be something I can do. Right now I have them all on Win 7 Pro with XP Mode VM but that is gone Jan 14, 2020 when MS kills support for Win 7 Pro. I have two test systems they use running Win 10 Pro 64 bit with Hyper V and a Win 10 pro 32 in the. VM.

 

[johngoebel]

Another possibility is to run the FPW windows app in an emulator. I have had very good success with vDos (vdos.info) running an app written in FoxPro 2.6 on a couple of 64bit Windows 7 machines.

vDos is fine for normal use but it's too slow for some administrative tasks, such as re-indexing files and building the app. I'll always keep a 32bit machine around for that.

John Goebel