Maybe MSLU would allow it to run
Or AI suggested...
Set the minimum OS version in the PE header
If you set the MajorOperatingSystemVersion and MajorSubsystemVersion to 5.0, Win9x will refuse to run it with a “not a valid Win32 application” error.

Thank you for your reply, none of these are options:

1) I clearly specified "how do I stop Windows Me/9x trying to run them?" not "how do I get Unicode work on Windows 9x", I don't wish to make SIV32N work on Windows 9x.
2) SIV32N is for >= Windows NT V4.00 so it needs to be and is 4.00
3) SIV32X is for >= Windows 2000 and is already 5.00

I can easily make SIV32N refuse to start, but how do I stop Windows Me/9x trying to run SIV32N?

It refuses to run the other SIV images, surely it can do this for images that require FULL Unicode support like Windows NT has. I am hoping for a Program Requires Windows NT type message, but can't see a flag in the image header for this.

I don't see why I get the device not functioning message and it's interesting that the x64 + ia64 images don't mention the different CPU type like the Alpha + PowerPC ones do.

Matth79 wrote on 2026-02-21, 14:21:

1) Maybe MSLU would allow it to run Or AI suggested... 2) Set the minimum OS version in the PE header 3) If you set the MajorOpe […]
Show full quote

1) Maybe MSLU would allow it to run
Or AI suggested...
2) Set the minimum OS version in the PE header
3) If you set the MajorOperatingSystemVersion and MajorSubsystemVersion to 5.0, Win9x will refuse to run it with a “not a valid Win32 application” error.

By accident I just ran the Unicode SIN32N on Windows Me, given it's Unicode it's not doing to work on Me/9x but much to my surprise WMe tried to run it and needless to say it did not work.

Hi, I don't know much about that program, but Unicode and GDI+ applications do run on Windows 98SE/Me.
These OSes just need unicows.dll and gdiplus.dll.
KernelEx project recommends having them in the Windows or System32 folder, I think.
That being said, unicows is merely a wrapper that translates Unicode<>ANSI, it won't add support for Unicode characters.
But applications will at least run with it.

Jo22 wrote on 2026-02-21, 17:23:

That being said, unicows is merely a wrapper that translates Unicode<>ANSI, it won't add support for Unicode characters.
But applications will at least run with it.

Given you said "it won't add support for Unicode characters" what would be the benefit of SIV32N working on Windows Me/9x given SIV32L does work on Windows Me/9x ?

Again I clearly specified "how do I stop Windows Me/9x trying to run them?" not "how do I get Unicode to work on Windows 9x" !

Update: I looked at this all in 2009 and decided MSLU is only sensible for Unicode only applications and the best implementation is to do an ASCII build for Windows 9x and Unicode ones for Windows NT which is what I did. I also seem to recall if built with MSLU that image is useless for Windows NT. In general using MSLU is the wrong solution when the program can be compiled for ASCII/MBCS.

red-ray wrote on 2026-02-21, 17:32:

Jo22 wrote on 2026-02-21, 17:23:

That being said, unicows is merely a wrapper that translates Unicode<>ANSI, it won't add support for Unicode characters.
But applications will at least run with it.

Give you said "it won't add support for Unicode characters" what would be the benefit of SIV32N working on Windows Me/9x given SIV32L does work on Windows Me/9x ?

Again I clearly specified "how do I stop Windows Me/9x trying to run them?" not "how do I get Unicode work on Windows 9x" !

Ah, sorry. 😅 I've merely responded to make clear that Unicode applications as such are a non-issue on Windows 9x, to prevent possible misinformation to spread.
I've also mentioned KernelEx, since it's related. It is originally meant to run Windows 2000/XP applications on Win 9x, after all.
And Windows 2000/XP applications in turn are often Win32 Unicode applications, -except those notable exceptions written in VB6/Visual Studio 6 back then-, so it may solve the associated issues of NT line applications as a side effect.
But of course, it likely won't solve the issue the way you want it. It also requires an updated Windows 9x/Me installation.
I'm afraid that's all I can say about the topic at the moment. 🙁

Edit: What comes to mind.. Back then, applications could identify the OS either by version number, platform id or Windows OS string (bad, some Java applications did it).
The PlatformID knew about Win31+Win32s, Windows 95/98, NT and Windows CE.
Late Windows 3.1 applications did check for Windows 95 by the Win16 API.
If 3.95 was returned instead of 3.1x, then the application knew it ran on Windows 95 (or higher).

