VOGONS


First post, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Hi everyone,

I do hope this is an acceptable spot to post this question in..
While I considered Miliways at first, I thought this might better fit into "Software".
Because, my topic is about old software on even older (!) software . 😅

I'm also hoping that I didn't ask this question in the past again.
I vaguely remember talking something about WIndows 3.1 and DirectX years ago, but that's all.
If there's an older thread of mine, the moderators are free to merge them, of course.

Ok, so let's start from the beginning. It all started in a dark, rainy night.
The wind rushed through the leaves of an old oak tree on the graveyard.. Oh, wait a sec - wrong story. 😅
I'm currently trying to backport certain Win95 programs/emulators to Win32s.. Which to my surpise, really kind of works! Yay! 😁
- Once the relocation tables are installed and crtdll.dll is being used, things start to come alive. Cool!

However, there's one problem: Some Win 95 applications depend on early DirectDraw (DirectX 2 or 3) and DirectSound.
While DirectSound is used as nothing more as an MCI alternative, the graphics stuff is more complicated.
Converting everything to WinG is quite some work.

Hence my question - can a subset of DirectDraw be implemented on Win32s ?
I'm not talking about porting Direct3D, retained mode et cetera pp. That's huge!
Just a simply video output (overlay, bit blit etc) - just like WinG or DCI offer on Windows 3.1x.

If you have any ideas, no matter how vague or crazy, please let me know! 😁
A wrapper from DirectDraw to WinG, DCI or GDI would be interesting, too.
Some sort of miniature ddraw.dll, like Windows NT 4 SP6 has (DirectX 3.0a level of features).

There are other projects, like DXGL - a DirectDraw to OpenGL wrapper.
- Maybe it can be ported over to Win32s and use a Voodoo card (MiniGL, Glide) somehow?

Or what about Pal-DDraw?
It seems it can do DDraw to GDI translation, without any other APIs involved.
https://github.com/ayuanx/pal-ddraw

Any ideas or thoughts heartly welcome! ^^

Best regards,
Jo22

Attachments

  • cube.gif
    Filename
    cube.gif
    File size
    3.14 KiB
    Views
    1673 views
    File license
    Fair use/fair dealing exception

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 1 of 21, by BEEN_Nath_58

User metadata
Rank l33t
Rank
l33t

DxWnd does DirectDraw overlays and may other things (like early DirectDraw interfaces) on GDI. However I am not sure if modern GDI and old GDI are equally capable. Secondly, you'll have to extract things out of there and compile them for Win3.2 and Win32s

previously known as Discrete_BOB_058

Reply 2 of 21, by Vic Zarratt

User metadata
Rank Member
Rank
Member

Raydream studio v4 had dual installer for win32s and 95, if 95 was detected than it would install rds4 with directX support and support for a different 3dmf file format, but the 32s version used something else and probably cut-down on something else i wouldn't remember.
Here's what i'm gibbering on about: http://www.win3x.org/win3board/viewtopic.php?t=13786

I manage a pot-pourri of video matter...

Reply 3 of 21, by wbahnassi

User metadata
Rank Member
Rank
Member

You can write an interposer DLL to implement DX3. It's a simple-enough API. But there will be some key pieces that will ruin the end result, either for performance or entire functionality. My suggestion is to try to translate DDraw to WinG as it should offer more speed and game-needed features than stupid GDI. And I guess forget about any HW-accelerated color-keyed blits, it would be all done in software... so don't expect matching perf to Win95.

Reply 4 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Thanks for all your replies so far, guys! I really appreciate your feedback! 😄 👍

