Windows on 68000

[kerravon]

Some of you may be aware that Microsoft Windows is available for both x86 32-bit and 64-bit and ARM 32-bit and 64-bit, and all 4 environments have an msvcrt.dll

And you may also be aware that PDOS-generic from pdos.org has a mini-clone of all 4 environments. Although Microsoft isn't interested in the 68000 for obvious reasons, I am, and most of the infrastructure to port PDOS-generic, including win32 mini-clone capability, to basically anywhere, with minimal fuss from the OS side (the linker pdld needs some work though), is already in place.

As first proof of that, now have a Windows 68000 environment, so you can have PE/COFF 68000 executables running at native 68000 speed on any 68000 environment.

Here it is using qemu-m68k (user, not system), transparently, on Linux:

root@kerravon2-pc:/home/kerravon/w2kshare# ./bios.exe pdos.exe scratch.vhd

bios starting
type in "dir" to get a list of files
type in "type" to show the contents of a file
type in "e/me/uemacs file.txt" to edit a file
ctrl-x, ctrl-s saves; ctrl-x, ctrl-c quits
about to execute program with entry point 3FB3A02C
welcome to PDOS-generic
running as pdos.exe
before printing parm
argv1 is scratch.vhd
about to open disk
done open
lba is 80
fat type is FAT12
about to call app at address 3E457954
welcome to pcomm
type help for help

enter a command
:pdptest.exe abc def
about to call app at address 3E54D000
welcome to pdptest
main function is at 3E54D1EC
allocating 10 bytes
m1 is 3E456030
allocating 20 bytes
m2 is 3E456080
stack is around 407FF9D4
printing arguments
argc = 3
arg 0 is <:pdptest.exe>
arg 1 is <abc>
arg 2 is <def>
return from app is hex 0

enter a command
exit
return from app is hex 0
return from called program is hex 0
enter command, exit to exit

bios exiting
root@kerravon2-pc:/home/kerravon/w2kshare#


Executable pdptest.exe was built with pdpclib/makefile.s68

bios.exe was built with generic/makebios.l6g and that makefile points to the other things.

The makefiles use tools available on the PDOS/386 hard disk image at pdos.org

And the executables I produced myself can be found in a temp.zip attachment here:

https://eab.abime.net/showthread.php?t=120813


Next stop might be Windows on the IBM mainframe. But I was planning on getting z/OS PCDOS out the door first, and that's waiting on Dat from Vietnam to debug.

[Gigasoft]

Well, that sounds like fun. What is the upper byte of those addresses for? Will you support multiple tasks, and if so how will function pointers work across modules when you have multiple instances of a module?

[iansjack]

What is the upper byte of those addresses for?

Good question. It would make sense on a 68012 or above, but not on a plain 68000. The byte could be used for other purposes (some OSs did so), but surely that would then limit the program to the 68000 rather than its later variants.

I wonder which processor the OP was emulating. (Edit: By default qemu m68k emulates a ColdFire processor, which is 32-bit. So it looks like basic Amigas and Atari Sts are left out of the equation. Not quite "any" 68000 environment. TBH, to get any useful Windows programs running with only 16MB of RAM - or less than 1MB on a basic Amiga - would be impressive in itself.)

[kerravon]

Well, that sounds like fun. What is the upper byte of those addresses for? Will you support multiple tasks, and if so how will function pointers work across modules when you have multiple instances of a module?

When you referred to "upper byte" I thought you were talking about the mainframe being AMODE 24 sometimes. But now I think you're talking about the address lines of a real 68000 CPU not existing. They exist on later processors, so the software will make use of that with no change required. Just give it any 68020 with more than 16 MiB of memory and the address lines will start being used. So - that's what it's used for.

And no, I personally have no intention of "supporting multiple tasks". I am only trying to run a single Win32 executable on any environment. If anyone wants an enhancement above and beyond that, they will have to either do it themselves or pay me a shitload of money to do it for them.

[kerravon]

What is the upper byte of those addresses for?

Good question. It would make sense on a 68012 or above, but not on a plain 68000. The byte could be used for other purposes (some OSs did so), but surely that would then limit the program to the 68000 rather than its later variants.

