Quick update. I checked the internet for the RtlFreeHeap issue.
It seems to be related to the NT Native API. It has to do with the PE loader, too, I think.
Windows 9x doesn't seem to be affected. Well, Windows 95, at least. Windows 98 was the first one to incorporate parts of the NT kernal.
"NTKERN.VXD is the emulator of the NT/WDM kernel over the old 3.x/95/98/Me Windows VMM kernel."
https://community.osr.com/discussion/143623/n … xd-windows-2003

Edit: I forgot to mention: I also forgot to change the Win32 project type from Debug to Release when I made the test binaries.
So it wasn't unlikely that all those debug information might have been too much for Win32s.
However, that wasn't the case. After changing the active project to Release, the file just got smaller. The error remained.

Edit: I hope you don't mind for the many dilettante mistakes of mine. 😅
I've been a modest tinkerer all my life, always learning by doing. 😄
So please bear with me. Please rather see this thread as a brainstorming session, sort of.

I see alot of choices here on getting a project up and running. I wouldn't mind trying to get one of these old compilers going, but right now I am hoping for a cross compiler on my modern machine to do the job, as I've had pretty good success at that. I think it will prove to be difficult still, and I might want to try VC4 or VC5 for win32s. Although again I think gcc with linking to glibc instead would be a good choice, as SDL isn't really all that specific to Microsoft's C libs. SDL should be able to work without msvcrt pretty easily.

I like the SDL idea, since it might prove to be a lightweight example on how to do things, to get you to the point of wanting to wrap DirectDraw to something else.

So I think to carefully think through to pick and try things will take me some time.

Jo22 wrote on 2023-01-23, 16:43:

"RtlFreeHeap" is an NT function that's simply not available.

Wait, does that mean you can try this on NT 3.1 or NT 3.51. It should work there, as NT 3.51 is quite close to NT 4.0 RTM. I would have tried this out myself, but I have school tomorrow, and I also don't know which files to copy. You mention DirectX 3.0 dlls, so I'm a tinker a bit with NT 3.51 and maybe NT 4, and probably destroy a few VMs while copying random Dlls. Will post screenshots if I find something interesting.

Jo22 wrote on 2023-01-23, 16:43:

Copying the pseudo DirectX 3 runtime files from NT 4 SP6 over to \SYSTEM\WIN32S partially worked (in quotation marks).

Umm... What files did you copy again?

BengalEmpire767 wrote on 2024-06-29, 09:53:

Jo22 wrote on 2023-01-23, 16:43:

Copying the pseudo DirectX 3 runtime files from NT 4 SP6 over to \SYSTEM\WIN32S partially worked (in quotation marks).

Umm... What files did you copy again?

Hi, I think it was ddraw.dll mainly. Other files such as dsound.dll and dinput.dll, too, I believe.

But please don't raise your expectations too high.
It's more of a trouble shooting measure.

DirectX in Windows NT wasn't really hardware accelerated, so I thought it's a better candidate than the DirectX on Windows 95.

The NT 4 DirectX doesn't tinker with VXDs or other system files in a way that the usually DirectX does.
It mainly converts to GDI and Wave API.

After all, all we need is Direct Draw. DirectX 2 or 3 should be sufficient to make programs run without crashing.
So that the application window (main form) would show up.

Once they *run*, I thought it would still be possible to use a direct draw wrapper (code parts of DXGL, HX DOS Extender etc) as a substitute to the original DirectX files.