One of the sumbling stones might be the compilers needed, also.
Visual C++5.0 can be convinced to use CRTDLL.DLL (via CRTDLL.LIB) and its linker can be forced to use relocation tables (/FIXED:NO).
(Note: DLL generation is different maybe. They may default to using relocation tables, but I'm not entirely sure.)

Modern compilers don't seem to feature this, anymore, unfortunately. 🙁
Many recent compiler projects use MSVCRT DLLs or worse, UCRT instead.
Like MinGW64, for example: https://winlibs.com/

Windows 3.1+Win32s require compilers, though,
which can produce something that can run on Windows NT 3.51, still.

Things like MinGW don't run on Windows XP SP3 anymore, even. That's all I have on my latest Windows system (my main PC is a Pi 4).
Just got an error message when trying to compile Pal-DDraw as an ordinary DLL (not for Win32s):
It complains about "cannot find entry point" error regarding _mkgmtime64 in msvcrt.dll.
Another user reported it here: https://sourceforge.net/p/mingw-w64/bugs/323/

I'm afraid I have to set up a VM with a more recent copy of Windows for such development software..
Hopefully, the produced binaries will run on Windows 95, at least, as promised.

Attachments

  • mkgmtime64_xpsp3.jpg
    Filename
    mkgmtime64_xpsp3.jpg
    File size
    11.28 KiB
    Views
    1587 views
    File comment
    "cmake.exe - jump-in point not found" (entry point not found)
    File license
    Fair use/fair dealing exception

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 5 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

On the other hand.. Win32s seems to be quite forgiving, which gives hope for further experiments.
Copying the pseudo DirectX 3 runtime files from NT 4 SP6 over to \SYSTEM\WIN32S partially worked (in quotation marks).
The Win32s test application nolonger complains about DirectDraw being missing.
It's rather Win32s that seems to be a bit helpless, because it doesn't feature a vital function call (understandably).
"RtlFreeHeap" is an NT function that's simply not available.

Attachments

  • win32s_rtlfreeheap.gif
    Filename
    win32s_rtlfreeheap.gif
    File size
    12.91 KiB
    Views
    1562 views
    File comment
    RTLFREEHEAP error
    File license
    Fair use/fair dealing exception

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 6 of 21, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Don't bother with MinGW or MinGW-W64 they won't work for less than NT 3.50/95. Both can compile working programs for NT 3.50 and 95.
You shouldn't need to run an environment on an old Windows OS (XP) unless you want to or the compiler you want to use is 16bit on a 64bit system. If 32bit you should be good. IIRC, OpenWatcom can produce 16bit Windows 3.x binaries.

Are you recompiling programs for an earlier OS or hacking the OS (wrappers) to get the code to work on an earlier OS or both?

For MinGW and MinGW-64 if using the later versions then you'll need to add/update the MSVCRT in 3.50,3.51,NT4,95,98,ME,2000.
Re: DOSBox Compilation Guides

For MinGW-W64 you'll need to make sure you use a win32 thread compiled MinGW-W64 and compile all program dependencies yourself (don't use pacman!)

How To Ask Questions The Smart Way
Make your games work offline

Reply 7 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++
DosFreak wrote on 2023-01-23, 17:15:

Don't bother with MinGW or MinGW-W64 they won't work for less than NT 3.50/95. Both can compile working programs for NT 3.50 and 95.

Thanks! NT 3.5 would be a start for me, at least, if it's possible. 😀

DosFreak wrote on 2023-01-23, 17:15:

You shouldn't need to run an environment on an old Windows OS (XP) unless you want to or the compiler you want to use is 16bit on a 64bit system. If 32bit you should be good. IIRC, OpenWatcom can produce 16bit Windows 3.x binaries.

You're right, I guess. It's just.. The XP PC is my latest Windows machine. It's an Intel Xeon.

My story: After Windows 7 went EOL, I had no other chance than to abandon Windows/PC:
The later releases were nolonger compatible with both my ideals and my PC hardware, too.

The upgraded Athlon 64 X2 machines my dad and I used for years can't run Windows 8.1 anymore, even.
"Your CPU does not support CompareExchange 128" *sigh* So we decided to abandon Windows/PC at this point.

Ok, so I had to decide were to go to, which in the end I couldn't decide. So I started using a Raspberry Pi 3 as a stop-gap solution many years ago.
- Currently, I'm still stuck with the Raspberry Pi platform, using a modern Raspberry Pi 4 in the maximum RAM version.

My dilemma is: The current development on the x86 PC platform after Windows 7 went EOL isn't for me. It's a philosophical matter, too.
That's why I'm still waiting. Waiting for things to change for the better. If that's going to happen is uncertain.

I didn't like Windows 8.0, 8.1 and Windows 10. Windows 11 looked promising (originally, before its release and the many restrictions), but not so much anymore.
UEFI without CSM/BIOS, TPM 2.0 and Secure-Boot requirement etc. This is nolonger my world. Everyhing is locked-in. I'm not sure if I still want to buy/get a new PC.
But even if I do buy/get one, it will be locked to Windows 10/11. Older OSes are nolonger possible to boot, not even as a dual-boot.

Without CSM/BIOS and other things, SATA ports, I can't even do boot DOS from an USB medium anymore.
And PCs capable of Windows 11 (officially, without hacks) aren't older than 3-5 years.
They lack a lot of legacy features (plain USB 2.0, floppy controller etc) that would be useful for Windows XP/7.