I wonder which processor the OP was emulating. (Edit: By default qemu m68k emulates a ColdFire processor, which is 32-bit. So it looks like basic Amigas and Atari Sts are left out of the equation. Not quite "any" 68000 environment. TBH, to get any useful Windows programs running with only 16MB of RAM - or less than 1MB on a basic Amiga - would be impressive in itself.)

I consider a C compiler to be "useful". And the C compiler I use - a derivative of GCC 3.2.3 - to be "useful". It opens up a world of development. The GCC compiler that I ship is approximately 3 MB in size, so well within the 16 MB you cited above.

SubC is much smaller - 85k. I also consider that to be useful, to the extent that it is better than having to develop in assembler. And yes, that should run within the confines of a basic Amiga with 512k. Although SubC doesn't have a 68k target currently:

D:\devel\subc\src\targets\cg>dir /b
cg386.c
cg386.h
cg8086.c
cg8086.h
cgarmv6.c
cgarmv6.h
cgx86-64-darwin.c
cgx86-64.c
cgx86-64.h
CVS

D:\devel\subc\src\targets\cg>


And you'll need a 68000 assembler too - the one that I ship (a derivative of binutils 2.14a) is about 500k, so you'll need a full 1 MB to stand a chance of using this for development (assuming you add 68k as a SubC target - that appears to be about 300 lines of code required, looking at cg386.c - but you need to know what you're doing - I don't). Or find a smaller 68k assembler which presumably exist - I haven't attempted to look, because I don't have an Amiga with a 512k limit. I did have an Amiga 500 circa 1988, but I upgraded its memory to 1 MB. So if some other developer has a need to run in 512K instead of 1 MB they would have to research or write that themselves.

pdld is 140k and not an issue for the linker. xar is trivial in size for the archiver.

So I'm not sure why you think basic Atari/Amiga are left out of the equation - I guess you can simply *define* "useful" as "an executable that is bigger than 1 MB in size". I personally think my "hexdump" program is useful and I use it often. That's considerably less than 16 MB in size too:

2024-07-20 06:18a 3,584 hexdump.exe

[iansjack]

Yes, but the programs you mention aren’t Windows programs, are they? If I want to run gcc on my Amiga I run gcc; no need for a Windows environment. The same holds for just about any of the gnu programs - native versions exist for the Amiga, or can easily be ported.

I still struggle to grasp why I would want to run a Windows environment on an Amiga. Which Windows programs would I want to run that aren’t available as native applications.

I appreciate the work you are doing providing a minimal Windows environment for these ancient machines. It’s just that I see no application for it. To me it is just a curiosity.

[kerravon]

Yes, but the programs you mention aren’t Windows programs, are they?

Yes, they are. Unless you want to specify an alternative definition of "Windows program". I'm actually curious what your definition might be. I have a similar curiosity about DOS - if DOS was ported to be 32-bit, what would it look like, or is that a contradiction in terms? I haven't been able to get a straight answer on that. But that's what triggered off PDOS development.

If I want to run gcc on my Amiga I run gcc; no need for a Windows environment. The same holds for just about any of the gnu programs - native versions exist for the Amiga, or can easily be ported.

First of all, "easily ported" defeats the whole purpose. I'm trying to provide executables.

And what if you're on an Atari instead of an Amiga? Or a 68000 Mac?

I still struggle to grasp why I would want to run a Windows environment on an Amiga. Which Windows programs would I want to run that aren’t available as native applications.

I didn't specifically claim that they weren't available as native applications. Nor did I claim to have any knowledge of what you personally would want to run. Currently I don't provide pdld as a 68000 executable on any environment. If I did, and it was a Win32 68k executable, then that would be the answer, except for the requirement that you personally want to run it - I'm not sure that you personally want to run any 68k that has ever existed - I have no idea. But if I did provide a pdld.exe, I'm curious how long you think it would take to produce a native Amiga version of it. If you can do that in under 5 seconds, I'd like to employ you. I would say the vast majority of people wouldn't even try. Doing a compile of anything is a traumatic experience - it is rare that someone has stuck to the C90 standard. In this case, pdld is C90-compliant, so the trauma is lessened. Although the author may have assumed "long long" exists by default, and you need to provide the NO_LONG_LONG override or something like that to make it compliant. Do you know? I don't - and I'm the guy who distributes the source code. It's apparently a traumatic experience for the pdld author to create his own repository so he gets me to maintain his source code.

