FoxPro runtime application on an OSX Server?

[Shadow38x]

We have a "legacy" application which was written for us in FoxPro 2.6 by a former employee and is running on a Windows NT Server which is getting very, very old.

We are a Mac-based design firm. Because of its age and my relative inexperience with Windows NT, I would like to dump the NT and migrate to a Mac OSX Server which I am currently setting up.

At an OSX introductory seminar, I asked about the feasibility of placing the FoxPro files on the OSX server and was told that the file structure should be compatible. I've copied the files to the server, but haven't been able to get the FoxPro application to run.

Does anyone have any experience with this sort of thing? It seems like it should be possible to do. Any help would be appreciated.

 

[rgbean]

What are you trying to run the FoxPro app on? While the data files should work just fine on any file server, the FP code can only run on a "WinTel" workstation (or one that's running an appropriate emulator). The exception to this would be if the code was developed for use under FoxBase for Mac, FPM 2.x or VFP 3.0 for Mac.

Rick

 

[Scott24x7]

Shadow38x,
If your app was a FoxPro 2.6 for Windows app, you may only need to acquire a copy of FoxPro 2.6 for MAC. I have actually taken compiled 2.6 Win (.APP) apps, put them on a Mac WITHOUT recompile!, and run the .APP. I sometimes get some *odd* screen appearances, but the code works 98%. It's then a small matter to go through, and create a bit of bracket code to handle the obscurities.

(when I say bracket code, I mean thins like:

IF _MAC
Do .... blah blah
ENDIF
*
IF _WINDOWS
Do ... blah balh
ENDIF

Usually, this is for apperance purposes only, to make window headers look correct, and that kind of thing. The only big problems I ever encountered were in reports where fonts differed, and this usually "Stretched" my reports out, but a little work resizing them under MacOS, and everything was golden....

Best Regards,
Scott

Please let me know if this has helped

 

[jschenke]

Hi Shadow38X,

I've been maintaining a cross-platform Win/Mac foxpro application for quite some time now, and it is unfortunately not as simple as running the .app on the Mac runtime.

Porting screens is the biggest issue, as they will usually not look very good -- even if you use the fonts MS provides as cross-platform, such as Arial and Courier New.
From experience, I know it's better to develop on Windows and then port to Mac, so that should cut down on the frustration ; but do expect quite some time for tweaking screen output.

As far as reports go, I hadn't been getting any decent results with the built-in transporter either. In the end, I was very happy to find an old hint somewhere on the web that described the following procedure:

COPY FILE "winrep.frx" TO "temp.frx"
COPY FILE "winrep.frt" TO "temp.frt"
USE "temp.frt"
DELETE ALL FOR platform = "MAC"
PACK && get rid of the old definitions
REPLACE ALL platform WITH "MAC"
REPLACE ALL fontface WITH "Courier" ;
FOR fontface = "Courier New"
REPLACE ALL fontface WITH "Times" ;
FOR fontface = "Times New Roman"
USE
USE "winrep.frx"
DELETE ALL FOR platform = "MAC"
PACK && get rid of the old definitions
APPEND FROM "temp.frx"

And presto, you have a Mac version of your report that isn't suffering from vertical stretching or horizontal width problems such as ****** in a numerical field when it's too narrow.

Now as far as the program files goes, most will work perfectly fine. Though you might want to tweak some programs with bracketed code the way Scott described.

Also, instead of building your own Help menu to store the 'Help' and 'Info' sections of your program, use
SET APPLEABOUT TO <the info screen program>
and
SET MACHELP TO <the help screen program>
so that your program follows the MacOS standards of the About box under the Apple menu and an application-specific menu item at the bottom of the Help menu.

A few more things to keep in mind:

- FoxPro is in no way, shape or form MacOS X native, so it will have to run in 'Classic' mode.
- Avoid FoxPro 2.5 like the plague as it _will_ bring your machine down.
- Only use the powerpc-version of the runtime or any compiled standalone applications on older machines running MacOS 7 or MacOS 8.
- On machines running MacOS 9 or MacOS X, use the 68k-version as the ppc-version _will_ bring your machine (or your 'Classic' environment) down.

Good luck,

Jan Schenkel

&quot;As we grow older, we grow both iser and more foolish at the same time.&quot; (De Rochefoucald)

 

[Shadow38x]

Sorry that I wasn't a little more clear. My goal is just to quit using the NT Server, not run the program from a Mac. The guy who originally wrote the program (no longer available for support) tried porting it to a Mac briefly and had many of the same problems you all describe and gave up.

Running the program from PC workstations is just fine for us. I've copied all of the NT server files to the OSX server, but have not been able to get the program to run from the PC workstations while accessing the OSX server.

Any ideas?

 

[jschenke]

Hi Shadow38X,

That puts things in a different light -- I've been able to get things working properly, but the headaches were quite serious

Okay, most important question, can the PCs access any other files?
If so, it could be that the path to the dbf files is hard-coded, and you may need to setup a network-drive within the PC that reflects the networked drive of the old NT machine.

Best regards,

Jan Schenkel.

 

[Shadow38x]

That is a distinct possibility. At one point, I had to remap a drive in order to avoid a similar hard-wired problem.

Yes, the PCs can see the OSX server and share files with it. Sometimes, when trying to launch the .exe file from the server, I get an &quot;invalid.exe&quot; message. Other times, I get a message asking for path names which sounds like it should take care of the problem, but after filling in the requested path information, the app still doesn't launch. I usually get an I/O error or files not found on server message.

I opened up a &quot;startup.dbf&quot; file and tried re-mapping that, but no luck. I feel like I'm getting close, but not close enough.

 

[jschenke]

The &quot;invalid .exe&quot; errors are probably due to the fact that Intel and Motorola processors use different bit-sequences to store binary information (known as the Little Endian vs Big Endian issue)

I'd suggest moving the .exe onto the client machines. Granted, it gives you version-control issues to worry about but combining that with setting the TEMP and a few other environment variables to something local, should boost performance.


Next, I'd check the source code for hard-wired references. It could very well be that one of the programs has a clause like
USE &quot;P:\DATA\SOME.DBF&quot;

My suggestion there would be to replace this kind of hard-wired references with a simple
USE SOME.DBF
and set the path environment variable to include the path to the .dbf files
PRIVATE myPath
myPath = SET('PATH')+&quot;;&quot;+&quot;P:\DATA\&quot;
SET PATH TO &myPath
If you find the time, you might change the program to fetch this path from a datafile.


Of course it's difficult to give exact solutions without access to the source code -- but we're always there to give as many hints as we can


Best regards,

Jan Schenkel.