So I thought about getting a new Macintosh as an alternaive and use an x86 virtualizer (Vmware, Parallels, VBox) for a peace of mind.
However, Apple started switching to M1/M2 processors a while ago, too.
So I would have to use x86 PC emulators on this platform.

Also, modern Mac OS X (now macOS) doesn't look friendly anymore. I'm not sure if I should move over.
I liked the look&feel of Mac OS X 10.0 Cheetah to Mac OS X 10.4 Tiger the most.
Snow Leopard, 10.6, was fine, too. I liked its ability to run Power PC applications using Cocoa and Carbon API.

Modern Mac OS X also tries to prohibit all sorts of stuff, like running 32-Bit applications
and using applications distributed as an offline-installer (-> everything not from Apple Store).
That's almost as bad as using current Microsoft Windows. *sigh*

Last but not least: The virtualizers available on M1/M2 Macs can run a virtualied Windows 10 for ARM, at best.
Which in itself has a basic x86 emulator integrated for running Win32 applications. However, this isn't exactly ideal, either.
The whole thing contradicts with my interest in x86 VMs and retro development.

That's why I'm still using the old Xeon as a Windows XP host.
Its two CPUs are quite capable for what they are, despite their age.
Hopefully, I can get some basic VMs with Windows 7-10 going on this old iron. 😀

DosFreak wrote on 2023-01-23, 17:15:

Are you recompiling programs for an earlier OS or hacking the OS (wrappers) to get the code to work on an earlier OS or both?

A little bit of both, I guess. I haven't completely decided what to do, right now. 😅
So far, I've managed to re-compile a handful of existing programs for Win32s using
their original source code and with the help of mid-90s compilers such as Delphi 2 and VS C++ 5.0.
Some of these were comparably simple things, though: Little utilities for emulators, etc.

DosFreak wrote on 2023-01-23, 17:15:

For MinGW and MinGW-64 if using the later versions then you'll need to add/update the MSVCRT in 3.50,3.51,NT4,95,98,ME,2000.
Re: DOSBox Compilation Guides

For MinGW-W64 you'll need to make sure you use a win32 thread compiled MinGW-W64 and compile all program dependencies yourself (don't use pacman!)

Thanks, I'll keep that in mind. 😄

Edit: Edited.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 8 of 21, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I'd say for questions on development then hit up Michael at the OS/2 Museum
https://www.os2museum.com/wp/author/michaln/
He is the one working on 3.x display drivers so may have some insight.

How To Ask Questions The Smart Way
Make your games work offline

Reply 9 of 21, by the3dfxdude

User metadata
Rank Member
Rank
Member

I think GDI's CreateDIBSection is what you are looking for. Check and see if this is available. I don't know when it was introduced.

I thought at one point, wine's ddraw (around 2001-2006) was based around a GDI style driver infrastructure that emulated something like this. Now anymore, there are alot more layers, which makes it harder to just bring over. If I were to try to go about this, I would try to use GDI. Or it would be learning the low level windows driver programming? Somehow it will be possible. I wouldn't be surprised that WinG and DDraw when they were first released used what GDI already offered at that point.

If an opengl driver exists on Win3.1, then you could maybe also lift some more ideas from wine on how to do the wrapping. But having any capable hardware that could actually accelerate on that backend in Win3.1? I can't see it.

Adding: Wine's gdi.exe and gdi32.dll shows both 16-bit and 32-bit exports for CreateDIBSection. Pretty sure it exists there.

Reply 10 of 21, by the3dfxdude

User metadata
Rank Member
Rank
Member

I went to look at SDL1 because it also uses CreateDIBSection. And looking over things, it seems like SDL1 can possibly be compiled without DirectX? It has separate backend video and audio drivers that don't require it. They may be a bit crusty and unused, but hey, it could be a source of inspiration. Also, I wonder if it could be easily ported to win32s on Win3.1? That means we could bring over alot of stuff based on SDL1, and perhaps if there is an opengl driver that works, run some of the demo programs, or even try going for a 3d game.

Reply 11 of 21, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

SDL was intended for 95+ so you'll likely need to do some work.