I appreciate the work you are doing providing a minimal Windows environment for these ancient machines. It’s just that I see no application for it. To me it is just a curiosity.

I didn't specifically claim that it had an application.

Perhaps if someone puts an Atari ST in front of me, sticks a gun to my head, and says "start coding", I'll say "can I bring my tools across so that I can code in C and my software isn't tied to this one machine?". I have no idea what psychos are out there and what they're capable of. I do know that an Atari forum exists, and I know that multiple Amiga forums exist, so presumably some people are unluckier than me with regards to psychos. I have a computer with 16 GB of RAM running Windows 10 and using a Zhaoxin CPU that was "smuggled" out of communist China.

I will still be able to use my essential tools when the psychos, or zombies, or time travelers arrive. If you click on the links at "Collapse OS" they think we won't have the luxury of an Amiga 500 with 512K RAM. I have no idea whether they are right or not. But I do know that if they are right, and we are forced to use Z80s, my software won't fit in 64k, so I'm screwed until the equivalent of the Amiga 1000 comes out. Is it possible it will collapse down to just 512k so that I am in with a chance of survival? Or really - I need 4 MB to have a chance at running gccami, not 512K. I have no idea. I don't know what collapses look like. I never expected to see Australians fist-fighting over toilet paper either. I'm not sure that actually happened in Australia (I think fist-fights happened in some places though), but the shelves were bare here for months. I had to use sandpaper.

Will that happen with computers after Putin nukes us all? No idea. No idea if Putin will even nuke us in the first place. My crystal ball is broken - otherwise I would have stocked up on toilet paper instead of Chicom CPUs (hedging my bets on the offchance that Intel and AMD have conspired with a drop-dead date on their CPUs).

I tell you what - I'll be laughing if RAM capacity is dropped to 16 MB for some reason. Last Man Standing. I charge $1000/minute for time on my Zhaoxin, and $1000/minute for programming time. Currency depends on who it is that collapsed.


EDIT:

https://www.springfieldspringfield.co.u ... ad-warrior

If you wanna get out of here...
you talk to me.

[iansjack]

In the context of running a Windows subsystem on a computer that doesn't support Windows natively, I would define a Windows program as one that depends upon the Windows API. I don't consider a program that is available natively on the platform in question to be a Windows program just because it has been ported to Windows.

So, for example, gcc is not a Windows program - native versions are widely available for most platforms. Emacs is not a Windows program - the same criterion applies. I agree that there are Windows versions of those programs, but there are also native non-Windows versions. And I see no reason to run the Windows version in a mini Windows subsystem when native versions exist.

The diatribe about "long long" goes over my head. Don't people just use the standard types like int64_t or uint64_t which make it explicit what size your variables are? I find that essential when interfacing with structures of known size - e.g. the structures involved in implementing an ext2 file system.

And - I'm not spending my time worrying about zombies or time travellers.

[kerravon]

In the context of running a Windows subsystem on a computer that doesn't support Windows natively, I would define a Windows program as one that depends upon the Windows API. I don't consider a program that is available natively on the platform in question to be a Windows program just because it has been ported to Windows.

In that case, it is only my programs that do directory manipulations, and thus use kernel32.dll as well as (or instead of) msvcrt.dll that are windows programs by your definition.

So, for example, gcc is not a Windows program - native versions are widely available for most platforms. Emacs is not a Windows program - the same criterion applies. I agree that there are Windows versions of those programs, but there are also native non-Windows versions. And I see no reason to run the Windows version in a mini Windows subsystem when native versions exist.