Edit: More information:
https://learn.microsoft.com/en-us/dotnet/api/ … d?view=net-10.0
https://www.c-sharpcorner.com/UploadFile/kamr … system-version/

red-ray wrote on 2026-02-21, 17:32:

Given you said "it won't add support for Unicode characters" what would be the benefit of SIV32N working on Windows Me/9x given SIV32L does work on Windows Me/9x ?

Jo22 wrote on 2026-02-21, 18:01:

Ah, sorry. 😅 I've merely responded to make clear that Unicode applications as such are a non-issue on Windows 9x, to prevent possible misinformation to spread.

Please stop posting these off topic ramblings, if you can't concisely answer direct questions then don't post at all.

I looked at this all way back in 2009 and decided MSLU is only sensible for Unicode only applications and the best implementation is to do an ASCII build for Windows 9x and Unicode ones for Windows NT which is what I did. I also seem to recall if built with MSLU that image is useless for Windows NT. In general using MSLU is the wrong solution when the program can be compiled for ASCII/MBCS.

Update: I have done some checking, you are totally incorrect🙁 and at lest one, I suspect most, native Windows NT V4.00 Unicode applications have at least one issue, I suspect many issues, on Windows 98 + Me as code that works on Windows NT V4.00 clearly screws up on Windows 98 + Me. Maybe if they were linked with MSLU they would not have an issue, however then I suspect they would not work as expected on Windows NT V4.00.

With the following routine EBX is saved on entry and when the function exits ESP is incorrect which results in an incorrect value being restored to EBX, once the function returns the incorrect value in EBX is used and this is what caused the crash.

It's this class of issue why I wish to stop Windows 9x even trying to run SIV32N.exe, further were I daft enough to build say SIV32N-MSLU .exe using MSLU then there would still be SIV32N.exe.

1ULONG reg_lose_tmp(                     // delete any .TMP files
2  CONST    SGD_BLOCK   *sgb,            // SIV Global Block
3           ULONG        mode )          // mode options
4{          TCHAR       *twp;            // text work pointer
5           TCHAR        twb[ 256 ];     // text work buffer
6
7  twp += stprintf( twp = twb, TEXT( "%s%s.tmp" ),                               // initialise
8                                         sgb->siv_dir,                          //
9                                         sgb->siv_exe );  DeleteFile( twb );    // SIVNNX.tmp
10  stprintf( twp -  7, TEXT( "RES.tmp" )               );  DeleteFile( twb );    // SIVRES.tmp
11  stprintf( twp -  7, TEXT( "W9X.tmp" )               );  DeleteFile( twb );    // SIVW9X.tmp
12  stprintf( twp - 10, TEXT(  "%s.tmp" ), sgb->jmapinm );  DeleteFile( twb );    // JMAPI_XNN.tmp
13  stprintf( twp - 10, TEXT(  "%s.tmp" ), sgb->hpdevnm );  DeleteFile( twb );    // hptdevxx.tmp
14  stprintf( twp - 10, TEXT(  "%s.tmp" ), sgb->stlibnm );  DeleteFile( twb );    // storelib_xnn.tmp
15
16  return mode;                                                                  // done
17}

So I take it you build this software yourself? Maybe import a symbol that Win9x does not export from its standard DLLs. It seems to carry some of the "*W" functions, but almost certainly not all of them. You need to find just one, and when you make your executable depend on that, Win9x will complain that it cannot find the symbol and will not run the program.

Ringding wrote on 2026-02-22, 09:26:

Maybe import a symbol that Win9x does not export from its standard DLLs.

Thank you for your post , I was thinking on similar lines, but had failed to find a function that is there on Windows NT V3.10 and absent on Windows Me.

Both W98 + WMe export such as DialogBoxIndirectParamW(), when it get's called it just returns totally failing to call the lpDialogFunc, it also returns 0 when -1 would make more sense.

When I asked Google it suggested NtCreateFile(), but there does not seem to be a ntdll.lib that MSVC 6 can link with. In the end I tried NetApiBufferFree() and that was easy to link as NETAPI32.lib exists in MSVC 6.

Below is what get's reported which I feel in not that helpful, wonder why there is "A Device attached..." as well and wonder, is it better to let the program start and have a sensible report?

Why block anything? Just use the popup that you already have that it is not supported.

DosFreak wrote on 2026-02-22, 11:51:

Why block anything?

I felt block as that is what happens with SIV32A.exe + SIV32P.exe, etc.. and I felt all the different builds should be the same.

I would like an inbuilt block that says something like "Program requires Windows NT", given I can't find one then I guess let it run and use my own popups.