For 3.50 I had to disable fullscreen support (CHANGEDISPLAYSETTINGS) in sdl_config.h and use the 3.51 joystick.dll.
Previously I would compile SDL 1.2 without Directx, Joystick or opengl support, etc but this wasn't necessary and I just left that alone and compiled whichever program without that support.
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.
I was able to run my compile of Mesa3D v7.5.1 on NT3.50 that allows OpenGL 2.1 but it's so slow it really isn't worth it. Funnily enough later versions of Mesa3D using kernelex on 9x actually run faster but it's still slow and not worth it. Glide would be the best bet, although if you only intend to run these programs in a VM then mabye some wrapping to the host could be done.
Audio: Without dsound then SDL will use wave-out.

SDL will compile with Mingw (gcc), Mingw-W64 (gcc) and VS. Unknown about anything else.

For 3.50:
include\SDL_config.h
Add
#define NO_CHANGEDISPLAYSETTINGS 1

I found the following to be unecessary for my usage but perhaps for yours it may be, the VICE dev uses the below:

3.51 Compile SDL without DX and GL support, this can be done by removing the '#define SDL_AUDIO_DRIVER_DSOUND 1', '#define SDL […]
Show full quote

3.51
Compile SDL without DX and GL support, this can be done by removing the
'#define SDL_AUDIO_DRIVER_DSOUND 1', '#define SDL_VIDEO_DRIVER_DDRAW 1',
'#define SDL_VIDEO_OPENGL 1' and '#define SDL_VIDEO_OPENGL_WGL 1' parts from
the SDL_config_win32.h file, and by removing the 'Directx.h', 'SDL_dx5audio.c',
'SDL_dx5audio.h', 'SDL_dx5events.c', 'SDL_dx5events_c.h', 'SDL_dx5video.c',
'SDL_dx5video.h', 'SDL_dx5yuv.c' and 'SDL_dx5yuv_c.h' source parts from the SDL.dsp file.

3.50
Compile SDL without DX, GL and joystick support, this can be done by removing the
'#define SDL_AUDIO_DRIVER_DSOUND 1', '#define SDL_VIDEO_DRIVER_DDRAW 1',
'#define SDL_VIDEO_OPENGL 1' and '#define SDL_VIDEO_OPENGL_WGL 1' parts from the
SDL_config_win32.h file, by adding '#define NO_CHANGEDISPLAYSETTINGS 1' to the
SDL_config_win32.h file, and by removing the 'Directx.h', 'SDL_dx5audio.c', 'SDL_dx5audio.h',
'SDL_dx5events.c', 'SDL_dx5events_c.h', 'SDL_dx5video.c', 'SDL_dx5video.h', 'SDL_dx5yuv.c',
'SDL_dx5yuv_c.h', 'SDL_joystick.c', 'SDL_joystick_c.h', 'SDL_mmjoystick.c' and
'SDL_sysjoystick.h' source parts from the SDL.dsp file.

Frankly the development tools and support is greater on DOS and 9x,than it is for 3.x, you'd likely be better off with HX Extender since most of the hard work was already done.
GCC for DOS, rust for 9x, DOSJS, etc
https://github.com/Baron-von-Riedesel/HX

How To Ask Questions The Smart Way
Make your games work offline

Reply 12 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

This is also interesting, someone in 2016 asked about Win32s support for SDL 1.2,
sadly no one ever bothered to reply to his/her question. Or maybe did later on, the site is nolonger there.

