Very Computer

Recently I updated my computer operating system from Win 95 to Windows NT
4.0 -
Microsoft's latest and greatest offering for the desktop.  Most things seem
to work well under
NT 4.0 with one very critical failure or oversight.  That pertains to
creating distribution disks
on a FoxPro for Windows 2.6 application.

The known problem according to Microsoft Knowledge Base article Q103032 -
"PRB: RUN/!
Command Failed with Windows NT", states that using the RUN command without
the /N
parameter FoxPro stops execution until the RUN command completes and the
MS-DOS
session is closed.  The article goes on to say that "because Windows NT is
a preemptive
multitasking operating system, it switches control back and forth between
FoxPro and the
RUN command.  This can cause FoxPro to time out while it is waiting for the
RUN command
to complete."  

The very critical piece to this as far as I am concerned is highlighted and
states:

        NOTE:  This problem affects the SetupWizard in the FoxPro Distribution
Kit, which also
        uses a RUN command, causing it to fail at the point where compression
starts.

Is there any solution to this problem?  I hate to call Microsoft and pay
$95 for a problem
they know about but have not fixed.  Microsoft needs to realize that not
everyone, especially
clients purchasing custom software, have the hardware required for their
latest releases.

Microsoft appears to be acting like a modern day Hitler trying to not only
kill FoxPro, but
also small scale developers wishing to stay on top of technology and
supporting their
clients not having the latest and greatest hardware requirements.

{ The known problem according to Microsoft Knowledge Base article
{ Q103032 - "PRB: RUN/! Command Failed with Windows NT", states that
{ using the RUN command without the /N parameter FoxPro stops execution
{ until the RUN command completes and the MS-DOS session is closed.
{ The article goes on to say that "because Windows NT is a preemptive
{ multitasking operating system, it switches control back and forth
{ between FoxPro and the RUN command.  This can cause FoxPro to time
{ out while it is waiting for the RUN command to complete."  

{ The very critical piece to this as far as I am concerned is
{ highlighted and states:

{ NOTE:  This problem affects the SetupWizard in the FoxPro Distribution
{ Kit, which also uses a RUN command, causing it to fail at the point
{ where compression starts.

Tom,

Well that really sucks!  Here's a hairy work-around, it's not pretty, but
it should work.
You can compress the files yourself (in a separate DOS session) using the
DOS "Compress.exe" command, which is exactly what the Setup Wizard uses.
Use the command line:
COMPRESS.EXE -a2 -be -f -l -z2847 <SourcePath\Filename.ext>
<TargetPath\Filename.ex$>
Change the "-a2" to "-a3" for a *slightly* smaller compressed file, but at
the expense of a much greater compression time.  The "-z2847" parameter is
optimized for 1.4M diskettes, (2847 * 512 = 1,457,664).  This determines
the largest chunk that COMPRESS will split your files into.  If you are
using a different distribution medium, adjust the "-z" parameter
accordingly, by telling it how many 512 byte units to put in the largest
chunk.  The easiest way to compress a series of files would be to write
out a batch file with one line for each file that needs to be compressed.

Once you've done that, put all your compressed files into the "Compress"
subdirectory under the directory that holds your distribution set.  They
will have a date/time stamp identical to their source files, and when you
run the Setup Wizard it will not try to compress any files that are
already compressed, unless they have an older date/time stamp than their
respective source files.

Now this is what I would call a "Kludge" <g>, hopefully it will be of some
help.

Ralph Morse

=====================

=====================

: Recently I updated my computer operating system from Win 95 to Windows
: NT 4.0 - Microsoft's latest and greatest offering for the desktop.

[snip]

: The known problem according to Microsoft Knowledge Base article Q103032 -
: "PRB: RUN/!  Command Failed with Windows NT", states that using the
: RUN command without the /N parameter FoxPro stops execution until the
: RUN command completes and the MS-DOS session is closed.  The article
: goes on to say that "because Windows NT is a preemptive multitasking
: operating system, it switches control back and forth between FoxPro
: and the RUN command.  This can cause FoxPro to time out while it is
: waiting for the RUN command to complete."  
:
: The very critical piece to this as far as I am concerned is highlighted
: and states:
:
: NOTE:  This problem affects the SetupWizard in the FoxPro
: Distribution Kit, which also uses a RUN command, causing it to fail
: at the point where compression starts.

Hmm, I don't know about /N doing any of that.  (Doesn't the /N allow
you to set aside memory?  I was unaware of any synch/asynch side
effects.)  The problem is more like the wizard assumes that it'll be
suspended until the RUN compress finishes.  Which is true in Win3.1,
(and 95?)  Under NT (or OS/2) it's not true.  Compress starts up in
it's own little dos box and Fox keeps right on going.

: Is there any solution to this problem?  I hate to call Microsoft and
: pay $95 for a problem they know about but have not fixed.  

I'm sure they know about it.  I doubt they'll "fix" it.  

:                                                            Microsoft
: needs to realize that not everyone, especially clients purchasing
: custom software, have the hardware required for their latest releases.
:
: Microsoft appears to be acting like a modern day Hitler trying to not
: only kill FoxPro, but also small scale developers wishing to stay on
: top of technology and supporting their clients not having the latest
: and greatest hardware requirements.

I won't address Microsoft's plans for world domination here.  This is
comp.databases.xbase.fox not alt.destroy.microsoft :)  But, to be
fair, let's face it, Fox2.6 is obsolete.  MS is spending their money
and developer time on VFP.  It's unreasonable to expect them to put
out a new version of an obsoleted product.  It matters not that there
is still a market for it nor that a lot of us would really like to
see even a *final* 2.7  If you (and I) need to continue using an
obsolete product, we do so knowing that there will not be any fixes.
The up side is, we know already what (most of) the bugs are and how
to avoid them :)

NT (and in my case, OS/2) are working exactly as they should, walking
and chewing at the same time.  The "solution" to your problem is to
hack your DKWIZARD\DKSETUP.PRG

What you need to do is add an \echo Yup>FINISHED.FLG at the end of the
places where it's building bat files to RUN.  (If I recall correctly
there's only about three or four spots but it's a tad messy in there.)

Then change the RUN blah commands to DO RUNIT WITH blah and wrap
your runs with something like this:

proc RUNIT
para cmd
dele file FINISHED.FLG
run &cmd
do while !file("FINISHED.FLG")
   wait wind 'Waiting for bat to finish...' time 1
enddo

This'll make Mr Wizard stop walking until compress finishes chewing.

Sorry, If I still had the code I hacked, I'd send it to you.