DOS Programs not Starting

[P1]

A recent 'improvement' M$ made memory management is causing DOS programs to abort. 

Known OSes affected:  W2KSP4, WXPSP2

The quick and dirty way to get around this is to create a shortcut and check "Run in separate memory space".

If this helps you, please come back and document it for the rest of us.

Addendum:  CREATE_SEPARATE_WOW_VDM must be added for CreateProcess to work properly now with memory management change.
This change broke working code using only NORMAL_PRIORITY_CLASS.

Regards,  P1   :8)

[MichaelW]

Is there any indication of what sort of DOS programs have this problem? Under Windows 2000 SP4 I have had problems running a few DOS programs that used to run OK under earlier versions of Windows, but I never bothered to keep track of which programs. Under Windows 2000, in the properties for a DOS program, I cannot find anything resembling a "Run in separate memory space" option.

[japheth]

The OP's remarks are rather confusing, since under XP, starting a DOS program will always run it "in separate memory space". Only Win16 programs can share a space and can optionally run in a separate one.

[P1]

Under Windows 2000, in the properties for a DOS program, I cannot find anything resembling a "Run in separate memory space" option.

It's under the shortcut tab.  Or maybe you do not have the update yet?

I run M$ Update as always and my DOS stuff starts giving me problems.  From Links and from CreateProcess now.

The DOS programs that 'went' dead on a shortcut ( It's least at three years old ) need the checkbox option on now.  So far, this has been observed for W2K only.

We have an old application in M$ Access II, with issues, that are worked around in assembly ( prevent two copies from running at once ).  This is where the CreateProcess issue was discovered.

These are work arounds, not explainations.

Regards,  P1   :8)

[P1]

The OP's remarks are rather confusing, since under XP, starting a DOS program will always run it "in separate memory space". Only Win16 programs can share a space and can optionally run in a separate one.

Yes, I understand I did not clarify which behavior was associate to which OS.

Link problem was apparent on W2KSP4.  Have not seen it for XP.

The CreateProcess issue showed up on Both OSes.  Which broke existing code that I support.  Which started this Hunt for Red July.

This flag is only valid only launching a 16-bit Windows program.  If set, the new process is run in a private Virtual DOS Machine (VDM).  By default, all 16-bit Windows programs are run in a single, shared VDM.  The advantage of running separately is that a crash only kills the single VDM; any other programs running in distinct VDMs continue to function normally.  Also, 16-bit Windows applications which are run in separate VDMs have separate input queues. That means that if one application hangs momentarily, applications in separate VDMs continue to receive input.

I have no detailed explaination for why the production code stopped working.  Only to associated it to a M$ Update I did for the affected workstations.

Regards,  P1   :8)

[P1]

One good thing from this.  I no longer have problems running M$ Access II runtime on a machine with 1GB of memory.

Regards,  P1  :8)