Even if you personally don't have a reason to run it - I do. I can produce a single Windows executable and run it on a Mac, Atari or Amiga (all of them at native speed - not emulation). I don't wish to maintain executables for every environment - I just produce one and be done with it. If you wish to compile from source - you can do so yourself, but you're likely in a minority, and certainly not in a majority that includes everyone in the world except me. I agree that I'm in a minority that wants to run Windows programs on a 68000 though. That may or may not change. I have no idea.

The diatribe about "long long" goes over my head. Don't people just use the standard types like int64_t or uint64_t which make it explicit what size your variables are?

Nope. For starters - none of the above are in C90 at all. And in C99, the use of the above completely prevents it from being ported to a 36-bit machine. If you had made it int_least32_t or similar, then it will be available on a C99-compliant 36-bit machine. But you didn't. And few do. C99 and above is a joke. The pdld author used:

D:\devel\pdos\pdld\src>grep fast stdint.h
stdint.h: typedef long long int_fast64_t;
stdint.h: typedef unsigned long long uint_fast64_t;
stdint.h: typedef long int_fast64_t;
stdint.h: typedef unsigned long uint_fast64_t;

D:\devel\pdos\pdld\src>

with a fallback option to bypass that for a pure C90 environment (or even a C99 environment that doesn't even have a non-exact 64-bit type available - I'm not sure if C99 requires int_fast64_t to exist - maybe it does if it also requires "long long" to exist).

I find that essential when interfacing with structures of known size - e.g. the structures involved in implementing an ext2 file system.

I managed to produce a FAT12/16/32 filesystem without needing to do that. And my code will work on a 36-bit machine too.

And - I'm not spending my time worrying about zombies or time travellers.

... or any other reason you (or I) haven't thought of where you might end up in a memory-restricted environment and have made zero preparation for such a possibility.

But if you're quite sure you'll always have 16 GB of memory or more available - go right ahead and do what everyone else is doing - ie writing 64-bit applications using humungous amounts of memory.

Because nothing could ever go wrong with a philosophy like that. That's as unlikely as there being a run on toilet paper - again.

[iansjack]

In that case, it is only my programs that do directory manipulations, and thus use kernel32.dll as well as (or instead of) msvcrt.dll that are windows programs by your definition.

I guess you mean the only Windows programs that run under your subsystem. I think most people would recognise that there are quite a few programs (mainly graphical ones) in the wide world that are truly Windows programs rather than ports from other OSs. Some of them have even been ported to other OSs - one thinks of Visual Studio as an example.

I agree that I'm in a minority that wants to run Windows programs on a 68000 though.

We can agree on that. I'd say that you are in an even smaller minority that wants to be able to run the same executable on Amiga, Atari ST and old-school Mac. Given the limited amount of RAM on these platforms many would prefer the leanest executable possible rather than one carrying the overhead of supporting various systems.

The diatribe about "long long" goes over my head. Don't people just use the standard types like int64_t or uint64_t which make it explicit what size your variables are?

Nope. For starters - none of the above are in C90 at all.

My mistake. I don't really use ancient versions of C, but I thought they all provided the "typedef" keyword.

I managed to produce a FAT12/16/32 filesystem without needing to do that.