DirectDraw and Direct3D are not trivial for NT 3.51 and 4. It won't work for NT 3.51, and only the included 3.0 version can work with NT4. Those old NT versions lacked a lot of symbols needed for newer DirectDraw/Direct3D to function.
(PS: PAL-DDRAW mentioned in the OP has no dependency issues with NT 3.51 so it can be used there. I don't have anything good to test programs for validating proper DirectDraw functionality, however.)

However, NT 3.51 and 4 apparently had no dependency issue with DirectSound/DirectMusic up to 8.0. There used to be a DirectX Media 6.1 for NT4 but it's theoretically possible to "upgrade" it to 8.0 based on the discoveries.

Back then I already succeeded in getting Yamaha S-YXG50 installed on NT 3.51. However, I was only able to produce any MIDI output from its bundled XGPlayer -- even after I configured MIDI mapper to point to the soft synth, I cannot get any MIDI output from other programs.

Most likely I need to actually register those DirectX components into HKCR. That is, actually write all the registry lines mentioned in the respective INF files so other programs can properly access DirectSound/DirectMusic, which is used by the soft synth. As there are quite a few registry lines regarding DirectSound and DirectMusic it certainly won't be a simple effort.

From what I inspected a good amount of DirectPlay and DirectInput (up to 7 I think) should also be usable, though I did not test the functionalities extensively.

In overall, for NT 3.51/4, a portion of DirectX can be made working, just not all of them. DirectX is pretty much for Win9x, 2000 and onwards.

Hi, I'm just a layman here but I suppose the main goal at this early stage is to solve dependency issues and get the application to run.
To run in the sense that the application is visible on Win32s.
There doesn't need to be any actual video output at this stage yet.
At a later point in time, it would be nice if the menu items would respond.
If we're there, actual Direct Draw initialization would be next step, maybe.
The early emulators and games of the mid-90s did't make much use of advanced DirectX features. Or so I hope.
In essence, Direct Draw 1.0 functionality would be enough, maybe.
Problem is that applications had been compiled with a later DirectX SDK, so the applications need to see DirectX 2 or 3 in order to be satisfied.
Once we're here, writing an wrapper from Direct Draw 1.0 to WinG would be worth a try.
Direct Input, Direct Sound etc. could be "supported" through dummy DLLs.
The emulators/games often had featured ordinary WaveOut as a workaround.

Ok just got back from school, I'm gonna give this a try today, don't think I'm going to go further, but still.

Quick update. It seems that Japheth's implementation of DirectX 2/DirectDraw 2 in HX DOS Extender
is good enough to run other Win32-based emulators such as Neko Project II.

Early versions 0.15 to 0.18 seem to run flawlessly, at least.
Except for the missing menu (GDI). Sound works, too.

Edit: There's no sound audible in my installation, but no error message I mean.
Issue night be specific to my HX DOS Extender installation here.

Version 0.22 seems to miss function "CreatePropertySheetA",
whereas the more recent version 0.81a misses "WINNLSEnableIME".

The latter seems to be related to the Input Method Editor (IME), a Japanese utility.
it's being part of Japanese Windows.

WINNLS dummies also exist for western Windows, not sure if it auto-magically fixes all the issues.

This is what Otaku World says about it:
"Otaku World's own WINNLS.DLL v1.1 by Stephen P. Lepisto
This is a replacement dll for WINNLS.DLL and IMM.DLL which appear only on Asian versions of Windows 95/98 (these DLLs handle the input of asian alphabets).
This replacement version will satisfy the requirements of some screen savers and toys that need WINNLS.DLL and IMM.DLL to run.
This version of WINNLS.DLL can be dropped into your system folder under Windows 9x and NT.
This file is NOT needed under Windows 3.1 but is needed under Windows 3.11!
Note: Windows 98/2000 and XP will most likely not need this file as they already include a version of winnls.dll.
Win2000 and WinXP will not allow you to copy this into the system folder anyway.
You will not need IMM.DLL with this WINNLS.DLL!
Note for Netscape users: if your browser saves this file with an extension of .EXE, please rename it to have a .DLL extension.

I think this is very interesting. It gives hope that Windows 3.1/Win32s might be sufficient enough.

Of course there are other emulators like CBM64 Project (CBM64W) that might run on HX DOS Extender just as well.

It's just that Neko Project II was very well written and supports various Win32 platforms,
including special build versions for targeting 9x, NT and Win CE. And Win64.
It also has two flavors, Japanese and Worldwide. Maybe related to IME support.

Maybe it can be built for Wín32s one day, as well.

The versions with Visual C++ 4.2 support (project files) might be convinced to run,
if CRTDLL.DLL is being used and once DirectDraw 2 or a subset of it is available.

Maybe it's possible to implement a DirectDraw 2 libary without acceleration.
if it's using plain surface/GDI output method, not much extra work would be needed.

Considering that real DirectDraw had a GDI fallback already built-in, this would be a start.

Anyway, I just wanted to keep you updated about my experiments.

A few more pictures of other emulators running via HX DOS Extender.
Some of them almost ran on Win32s last time I've tried.

And here's vMac 0.18b Win32 port..
It almost ran in an usable fashion on Win32s, if it wasn't for visual glitches.

Jo22 wrote on 2024-08-17, 05:26:

It seems that Japheth's implementation of DirectX 2/DirectDraw 2 in HX DOS Extender

Hello,

it should be mentioned that the above link to HX DOS Extender is pretty outdated - it's from 2013.

The current version of the extender can be found here: https://github.com/Baron-von-Riedesel/HX

Baron von Riedesel wrote on 2024-08-17, 13:18:

[Hello,

it should be mentioned that the above link to HX DOS Extender is pretty outdated - it's from 2013.

The current version of the extender can be found here: https://github.com/Baron-von-Riedesel/HX

Hi! Thank you very much! ^^

Quick update. I got NP II to compile on all three versions of Visual Studio/Visual C++.

For VC++ 4.2, I had to get DirectX 3 SDK and put it to C:\SDK, then add the directory and its sub directories in Visual Studio (Tools->Options).
I didn't add them to vcvars32.bat yet. The DirectX 2 SDK also worked, but dxguid.lib was missing. The DirectX 3 version could be used.
I've attached a screenshot for convenience.

Only problem I had was adding CRTDLL library (crtdll.lib) and /FIXED:NO to VC++ 4.2.
Later I've found out the linker option wasn't necessary, because VC++ 4 still has relocation tables enabled by default.

Another stumbling stone is the release type, by the way.
WIN32 DEBUG or TRACE builds sometimes cause compiling issues, but WIN32 RELEASE may work in same situation.

Visual Studio 6/Visual C++ 6 on Windows XP caused me the least issues, by the way. It worked straight away.
Its direct predecessor, VC++ 5, might be similar, but I haven't tried so I can't confirm. I use Visual Studio 97 on Japanese Windows 98SE.

PS: The problem with the missing "rtlfreeheap" function in w32scomb on Win32s still remains.
So far, I've found this information about "rtlfreeheap" function:
https://learn.microsoft.com/en-us/windows-har … ifs-rtlfreeheap

PS: I've forgotten to mention that I'm using Windows NT 4 for VC++ 4.2. I thought it would be appropriate (DX2/DX3 limit etc).
The font of NP II is weird looking because the PC-98 font file isn't found in same directory yet, so it falls back to an internal font.
Another thing I forgot to mention is that I copied NASM v0.99 to the BIN folder of Visual C++. I renamed it to NASMW.EXE.
That's because NASM was needed for the MK.BAT file in NP II directory. It assembled a memory.obj file that's needed for the project.

DosFreak wrote on 2023-01-23, 22:09:

Video: NT 3.50 and 3.x don't support OpenGL and 3.51 doesn't support OpenGL 1.2, so SDL would use WINDIB which means GDI.

This is not entirely true - OpenGL 1.0 appeared in Windows 3.5 "Daytona", then extensions were added in 3.51 "NewShell", and version 1.1 became available in 4.0 "Cairo".
https://community.khronos.org/t/is-it-possibl … -so-how/110656/

Both versions were also ported to Windows 95 eventually:
https://www.betaarchive.com/wiki/index.php?ti … _Archive/124556 - 1.0 with fix for "memory DC/bitmap resizing bug", distributed as oglfix.exe
https://www.betaarchive.com/wiki/index.php?ti … _Archive/154877 - 1.1, distributed as opengl95.exe

The initial version of the 1.0 port mentioned in Q124556 from above can be found here:
https://archive.org/details/Microsoft_Develop … _1_October_1995 (see /WIN95/OPENGL95)

Taking posts out if context is never a good idea particularly since mine was related to SDL. Go back and read the thread from the start and focus on what the op is asking. Iirc, this thread was likely initiated on efforts to run emulators that cant run on 3.1 due to missing dependencies. Then SDL was brought up since its highly compatible and should be possible with some effort to get programs to use it to work.

There really isnt a lot of video cards and drivers with ogl support that would support running old or newer emulators that require old or newer vers of hardware ogl on these old versions of Windows and running ogl wrapped to software (GDI) is incredibly slow even on fast computers but if you want software ogl 2.1 or less running on nt 3 then yes its possible. Heck with a bit if work you can probably compile newer versions of mesa3d to work or create your own GPU and drivers.

If you want a different discussion on which os supported what in what way and if its usable or not by anyone then or today then feel free to start a new thread.

Man, I just noticed a slight inaccuracy and wanted to clarify. There's absolutely no personal attack here. It's just that I'm kind of traumatized by this because it took myself a whole year to grok the Windows graphics stack due to the sheer amount of misinformation and incorrect terminology floating around. And VOGONS helped me a lot with this. Now I try to share this knowledge to preserve it, rather than sit on it like a dog in the manger.

And yes, I read the entire topic carefully before this.

BlackDoomer wrote on 2024-11-13, 18:59:

Man, I just noticed a slight inaccuracy and wanted to clarify. There's no absolute personal attack here. It's just that I'm kind of traumatized by this because it took myself a whole year to grok the Windows graphics stack due to the sheer amount of misinformation and incorrect terminology floating around. Now I try to share this knowledge to preserve it, rather than sit on it like a dog in the manger.

And yes, I read the entire topic carefully before this.

Hi, I think it just sort of was a misunderstanding that happened here.
Emotions transport not so well over the Internet, after all. 😟
Also, you must know that DosFreak knows quite a bit about DOSBox, SDL and NT 3.x. If memory serves, he had ported DOSBox to NT 3.51, too.
So your comment maybe came off as sheer criticism, understandably.
Anyway, it's not that of a drama, I think. We all make such mistakes once in a while without even knowing, myself included.
Personally, I'm grateful for any Information! 🙂 I didn't know much about OpenGL 1.x yet, Windows 98SE was what introduced me to OpenGL.
More precisely the GL Gears sample (Win32 build). You know, the one that originated from Unix platforms..

Quick update. Found an alternative to CRT library, called MiniCRT. Works from Windows NT 3.1 onwards.
http://www.malsmith.net/minicrt/