An EXE - what is it really?

[Russell Campbell]

I didn't know exactly how to title this message . . . I have a small app (in
EXE form) that I use to copy files from my local drive to the network.
Basically, it will copy all files in a folder and subfolders to whereever I
point it and will only copy changed files (files where the source file is
newer than the destination file). But it craps out on some files that are
"compiled" into the EXE. For instance, one file, LOGIN.SCT, is compiled
into the EXE, but resides at C:\DEV\VISUAL\COMMON\FORMS\LOGIN.SCT. When it
tries to copy this file, it gives me an error that says "File
C:\COMMON\FORMS\LOGIN.SCT could not be found." This happens in a method
called CopyOneFile and it is passed a source file path and a destination
file path as parameters. So I have verified that the parameter tcSourceFile
contains the string C:\DEV\VISUAL\COMMON\FORMS\LOGIN.SCT at the time of the
error, yet the system says it can't find C:\COMMON\FORMS\LOGIN.SCT. This
happens on some other files, all of which are files that are compiled into
the EXE. On every other file (which is quite a lot), it never happens. I'm
thinking that the non-EXE nature of VFP EXEs is partly to blame here, hence
my subject title. However, I'm having a bit of trouble determining the
specifics. The offending line of code is:

copy file (tcSourceFile) to (tcDestinationFile)

and, as I said, at the time of the error tcSourceFile =
"C:\DEV\VISUAL\COMMON\FORMS\LOGIN.SCT".

It's a strange one. Anybody have any thoughts on this?

Thanks,

Russell Campbell

[PAul Maskens]

A VFP executable contains the loadeer for the runtime libraries, your
compiled code, and a virtual filing system that allows you to embed files in
the .EXE and access them without copying them to disk.

You're falling afoul of something wierd!

The Fox WIki says at http://fox.wikis.com/wc.dll?Wiki~VFPFileSearchPath~VFP
that it really isn't clear.
http://fox.wikis.com/wc.dll?Wiki~VisualFoxproInvocationStack gives a hint of
what might be happening.

All things considered (functions and class definitions), VFP searches :
1.. Internal commands ( if the function is not prefixed with m.) and base
classes, then
2.. User-defined class definitions cached in memory in the order they were
loaded, so long as the class definitions are still along SET CLASSLIB or SET
PROCEDURE, then
3.. If in VFP 8, a collection's default method, for example
myCollection(), then
4.. MyArray(n) array memory variable in scope.
5.. Functions and class definitions in the current .PRG, then
6.. Class definitions along SET CLASSLIB, then
7.. Functions and class definitions along SET PROCEDURE, then
8.. Functions and class definitions in the stored procedures of the
current SET DATABASE TO, then
9.. Functions and class definitions in the execution chain (call stack),
then
10.. Functions named for files bound in the app/exe, then
11.. Functions named for files in the SET DEFAULT (local) directory, then
12.. Functions named for files out along SET PATH.
13.. COM classes in the OLE registry if SET OLEOBJECT is ON
So I think for a file, your search will be in 10, then 11, then 12.
But that should only apply when the filename alone is specified and there is
ambiguity that needs to be resolved.
Once a full path to the file is passed, then that ought to bypass all of
this searching.

[Ook]

The docs are a bit lacking in information about this issue, unfortunately.
I've played with it a bit (as I'm sure you have) and found that if you are
doing COPY FILE, and if the source file is embedded into the EXE, then VFP
will use the embedded file, and ignore the file specified in the source
parameter, even if they are in different directories.

Example:

I have a form with a cmdButton that does this:

COPY FILE 'c:\temp\zort\runtime\zort.zzz' to 'h:\zort.zzz'

The file zort.zzz is embedded into the exe from c:\temp\zort\dev\zort.zzz.
The two zort.zzz files have different contents. If I do the COPY FILE above
from the EXE you would expect the runtime\zort.zzz file to end up on the H:
drive. But, surprise, VFP takes the embedded dev\zort.zzz file instead!!! It
completely ignores the path in the source file parameter, and doesn't care
if the file exists or not. It uses the embedded file.