I'd say that FAT is a rather simpler filesystem than ext2fs, but that's just my opinion. (I'd say a lot of other things about FAT, but most of them would be unprintable in polite society.)

But if you're quite sure you'll always have 16 GB of memory or more available - go right ahead and do what everyone else is doing - ie writing 64-bit applications using humungous amounts of memory.

I'm absolutely sure that I'll always have 16GB (minimum) of RAM available as long as I have computers available. (And I do like to make use of that memory rather than having it idling.) I think my Macs and PCs are more likely to be usable after a hypothetical holocaust then my Amiga. If I don't have a computer any longer - then why would I care about running Windows programs on an Amiga?

I completely understand that you find this sort of stuff fascinating, and good luck to you - long may you enjoy it (as long as you don't come up with silly ideas like a "new Linux standard"). I've spent my life playing with things that are fascinating but totally useless, and continue to do so.

[nullplan]

My mistake. I don't really use ancient versions of C, but I thought they all provided the "typedef" keyword.

They do. long long is a C99 innovation, though. Some compilers have supported it earlier, but some did not. And kerravon would rather compile code with a compiler that is not on the required standards level than brush up his stuff to something less ancient. Well, that is their problem, I stopped caring months ago.

[kerravon]

I agree that I'm in a minority that wants to run Windows programs on a 68000 though.

We can agree on that. I'd say that you are in an even smaller minority that wants to be able to run the same executable on Amiga, Atari ST and old-school Mac. Given the limited amount of RAM on these platforms many would prefer the leanest executable possible rather than one carrying the overhead of supporting various systems.

That's not correct. The Windows executables are all lean. Leaner in fact than both native Atari and Amiga executables, because the use of msvcrt.dll means that the C library is not in the executable. I don't know what Mac does. There is ZERO "support" for Amiga or Atari in the Windows executables I produce. They are pure Win32 executables as if Atari and Amiga never even existed.

That's why my glorified "hello world" PE executable is around 7k in size:

D:\devel\pdos\pdpclib>dir pdptest.exe
Volume in drive D is PAULDATA
Volume Serial Number is DAB2-6E30

Directory of D:\devel\pdos\pdpclib

2025-07-10 08:17a 7,680 pdptest.exe


But with an additional 140k of external unrelated executables, I can create a subsystem for the Amiga/Atari/etc that will run the above PURE WINDOWS EXECUTABLE. It's a different 140k for each platform though, and so a new platform like the Mac would need me to do some work to build my subsystem - and if I use an existing Mac compiler and C library, that should be a simple matter of recompilation. As it is - I normally port PDPCLIB to a new environment first, along with getting pdld to target the executable format (68000 Mac in this instance), so I normally have some work to do. So the 140k may be bigger if I use someone else's C library.

The diatribe about "long long" goes over my head. Don't people just use the standard types like int64_t or uint64_t which make it explicit what size your variables are?

Nope. For starters - none of the above are in C90 at all.

My mistake. I don't really use ancient versions of C, but I thought they all provided the "typedef" keyword.

Yes they do. But C has never guaranteed an exact number of bits in any data type. It has guaranteed some minimums for each type though.

I managed to produce a FAT12/16/32 filesystem without needing to do that.

I'd say that FAT is a rather simpler filesystem than ext2fs, but that's just my opinion.

Tell me the ext2 structure that you think can't be supported on a C90 system with a "long" of 36 bits and I'll show you how I would do it. Noting that with 36 or 32 bits maximum I would expect the entire file system to be restricted to 2 or 4 GiB in size for my code to work.

But if you're quite sure you'll always have 16 GB of memory or more available - go right ahead and do what everyone else is doing - ie writing 64-bit applications using humungous amounts of memory.

I'm absolutely sure that I'll always have 16GB (minimum) of RAM available as long as I have computers available. (And I do like to make use of that memory rather than having it idling.) I think my Macs and PCs are more likely to be usable after a hypothetical holocaust then my Amiga.

That's existing computers. What will new computers look like and how much will RAM cost?

If I don't have a computer any longer - then why would I care about running Windows programs on an Amiga?

You may have a new computer with 512K RAM. It may not be an Amiga. It may be 68000-based and Win32 may be the native OS of the computer. It may be written by Microsoft themselves, because Microsoft are the only ones who had contingency plans for whatever it is that happened - or have some sort of monopoly power.

Also, at the end of the day, 68000 is just one example. I am mainly just showcasing how to run Windows programs on an arbitrary CPU. Microsoft themselves have already demonstrated both x86 and ARM. They have ceded the rest of the market to me. Which apparently includes RISC which the Chicoms seem to be getting involved in. It may be that Russia and the West wipe themselves out, leaving neutral China as Last Man Standing. No idea.

I completely understand that you find this sort of stuff fascinating, and good luck to you - long may you enjoy it (as long as you don't come up with silly ideas like a "new Linux standard"). I've spent my life playing with things that are fascinating but totally useless, and continue to do so.

You haven't mathematically proven that either the "new Linux standard" is silly nor that any of my work is "totally useless". It's outside the realm of mathematical proof, so you can't do that. You can attempt some other form of "proof", but to date it hasn't been sufficiently convincing to me.