"The current sdl12 code has a compatibility layer for win32 api, but has anyone worked on a port for win32s?
There is recent, extensive work to build at least one win32s “emulator” which actually maps the
win32s api instruction set to a modern system api (http://stephan.win31.de/w32slist.htm and https://en.wikipedia.org/wiki/Win32s).
I haven’t confirmed whether this particular project overlaps with Wine since it is currently closed source.
Another advantage is that win32s applications would run in dosbox since it supports Win 3.1;
however, Win32s “emulation” would be freed from the constraints of translating x86 instructions
and could instead directly translate the higher win32s api to a host system.

Since win32s seems to use some subset of GDI function, it would be interesting to first port the sdl12 windib driver so that it is compatible with win32s.
There is also recent work on openwatcom to build win32s applications so that this is possible."

Source (archived): https://discourse.libsdl.org/t/porting-sdl12-to-win32s/22015

It amazes me, however, how similar this person's point of view is (or was) compared to mine.
Somehow it's reassuring that I'm not the only person with such crazy ideas, hah. 😅

Edit: @the3dfxdude, dosfreak Thanks a lot for the links/tips! 😎 Yes, WinG and WINDIB are related, just checked!
The DIB engine in Windows 95 is like a descendant of WinG's WINGDE.DLL or vice versa (internal/original name "Windows 4.0 DIB Engine", DIBENG.DLL).

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 13 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Technically, there's another API that could be worth a try - SciTech's WinDirect.

https://www.cs.hmc.edu/~tsemple/wingames/

https://www.cs.hmc.edu/~tsemple/games/win311.html

http://www.combatsim.com/memb123/archive/htm/ … tm_arc4/sdd.htm

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 14 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Quick update. I think I understand why no one replied to the user's question. It's just a wild guess, though.:
The official SDL 1.2 apparently requires multi-threading. 🙄 Which isn't available on Windows 3.1/Win32s..

"Creating a Project with SDL
Create a project as a Win32 Application.
Create a C++ file for your project.
Set the C runtime to "Multi-threaded DLL" in the menu: Project|Settings|C/C++ tab|Code Generation|Runtime Library . "

Source: https://www.libsdl.org/release/SDL-1.2.15/VisualC.html

I've checked https://www.libsdl.org/release/ site.:
SDL 1.2.2 seems to be the last to support Visual C++ 5.0, which is the latest Win32s friendly Visual C++.
Version 6, as supported by SDL 1.2.14, is said to cause lots of headaches for compiling Win32s compatible binaries.

The last version, 1.2.15, doesn't mention an VC version in the filename - not sure what it needs.
The HTML file says "Using SDL with Microsoft Visual C++ 5,6 and 7". Why is version 8 not being mentioned ?
- It had its own filename just before (SDL-devel-1.2.14-VC8.zip)..

Edit: I didn't mean to be disrespectful. I really like SDL 1 due to it being so down-to-earth.
Platform-specific implementations aside, it's very clean and doesn't add any fuss to the matter.

It's just a bit depressing sometimes that even simple projects dropped support for classic VC++4/5/6 for no apparent reasons.
The same underlaying Visual Studio/VC++ compilers were used* for the final Visual Basics, VB5/6.
The iconic RAD IDEs for 32-Bit Windows development of the late 90s/early 2000s.

(*Speaking under correction: VB 5 used Visual Studio 97, whereas VB6 used Vistual Studio 6.0..
Afaik, VB 5 and 6 also used hacked VC++ compilers/linkers of those Visual Studios to generate the VB applications.
VB5/6 -in higher end versions- can generate both EXE files with P-Code or Native code, also. They still rely on the VB Runtime, of course.)

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 15 of 21, by the3dfxdude

User metadata
Rank Member
Rank
Member

I was able to cross compile a dll with the latest mingw, but that platform in it's loader implementation of msvcrt assumes threading functionality on init/exit. If I use a newish msvcrt from winxp that has this, that msvcrt won't run due to missing Nt* API functions. If I go older, then I loose the necessary threading support, at least with the public API. From what I know they have been making the headers assume vista+. I fixed something a little while ago to make it winxp compatible again, but even here it is happening.

I wonder if I just static link SDL to the gnu c library, that I won't need msvcrt at all. Note I have already been testing this on Win3.1 + win32s to this point. Yes unfortunately the assumptions mingw puts on msvcrt is not really compatible with any 9x either today it seems.

I think the truth is SDL supports threading because the devs probably thought it would be helpful. But apps are generally written single threaded, as it was common anyway back then. I don't think it imposes strong requirements on this, unless this came very late in the development? So I think that we probably could find ways to ignore whatever it needs the newer VC++ for.

Reply 16 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

the3dfxdude, thank you for your help and for the information! 😀 👍
Here, I'm currently experimenting with crtdll as a substitute for msvcrt. It dates back to the NT 3.1 days, afaik.
It wasn't my idea to use it, I must admit, however. I stumbled upon a github site that recommended it:
https://github.com/TransmissionZero/Win32s-Ex … ple-Application

From what I can tell, it really works. Though the applications I tried this with are of a modest nature, merely.
Something sophisticated as SDL may not work with, since it makes certain assumptions, as you said.

Edit: Archive fixed.

Attachments

  • Filename
    crt.zip
    File size
    381.06 KiB
    Downloads
    37 downloads
    File comment
    various versions
    File license
    Fair use/fair dealing exception
Last edited by Jo22 on 2023-01-30, 09:59. Edited 1 time in total.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 17 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

I just had a look at the old HX DOS Extender page, because of Dosfreak's link to the most recent version (thanks again!).
From what I can tell, many of the classic Windows components are being available in HX DOS Extender.

Edit: The page also mentions that dll. Also interesting is the "Win32 API Emulation" part.
There's so much information to learn from, imho. It needs time. I just wished my mind wasn't so limited.
Anyway, as a consolation, the information we collect here for Win32s compatibility can be useful to others either way.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 18 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

This is interesting! Odin (o.8.9) on OS/2 Warp can execute the MZ700WIN* binaries (Win32 EXEs)
with the MSVCRT dependency just fine (my compile with an relocation table and the original file),
but has trouble with the CRTDLL legacy version of my compiled binary.

Apparently, the latter library is not part of Odin, despite the existence of an alias for a "CRTDLL32.DLL".
When I borrowed the DLL in question from NT 3.51 and stored it as CRTDLL32.DLL in ODIN\SYSTEM32, it worked fine.
The other related files Odin has included are: Msvcirt.dll, Msvcrt.dll, Msvcrt40.dll..

Msvcrt20.dll is missing, too, which was used by Visual C++ 2.0, another popular compiler of the early Win32 days.
- There are two versions of the runtime library, one for normal 32-Bit Windows and one for Win32s.

This is interesting in sofar, because I assumed only the 9x line was missing the CRTDLL in the standard installation.
I had assumed that both WINE and its related projects, like Odin, have that ancient DLL shipped.

Alas, it's not the case. Popularity is more important than age or historic relevance, I suppose.
That dreadful MSVCRT is everywhere.

On the other hand, the classic MSVBVM60.DLL (around since Windows 98) is still not available in WINE 8.0. 🙄

(*That's an old emulator written by a Japanese author I use for testing. The final release was in 2000.
It's one of the late 90s emulation projects requiring MS VS C++ 5/6 and DirectX 2/3.)

Edit: Typos fixed.
Edit: Formatting fixed. My apologies for anoher edit, I have trouble to concentrate somehow.
Edit: I forgot to mention: Odin is an Win32 compatibility layer for OS/2. Similar to Win32s, which is the same to Windows 3.1x.
However, Odin is more complete and has support for DirectDraw and can use DIVE API (OS/2's equivalent). Odin is available here: https://ecsoft2.org/odin

Attachments

  • mz7win_mscvrt_b.png
    Filename
    mz7win_mscvrt_b.png
    File size
    57.57 KiB
    Views
    1039 views
    File license
    Fair use/fair dealing exception
  • mz7win_mscvrt_a.png
    Filename
    mz7win_mscvrt_a.png
    File size
    58.1 KiB
    Views
    1039 views
    File license
    Fair use/fair dealing exception
  • mz7win_crtdll-error.png
    Filename
    mz7win_crtdll-error.png
    File size
    85.5 KiB
    Views
    1039 views
    File license
    Fair use/fair dealing exception
  • mz7win_crtdll.png
    Filename
    mz7win_crtdll.png
    File size
    57.47 KiB
    Views
    1039 views
    File license
    Fair use/fair dealing exception

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 19 of 21, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Update. Here are the files of the MZ700Win emulator, since the original website nolonger exists.
I've also attached the Win32s compatible binary. If Windows 3.1x ever gets DirectDraw, it may work.
Edit: Provided, that the "RtlFreeHeap" problem is solved, also.

Sharp's monitor is not included. It's not needed for testing, also: There's a substitute, "NewMon", created by fans.
The emulator also has an internal monitor, which is sufficient for testing and automatically activated if a monitor file is missing.

Attachments

  • mz700win_compile.png
    Filename
    mz700win_compile.png
    File size
    33.22 KiB
    Views
    1010 views
    File comment
    Visual C++ 5.0 on Japanese Windows 98SE
    File license
    Fair use/fair dealing exception
  • Filename
    mz7_052s.zip
    File size
    114.76 KiB
    Downloads
    32 downloads
    File comment
    mz700win source (original, unaltered)
    File license
    Fair use/fair dealing exception
  • Filename
    mz7_052.zip
    File size
    144.3 KiB
    Downloads
    36 downloads
    File comment
    mz700win program (original, unaltered)
    File license
    Fair use/fair dealing exception
  • Filename
    mz700win_with_reloc.zip
    File size
    169.87 KiB
    Downloads
    40 downloads
    File comment
    My binaries of mz700win (MSVCRT, CRTDLL) w/ .reloc section
    File license
    Fair use/fair dealing exception
  • Filename
    font.zip
    File size
    1.74 KiB
    Downloads
    27 downloads
    File comment
    Font file
    File license
    Fair use/fair dealing exception

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//