To make matters more confusing, before it copies the embedded file, it first
verifies that the disk file that was the source of the embedded file exists.
It won't use this file, it just verifies that it exists. That is why you get
the error - it can't find the file in the path that it was embedded from,
again ignoring the path you gave it in the source parameter.

So:

1) we copy from source to destination.
2) source file is embedded into EXE
3) VFP will verify the physical existence of source file on disk, but not
actually copy it.
4) VFP will copy contents of embedded file, ignoring file specified in
source parameter.

Is this a bug? It's been a problem since VFP3 and I would not be surprised
to find that FPW did the same thing. Bug or Feature By Design, it is
extremely unreliable to use COPY FILE on any files that are embedded in the
EXE, regardless of the path.

You might want to examine some of the files that you have copied to ensure
that their contents are what you expect them to be, and not the contents of
the embedded file.

YMMV.....

"Russell Campbell" <nos...@byteme.com> wrote in message
news:45J5b.29753$Om1....@newsread2.news.atl.earthlink.net...

[Russell Campbell]

Well, I basically knew the answer as you mention, so I guess my subject
title was not the best. It was more like "what kind of weird EXEs do we
have that they do this type of thing?" It would be nice if one day we get
real EXEs out of VFP.

"PAul Maskens" <pmas...@mvps.org> wrote in message
news:e5Xh9Vwc...@TK2MSFTNGP09.phx.gbl...

[Russell Campbell]

Obviously, you've done your homework on this one. I don't remember ever
running into this issue before. I think I will use a Windows API call to do
the copy instead of VFP's COPY FILE command, since it suffers from
stupidity.

Thanks for all the info.

"Ook" <usenet@nospam@emberts.com> wrote in message
news:OPQpTZwc...@TK2MSFTNGP09.phx.gbl...

[Ook]

This really isn't an issue of having a real EXE or not. It's a bug that has
been carried over from FoxPro 2.6, and after all these years, Microsoft
still has not done anything about it.

I just spent some time playing with FoxPro 2.6, and it has the same problem.
Different versions of FoxPro may or may not give an error if the file
doesn't exist on disk, but it looks like they all will use the embedded
file, ignoring the path specified in the source file parameter.

"Russell Campbell" <nos...@byteme.com> wrote in message

news:fNM5b.23184$EW1....@newsread1.news.atl.earthlink.net...

[Russell Campbell]

Isn't the EXE is really kind of just a collection of forms, reports, menus,
etc., that is interpreted on the fly? I feel like the bug is related to the
fact that we don't have a real EXE. I'm just not sure that this would
happen if this were compiled code. You really wouldn't DO FORM <formname>
or REPORT FORM <reportname>, it would be more like a JUMP <to some address>
instruction. There would be no distinction between forms or reports or
anything else. I'm just theorizing here, so maybe I'm way off base. I've
never had the need to study the structure of the EXE in any detail . . .

"Ook" <usenet@nospam@emberts.com> wrote in message

news:uFyg1ayc...@TK2MSFTNGP10.phx.gbl...

[Ook]

I've never decompiled it...but a VFP EXE is merely the APP with a header
tacked on to make it run outside of VFP. So in that sense it's not a true
EXE. But I still think the issue here is simply buggy code, and not at all
related to how the EXE is actually formed.

I suspect that DO FORM... is translated behind the scenes to an actual
JUMP...or maybe it's not that easy, and is more complex then that? Hmm...I'm
going to get in over my head, so I'll stop guessing and maybe someone who
knows more about how the APP/EXE works can jump in and comment.

"Russell Campbell" <nos...@byteme.com> wrote in message

news:q0R5b.32762$Om1....@newsread2.news.atl.earthlink.net...