How to prevent Windows ME from suggesting MS-DOS mode?

[Kahenraz]

Windows 95 and 98 have a tick box to uncheck "Suggest MS-DOS mode as necessary" in the Advanced properties of DOS programs, but this option does not appear in Windows ME. Without it, Windows suspends some DOS applications when they are run with this annoying popup. There is a delay when dropping back to Windows, having to close the dialog, then select the window and set it back to full screen. This is particularly tedious if I have both hands on the keyboard as dismissing the dialog and selecting the Window is best done with the mouse.

Is there any way to restore this functionality to stop the dialog from appearing?

I happen to like the additional features that Windows ME provides over Windows 98, and would prefer to use it instead. The limiting factor is that I also want to run a lot of DOS programs, and this popup is infuriatingly annoying.

 

This is a follow-up on a topic with the same title that I made on the VOGONS forum:

https://www.vogons.org/viewtopic.php?f=46&t=86873

Edited July 3, 2022 by Kahenraz

[jumper]

You're running in full-screen and don't want to be interrupted by Windows, so for best performance you should be in MS-DOS mode.

1. Don't dismiss the dialog! Run the wizard to create a new shortcut.

2. Use the other tabs to set better options.

3. Install a program that will click the buttons for you.

4. Use a different VM to run the more challenging DOS programs.

 

[Kahenraz]

This is not an issue with all DOS games, only some. And it's the behavior of the OS that is deciding what is best for performance when in reality my hardware is more than capable.

 

1. The wizard cannot create a shortcut that is capable of avoiding this dialog in Windows ME.

2. There are no options exposed in Windows ME that are "better" -- note that there are LESS options than Windows 98, where this dialog COULD be avoided.

3. The problem isn't clicking buttons but the process and delay of the window changing focus and minimizing, the annoying dialog popup, dismissing and then reestablishing focus. The entire screen, program, and desktop will blink and it's very unpleasant, laggy, and would confusing for guests, even if it were automated.

4. This is running on native hardware. The program is not challenging and there is no VM. The problem is the missing option since Windows 98 where this dialog could be suppressed.

 

Edited July 5, 2022 by Kahenraz

[jaclaz]

AFAICR, the properties you are setting are connected to .pif files.

They are like the least documented MS files ever, the only document I ever found that deals with them is here (via Wayback Machine):

https://web.archive.org/web/20220214185118/http://www.smsoft.ru/en/pifdoc.htm

(no reference to what works in ME, though).

There could be two possibilities:

1) the ME simply does not respect/read/parse the setting in the .pif file
2) the ME respects/reads/parses the setting correctly BUT the editing interface misses the setting

Of course if it is the 1st case there is very little that can be done, but if it is the 2nd there may be ways.

Have you tried creating the .pif in Windows 98 and then trying running it unmodified in ME? ( you would need another system or a VM runnning 98)

Or creating a "same" ..pif under 98 and under ME and compare the actual files to see if there are differences (and if they are in the relevant areas according to the provided doc)?

jaclaz

[RainyShadow]

Look for a "MS-DOS Prompt" or "COMMAND.COM" shortcut somewhere in the Windows folder. It contains the default settings for DOS programs. 

Change that option there and test again. 

 

If the properties dialog for that shortcut lack this option (as Jaclaz suggested), or the shortcut itself is missing, you can try to copy one from a Win98 system and see how that works. 

 

P.S.

If i remember correctly, the Target field contained only the executable name without a path - try to keep it this way.

[RainyShadow]

OK, the option is indeed missing in WinME: 

https://i.imgur.com/DjK200x.png

 

Here, the Win98 file with that setting disabled dosprmpt.zip

Couple other untouched shortcuts included for your amusement

Extract to your Windows folder (backup+overwrtite your original file)

 

[edit]

PIF Editor from Windows 3.11, if anyone wants it - PIFEDIT.zip

Edited July 6, 2022 by RainyShadow

[jaclaz]

Most probably (but should be tested) it is the 04000000h value in the bitmask at offset 010h of section Windows 386, marked as "Not automatically offer transition in a MS-DOS mode" in the linked to document, which sounds like a "reversed" description of "Suggest MS-DOS mode as necessary".

@RainyShadow

If you have time/will can you make:

1) two copies of a same .pif

2) save a copy of the .pif with the setting enabled

3( save the other copy of the .pif with the setting disabled

4) compare in a hex editor or run fc /b against the two files

jaclaz

[RainyShadow]

@jaclaz

done test.zip

 

Offset 0x1CC, value 00 is enabled, 04 is disabled.

Edited July 6, 2022 by RainyShadow
fixed

[jaclaz]

Good.

The 04 seems right, the offset is - pardon me the pun - way off, but if the byte is there it is there (and the mentioned doc is not at all clear in the way it provides offsets or I am very bad at calculating them, maybe sections are in a different order from what seems to be described).

BUT I checked the files, and the offset is actually 460 decimal i.e. 0x1CC that makes a lot more sense, I will try later to re-calculate if it matches.

jaclaz

[RainyShadow]

3 minutes ago, jaclaz said:

BUT I checked the files, and the offset is actually 460 decimal i.e. 0x1CC that makes a lot more sense, I will try later to re-calculate if it matches.

oops  

I normally have my editor show hexadecimals, but the switching is done with a single click and i didn't even notice, lol

 

 

[jaclaz]

The linked to doc uses lengths of the section (excluding titles) and some lengths within section seems wrong (possibly something has changed in the format) and there is some 00 and 20 (SPACE) padding, but all  in all the 0x1CC offset is fine.

jaclaz

Edited July 7, 2022 by jaclaz
I had misread the documentation

[jaclaz]

Corrected previous post, I read the document incorrectly, it is accurate.

Re-checked it.

The 0x1CC is correct.

The four byte value is at offset 0x10 from the beginning of the section, since the 0x04 is the most significant byte, it is the fourth byte, i.e. there are 3 bytes before it.

The section begins at 171h+16h+16h+6h=1A3h (basic section+basic section header+first section header+first section length)

To this you add 16h for the second section header, 10h for the relative offset in the section and 3 for the relative offset inside the 4 byte value:

1A3h+16h+10h+3=1CCh

jaclaz

[jumper]

1B0h in my pif tests on 98:

Fc/b y.pif z.pif

Will try again on ME.

Update: Close on Exit is 01h at 1B0h on 98 and ME, so !Suggest must be 04h at same on both.

 

Edited July 8, 2022 by jumper

[jaclaz]

@jumper

It sounds "queer".

The size of the sections and of the section headers per documentation are fixed, 1B0h is 1Ch (28) before the calculated 1CCh, which is at relative offset 10h+3=19, so your 1B0h seemingly falls before the beginning of the 386 section, right into the section header.

AND "Close on Exit" should be in the Basic section, at offset 63h.  and it should be 10h as value, not 01h

Post a .zip containing your y.pif and z.pif, I would like to have a look at them, comparing with the files RainyShadow posted.

jaclaz

Edited July 8, 2022 by jaclaz

[jumper]

It's just where it should be in the 386 section. Follow the 16-bit chain of headers to find the 386 section. Chain starts at 171h as legacy section header actually follows its data. Header struct (size 22d/16h):

Char [16d/10h]  - szSectionName

Word Next, dataOffset, dataLength

 

You have an extra 16h+6h in your section calculation. Maybe an extra 286 section that mine (98 and ME) don't have?

(Sorry, can't post files from pc now.)