"Have you ever wondered what it takes to convert a 16 bit application from the very first version of Windows, release in 1985, to run as a native 64 bit application in 2021".. well.. I definately never wondered that.. but that won't stop me from enjoying this :)
Well my employers Programm started as DOS programm(Charakterbased WIMP) and became a Windows 95 Programm (Windows API based) and then an NT4 Programm It's not so difficult...It currently doesn't run below Windows2000 , yet we still have some technical debt ...like Unicode is about to be done...while it is should have been done since 2009....
I did so much of this crap back in the day, from 16 to 32, that I knew what had to change by heart. I recently ported a 32-bit oldie (originally 16-bit) to 64, and it was painless. I'm so happy I retired from coding for a living; it's a much better hobby!
As recently as about 2010 I found a 32/64 bit pointer bug in a 3rd party UI library we were using. I reported the bug to the vendor and then because I was the only real email address they had I started getting invoices :-\ Being a very large company it took me months of emailing various people to get someone else to take responsibility for them.
@@davidtaylor6124This is when you email someone high up in finances and tell them that the vendor is sending you invoices despite the fact that you're not supposed to see those. That usually works, though I haven't had to use that more than 2 times, and that was at the same company, so I don't know how well that works outside of that environment.
It's too bad Microsoft doesn't have a "fat binary" (or "universal binary") system like Apple to allow one executable to run on multiple architectures. It would be fun to have one .exe that runs natively on 16-bit Intel, 32-bit Intel, PowerPC, Alpha, MIPS, 64-bit Intel, 64-bit Itanium, etc.
@@NCommander PE have MS-DOS stub which is a valid dos application. So at least you can do is to have application that works in both Windows and DOS. And I definitely remember seeing such apps in the wild.
@@etopowertwon IIRC those were limited to text only ones that could run in DOS as DOS apps but when launched within Windows were Windows apps despite looking like a DOS text app in a window. Probably have seen some running on point of sale systems during the years when POS was transitioning from DOS to Windows. If the cashier user software could be written and compiled once to run on both older DOS POS systems and newer Windows POS systems, it would reduce support headaches by having a single code base. That would also help with customer retention by supporting older hardware until the demands of retail stores outstripped the capabilities of older POS systems.
@@KookoCraft to an amount that is absurd for the .001% that wants it or would be affected by it. Microsoft did it right by supporting it OS side... the problem is they dropped that support. because again... .001% better to inflate the os 100mb, then every executable by 10mb.
I believe this is why Cardfile had custom assembler disk DOS routines: "createbitmap may have caused disk swap, make user reinsert disk" -- it relied on the functionality to simulate a two-floppy system on a single-floppy system. Cardfile was not written to read the entire file into memory because it ran in real mode and each card could have a bitmap up to 64k in size. You could have replaced with stdio C calls easily.
Good catch. There's actually a few other places where it uses assembly for some string manipulation functions. It would be straightforward to rip the ASM for C code, but it would still probably be 1-2 hours of fiddling.
@@NCommanderIf you search deep enough on old SDK and DDK discs you are likely to find the last version of MASM to support 16 bit x86 assembly . Many MS DDKs over the past 23 years included the exact compilers used for building the OS itself .
18:50 - The 16-bit Intel compatibility is how I run a web browser on my PowerPC NT 4.0 system. The latest version of IE for PowerPC was 3.x, which is terrible. IE5 was available for Windows 3.1 16-bit, and it runs just fine on NT 4.0 PowerPC.
@@AgeofReason well, ubuntu is bloated, and windows 8.1 is just a weird hybrid child of 7 and 10. arch can probably be decent if you manage to get everything set up completely perfect, and i'd say debian is an alright distro. but in this case, i was referring more to the usage of a less-commonly-used built of windows nt 4.0
This does kind of make me wish that Olivetti had capitalised on the Archimedes to make them ARM-based Unix workstations. I can imagine it now. "Windows on ARM goes way back further than you'd imagine, with Windows NT4 being released for ARM for the Olivetti Phoebe workstations. Libraries released by Acorn and Olivetti and now hosted by ARM made compiling these 16 bit X86 applications for 64 bit ARM way easier than I thought it would be!"
This is interesting, my dad uses a vector drawing program built for Windows 3.1, Macrografx Designer 3.1, to manage the blueprints for his house, he is constantly using it, with his new machine, running Windows 10 64 bit, I noted that MS has dropped support for running 16-bit programs, I had to set up a Win7 32-bit VM and have him run it in that environment, it works good enough for him. He has tried to switch to other programs, but this is the only drawing program he has been able to use effectively, and now it is a bit late to change....
See if that application works with OTVDM (be sure to enable virtualization-based hardware accelration since by default it uses the 386 emulation core from MAME)
Yeah, software industry simply has not enough professionality anymore to make early as good quality software as back then. I refuse to even install Windows 10, but good that you are finding a way to run old good quality software on it.
That's really funny, my dad used to use a billing program for his medical practice that only worked with Windows XP back when I built him a new Windows 8 PC for his office. I ended up using a winXP VM for him and it worked really well for him while he needed that solution still.
This in combination with the recent GTA debacle means that when I hear a company say we can't make systems backwards compatible they either don't currently have staff with the knowledge/ don't want to hire one, or it means that someone will actually have to put in the effort. And before you say well they lose money to the resellers.... They have the money to start their own used stores
with modern programs, many dynamic and static libraries would also need to be fixed as well, also the microsoft win32 api is extremely different now and many guis are also built with things like wxwidgets, and c++ standards are slightly different as well
its not that it cannot be done technically, it cannot be done profitably i havent watched the whole video yet, but if its 8 hours for a hello world, it would probably be thousands of hours for a game sized project lets assume its a rather optimistic 5000 hours and the cost of development is 50 bucks per hour thats at least 50k in expenditures for barely any gain
That's game consoles, where, historically, the software is directly driving the hardware and each version of the hardware is commonly not even the same CPU instruction set, let alone memory model, graphical features, etc. Microsoft did the work and had a team working for years on getting old games running correctly on new systems at no additional cost to the user, while Sony and Nintendo instead required the developer to do the work to create (and sell) the port. The latter certainly makes more sense to investors, so I can hardly fault them for that, especially when it was never an expected feature before Microsoft.
This video was in my recommendations and actually I've wondered before why it's not so easy to run older programs on newer OS'es. I lack the skills to find this out myself, so I like you investigating the problem. I also like your approach, you just start and patiently tackle every hurdle that you come across. On top of that, you have a great relaxing voice to listen to and do a great job explaining. Although this is not my main area of interest, this is real quality content. Keep it up man.
This reminds me of a utility I needed which was available on the Internet only as a C source file. On double-clicking the source file, it opened in Visual C++ 6.0 (which I had installed on my XP PC), and it compiled and ran just fine after changing just one line. After the fact I realized that the source file was actually written on and for the Amiga. It still ran happily on Windows XP. However, it was a command line application with no GUI which, as far as I remember, only served to convert one file format to another.
@@davidtaylor6124 yeah, though I have mixed feelings about the small size of the standard C library, it's certainly been very effective over the decades. Security issues (strcpy, scanf, etc) aside.
Great job on the video, it was interesting following the live stream and like a champ you made it through and complied it for so many OS. Definitely look forward to seeing you port more Ancient Windows applications to modern or specialized platforms. MIPS definitely doesn't look like fun.
There is one more step I can see you could go, which is to have the XP+ versions opt-in to themed controls (that always bugs me about older apps that never got updated to do so).
Great recap. I always love your videos! Maybe one of these days, the scheduling planets will align so I can attend a live stream for reals. Good job, man! 😺
It's pretty crazy what you put through in this project. I'm very glad that somebody really did it, because i'm tired that windows come with a lot of crap that we don't use. If i had to buy an windows it will be you're windows project :)
I have a Itanium I HPi2000 server that I bough new some time in the very early 2000's. To this day it is still the most expensive computer I'd ever spent my own money on. Last time I powered it up (10 years ago?) it would boot into NT but shut off after about 10-15 minutes. Most probably an issue in the power supply that may be easy to fix.
That sounds like thermal overheat production kicking in. You should be getting a BMC log information about it. If the plastic guides in the case aren't properly installed, it gets very toasty, and then shuts down.
You don't have to DRAW assets when you just missing a converter. Just copy them from screenshots. I once had a problem with designing a simple Windows UI. I compared my app to a one built in Windows. I forgot which one now. My app looked dull because no icons. So I took the simplest path - I made a screenshots of the native app, moved the icons to GIMP, set transparency with color to alpha tool and bang, my app looked exactly like the native one without a single pixel drawn by hand. As for the timing - if whole process took you about 8 hours, this would probably take you no more than 30 minutes, downloading and installing GIMP included ;) Yes, I like GIMP ;) And I can't draw at all, I just use GIMP to build icons from images.
Seeing what the task of porting an app to the newest version of Windows from the oldest version was rather interesting. I do wonder if "every released version of Windows" mentioned at the end includes the mobile/phone versions. That'd be interesting.
Yeah, the CE family of Win32 program file formats are fun to work with, but the debugging tools are sorely lagging . Windows Phony 7 (based on Zune) was a disaster of uselessness. Windows Phone 8 was a version of Desktop Windows artificially locked to running a useless subset of code that would be distributed through Microsoft's app store.
@@johndododoe1411 Windows Phone 8 was basically just the NT kernel as far as desktop components go. 10 was more like a locked-down version, particularly with how limited Continuum was.
You should get that ex Microsoft engineer that has a TH-cam channel to help you with this stuff, he used to develop with windows on risc platforms so he is the right guy for the job.
Late to the party, informative! I had a range of in-house 16-bit monitoring applications I'd developed in Delphi and ported them to 32-bit back in the day. Although Borland had done a fantastic job of allowing you to port existing applications, I'd made extensive use of functions directly calling the Windows subsystem. Suffice to say, it was still a chore to successfully recompile and I also ran into you problem of functions that didn't exist (or were renamed, took different size parameters etc.). One of my _"just for fun"_ projects I made was a Delphi custom control for the Task Dialog (introduced in Windows Vista) for Delphi 7. Besides supporting the underlying native dialog, I built a complete emulation of the dialog for earlier Windows OS's (well, Windows 2000 & XP) that necessitated coding *more* custom controls. Yeah, you could say I got rather carried away.
Love videos on when new tech meets low tech. There used to be a program that was shareware back in the 90's that after installed It could take any of your programs and optimize them to run better with less memory leaks. Sadly they were sent a stop desist legal notice that they are voiding copyright law. lol so sad. great concept though.
Thanks for this condensed recap. I watched some of the live stream, but 8 hours was too much for me. This was much more accessible. For porting WineMine, Could you use the bitmap files from the version meant to run under Wine, instead of the Windows 1.x port?
I actually considered doing that, but I couldn't find the original Winemine source code when I looked for it. It's appartantly no longer part of WINE, and I was like "yeah, I don't want this to be me googling for 30 minutes"
@@NCommander I found a project called "Adapted WinMine Source for Teaching Win32 API Programming". The source file includes bmp and ico files. Maybe a follow-up video could include it? Also, from what I could find, the issue with the bitmaps seems to be Windows 1.x/2.x doesn't support DIB bitmaps, so the bitmap formats are different between 1.x/2.x and later versions of Windows.
My office has some applications that have been running on windows ME or XP for 20ish years now, and this video has renewed my confidence that we CAN make those apps run on windows 11!
@@NCommander in this case I think it's a matter of certain protocols available in older operating systems, but I'm confident I can find a way to accommodate them
Adding OS/2 to the mix was a nice touch. :) To try more processor architectures, Workplace OS could run 16bit Windows on PowerPC. Assuming you can get your hand on both a PowerPC and one of the few pre-releases of Workplace OS. And I'd love to see the OS/2 port, of course. One of my few regrets about my otherwise not too excessively wasted youth was that I didn't learn OS/2 programming back then.
Pro tip: Get an MSDN documentation CD from before 1999 and use the included guide for porting OS/2 programs to Windows, only in reverse. Also remember that GDI was called GPI (even in Windows XP internals).
@@johndododoe1411 Oh, that's a good idea. Thanks :) I was looking for information comparing the APIs, but I hadn't thought of looking at Microsoft's porting guides.
8:05 System.fon is a variable-width raster font, sadly. When you installed high-resolution video drivers on Win3x, they would often have a "Large Font" variant of the driver, which swapped system.fon for an equivalent with larger glyphs. Pretty sure 3.x, 9x , NT, 2K and even XP used raster fonts for all UI widgets, ClearType on XP notwithstanding. What a shamozzle! :D
You're supposed to make sure you have sizing to work regardless of fonts (this is one of the main reasons why German was one of the first languages that Microsoft releases betas for since statistically, it's one of the more verbose languages by character count.
@@NCommander For sure! I was mostly just surprised that they used a bitmap font by default for so long. (Although given what you covered in the video, maybe less surprised!)
Pretty smooth it went I'd say! The only thing I don't really like is modifying things for a higher WinAPI version, this can be a source of typos and bugs. Instead I'd go with a wrapper-header approach, say instead of replacing MoveTo() with MoveToEx() everywhere I'd just write an inline MoveTo() calling MoveToEx() itself (won't really work in some other cases though).
Now try to do that with an application from the very first next step os up to the latest macOS release, it’s surprising how a lot of the core api hasn’t really changed that much, and I know of people who marinated some applications this long that said they really hadn’t to do substantial changes to their code base
I don't think that's true anymore, if it was ever really true? I don't know about NextStep, but Mac OS 1 software was written in Pascal, officially. You should have been able to use C but it would likely not be, and some point you would have to port that to C. But let's say you've gotten to a more popular "classic" Mac OS 7, that would port to the OS X Carbon API pretty easily, since that was the intent (probably about the effort of windows 16 to 32bit at worst). The problem is,regardless of Next or Classic Mac, that the, as far as I know, only UI API of 10.0, Carbon was removed in OS 10.15 Catalina, and Carbon to its replacement Cocoa is *not* an easy port. You could probably also hit things like the permission hardening in various versions. Apple, for better or worse, have not been as backwards compatible as Microsoft.
@@SimonBuchanNz note the capitalisation and spacing, they’re actually only referring to OSX under the new name, not the Classic OS. And even core system UI elements like the colour and font picker are unchanged from NeXT, Quartz is a descendant of Display PostScript (and can still, with the right interpreter software, export the entire screen into a PSD with every window its own layer; just like NeXTSTEP could save and send a PostScript print document of the GUI to a connected printer) so I wouldn’t be surprised if some third party applications can still work with minimal tweaking. OSX has Swift now but last I checked (which was a few years ago) there was nothing stopping you from using legacy Objective-C code.
@@kaitlyn__L they said "from the first next step os..." so, no, I don't think they were saying from the first branded as "macOS" (which was only somewhere around 10.12ish, IIRC? Hardly impressive if it was what they meant) Yes, I'm aware of Quartz. It was introduced in OS 10.0, and isn't a common or sufficient API to target: it's a 2d graphics library, not a UI library. (Or you're talking about the compositor, thanks Apple for the overloaded name). You *might* be able to compile a very specific type of application with entirely custom UI components on 10.0 up to 11.x, but I'm very suspicious. On the other hand, it's very likely that many Windows 95 samples compile on current Windows (modulo compiler fixes in practice), and that Windows 1.0 samples need only minor changes. Again, this isn't *intrinsically* a good thing, the API is often quite bad in comparison when ignoring the history (11 parameters to CreateWindow!?), but it's the users that really pay the price: losing access to older software, vs worse quality on average for native apps. Not sure why you're bringing up iOS, it's lineage isn't that relevant or interestingly long here.
@@kaitlyn__L You see NeXTSTEP's influence all over modern macOS with so many of the APIs starting with "NS". I know Apple is strongly pushing people to Swift, but Obj-C still has its place - I liken it to how even Python programmers sometimes use C-based libraries for performance or compatibility reasons.
Given that Microsoft had recently discontinued development of NTVDM with the release of Windows 11, nobody has rereleased any 16-bit Windows games designed for Windows 1.0, 2.0, 3.0 and 3.1 on digital distribution platforms like Steam and GOG via OTVDM to do the same thing that DOSBox had been doing for rereleasing MS-DOS games for years.
The only thing I would like to see here additionally is updated GUI to match those versions of Windows you're running those apps on ;) Would be cool to see correct GUI elements (size, fonts, etc.) in NT and 11!
What's interesting about coding is how there's 1000 ways to do the same thing. This really shows how amazing Windows is, there are games and programs from Windows 95 that I can literally just double click and run, and it runs. Somehow, it just works. Whereas there's other programs made for just a different version of the same windows that will throw a fit if anything changed.
I spent months for a company doing this for an industrial controller application. It was made of multiple modules that cooperatively multitasked and shared pointers over DDE. Had to reimplement 16-bit memory model and work around a lot of limitations. Good project though
It might be cool if you could write something for LLVM, wherein it takes the original executable, and outputs a converted appropriate binary for your target platform. I know a few people have tried to do do some 16-bit emulators like this, but ran into issues. namely that the game was writing code into memory and expected to be able to branch to it and run it.
In my experience, I just copy paste the source code, re-add all the objects, and go through changing all the syntax and code, line by line. Essentially re-writing everything, but having a reference of intended functions.
Why not use #define macros to generalize all the porting, and make via conditional compilation a way to compile any source files on any compiler version and target bitsize. Even resource files and assembly files have support for it possibly at least in the more modern tools. But the macro approach makes your translation procedure much more well documented, generalized and faster, less mistake prone and flexible. Porting the interupt calls sounds like a by hand procedure when moving to 32bit. MASM is abandonware and I think you can safely find it as such. Using Borland for the visual assets is a great idea or even writing a tool to parse the old files and translate them yourself, given graphics files are not too complex. Anyway cool project, well done
MASM is not "abandoned", but the old linker it is. Strictly speaking, all interrupt stuff can be moved just from binaries and linked executables, but no one knows enough about microsoft obscure win16/32 apps. One of the most annoying things are the timer calls from old apps, most are only delays and modern cpu's heat a lot wasting time in those loops.
Honestly, the main reason I didn't was because this topic was virtually undocumented. There are some pointers in the VC++4/6 documentation, but it wasn't compherensive so I had no idea how complex this would be. Also, for comparsion sake, its easier to see how each one is different on Git.
@@NCommander it's sad microsoft has not preserved the old MSDN documentation. I remember CDs and DVDs full of it years in the past. Now that the job is done, you are right, some diffing could easily convert the work you already did to macros and conditional compilation. In a way, unless still needing to support old Windows, it just muddies up the code. But just for the fun of having portable source, might be worth it, as well as to aid future projects
@@bigalejoshileno the old ml.exe is indeed what I meant. There are a bandonware sites with downloads of the latest ML supporting 16bit. Legal gray area but its not considered IP that microsoft is interested in at all anymore
@@NCommander WinCE was an unfortunate contraction, which is likely why Microsoft soon changed the name to Pocket PC. WinCE 5 was still holding out as the OS on many GPS receivers, mainly running CoPilot or iGO or some proprietary navigation software. I managed to accidentally erase the software on a RightWay RW200. I figured out how to bypass the built in nav software by using the unit's built in option to change the navigation executable to launch the WinCE GUI instead. Got something with Chinese and poked the wrong button. Oops! Then I figured out how to install a version of iGO to the internal storage, which was good because the CoPilot it came with was terrible.
This is just amazing - This summary video highlights reel is too much fun - even if YOU didn't have much of it making it. lol The vagaries of inter-generational backwards and cross platform support is interesting.
You missed a trick. There was actually a library that mapped the Win16 API onto 16-bit Presentation Manager, Micrografx Mirrors. You could have used that and built an actual (16-bit) OS/2 program.
@@NCommander It was the reason why I switched to having my OS, Dev Env, mobile phone, and everything else setup in English, because they actually translated EVERYTHIGN to German. Even the names of "Create objects for ..." "Application", "Server", etc. in the "Create new MFC application" dialog.
@@der.Schtefan German is actually one of the first languages targetted for internationalization, because, statistically, it has the longest words per any latin language, so if you translate to german, you'll findmost, if not all the UI layout issues. (the other major ones you see is generally arabic for right-to-left writing, and Chinese or Japanese for unicode support (or multibyte characters in older languages))
Lol Linux requires no changes, you can literally bring a statically compiled executable from the earliest version to today and it will run fine. Linus has committed to never breaking userspace. Generally tools to build software are backward compatible as well.
The project files for this have been uploaded here: github.com/NCommander/windows-1-apps-to-64-bit
Cool, I'll try porting to Itanium once I get a hard drive replacement.
Cool!
You should try and port a director game to 64 bit. It would be an interesting challenge.
rather rewrite the program then this, it will be easier
I was gonna ask that
"Have you ever wondered what it takes to convert a 16 bit application from the very first version of Windows, release in 1985, to run as a native 64 bit application in 2021".. well.. I definately never wondered that.. but that won't stop me from enjoying this :)
I wondered that some time ago. When I tried the Windows 3.1 file manager on Windows 10 (Microsoft recompiled it.)
Like how every ATM in Sweden seems to run on either OS/2 or NT 3.51.. 🤔
@@savagesarethebest7251 Really?
I think they mostly run on XP/POSReady 2009 here in Germany.
Well my employers Programm started as DOS programm(Charakterbased WIMP) and became a Windows 95 Programm (Windows API based) and then an NT4 Programm It's not so difficult...It currently doesn't run below Windows2000 , yet we still have some technical debt ...like Unicode is about to be done...while it is should have been done since 2009....
It's Autism awareness month
I did so much of this crap back in the day, from 16 to 32, that I knew what had to change by heart. I recently ported a 32-bit oldie (originally 16-bit) to 64, and it was painless.
I'm so happy I retired from coding for a living; it's a much better hobby!
As recently as about 2010 I found a 32/64 bit pointer bug in a 3rd party UI library we were using. I reported the bug to the vendor and then because I was the only real email address they had I started getting invoices :-\ Being a very large company it took me months of emailing various people to get someone else to take responsibility for them.
@@davidtaylor6124 Was your company just not paying for it XD
@@davidtaylor6124This is when you email someone high up in finances and tell them that the vendor is sending you invoices despite the fact that you're not supposed to see those. That usually works, though I haven't had to use that more than 2 times, and that was at the same company, so I don't know how well that works outside of that environment.
It's too bad Microsoft doesn't have a "fat binary" (or "universal binary") system like Apple to allow one executable to run on multiple architectures. It would be fun to have one .exe that runs natively on 16-bit Intel, 32-bit Intel, PowerPC, Alpha, MIPS, 64-bit Intel, 64-bit Itanium, etc.
I've always been surprised they *didn't* do that for Portable Executable; they were very clearly planning multiple ports from day 1.
@@NCommander PE have MS-DOS stub which is a valid dos application. So at least you can do is to have application that works in both Windows and DOS. And I definitely remember seeing such apps in the wild.
@@etopowertwon IIRC those were limited to text only ones that could run in DOS as DOS apps but when launched within Windows were Windows apps despite looking like a DOS text app in a window. Probably have seen some running on point of sale systems during the years when POS was transitioning from DOS to Windows. If the cashier user software could be written and compiled once to run on both older DOS POS systems and newer Windows POS systems, it would reduce support headaches by having a single code base. That would also help with customer retention by supporting older hardware until the demands of retail stores outstripped the capabilities of older POS systems.
wouldnt that increase binary size
@@KookoCraft to an amount that is absurd for the .001% that wants it or would be affected by it.
Microsoft did it right by supporting it OS side...
the problem is they dropped that support. because again... .001%
better to inflate the os 100mb, then every executable by 10mb.
I believe this is why Cardfile had custom assembler disk DOS routines: "createbitmap may have caused disk swap, make user reinsert disk" -- it relied on the functionality to simulate a two-floppy system on a single-floppy system. Cardfile was not written to read the entire file into memory because it ran in real mode and each card could have a bitmap up to 64k in size. You could have replaced with stdio C calls easily.
Good catch. There's actually a few other places where it uses assembly for some string manipulation functions. It would be straightforward to rip the ASM for C code, but it would still probably be 1-2 hours of fiddling.
@@NCommanderIf you search deep enough on old SDK and DDK discs you are likely to find the last version of MASM to support 16 bit x86 assembly . Many MS DDKs over the past 23 years included the exact compilers used for building the OS itself .
@@NCommander We need that cardfile port! I'd certainly love to watch another video.
AKA The infamous, phantom drive ;-)
18:50 - The 16-bit Intel compatibility is how I run a web browser on my PowerPC NT 4.0 system. The latest version of IE for PowerPC was 3.x, which is terrible. IE5 was available for Windows 3.1 16-bit, and it runs just fine on NT 4.0 PowerPC.
Linux is the answer
@@null8507 it may be an answer, but it's a boring one
@@AgeofReason well, ubuntu is bloated, and windows 8.1 is just a weird hybrid child of 7 and 10. arch can probably be decent if you manage to get everything set up completely perfect, and i'd say debian is an alright distro. but in this case, i was referring more to the usage of a less-commonly-used built of windows nt 4.0
This does kind of make me wish that Olivetti had capitalised on the Archimedes to make them ARM-based Unix workstations. I can imagine it now.
"Windows on ARM goes way back further than you'd imagine, with Windows NT4 being released for ARM for the Olivetti Phoebe workstations. Libraries released by Acorn and Olivetti and now hosted by ARM made compiling these 16 bit X86 applications for 64 bit ARM way easier than I thought it would be!"
This is interesting, my dad uses a vector drawing program built for Windows 3.1, Macrografx Designer 3.1, to manage the blueprints for his house, he is constantly using it, with his new machine, running Windows 10 64 bit, I noted that MS has dropped support for running 16-bit programs, I had to set up a Win7 32-bit VM and have him run it in that environment, it works good enough for him.
He has tried to switch to other programs, but this is the only drawing program he has been able to use effectively, and now it is a bit late to change....
See if that application works with OTVDM (be sure to enable virtualization-based hardware accelration since by default it uses the 386 emulation core from MAME)
Yeah, software industry simply has not enough professionality anymore to make early as good quality software as back then. I refuse to even install Windows 10, but good that you are finding a way to run old good quality software on it.
That's really funny, my dad used to use a billing program for his medical practice that only worked with Windows XP back when I built him a new Windows 8 PC for his office. I ended up using a winXP VM for him and it worked really well for him while he needed that solution still.
Or you could try running it on a modern system under WINE.
This in combination with the recent GTA debacle means that when I hear a company say we can't make systems backwards compatible they either don't currently have staff with the knowledge/ don't want to hire one, or it means that someone will actually have to put in the effort.
And before you say well they lose money to the resellers....
They have the money to start their own used stores
Microsoft is very good with backwards compatibility
They just don't want to waste the hours so 2 people are able to use this
with modern programs, many dynamic and static libraries would also need to be fixed as well, also the microsoft win32 api is extremely different now and many guis are also built with things like wxwidgets, and c++ standards are slightly different as well
its not that it cannot be done technically, it cannot be done profitably
i havent watched the whole video yet, but if its 8 hours for a hello world, it would probably be thousands of hours for a game sized project
lets assume its a rather optimistic 5000 hours and the cost of development is 50 bucks per hour
thats at least 50k in expenditures for barely any gain
There are re3 and re3-vc to run GTA 3 and Vice City on modern systems. Of course it's possible.
That's game consoles, where, historically, the software is directly driving the hardware and each version of the hardware is commonly not even the same CPU instruction set, let alone memory model, graphical features, etc.
Microsoft did the work and had a team working for years on getting old games running correctly on new systems at no additional cost to the user, while Sony and Nintendo instead required the developer to do the work to create (and sell) the port. The latter certainly makes more sense to investors, so I can hardly fault them for that, especially when it was never an expected feature before Microsoft.
If you replace “Windows” with “Interface Manager” in “Windows 11”, it becomes “Interface Manager 11” Which ironically has a nice ring to it
Interface Manager XP
@@windestruct Interface Manager Millennium Edition
@@lukemeissner1741 *mistake edition
Interface Manager NT 3.51
Interface Manager 98
This video was in my recommendations and actually I've wondered before why it's not so easy to run older programs on newer OS'es. I lack the skills to find this out myself, so I like you investigating the problem.
I also like your approach, you just start and patiently tackle every hurdle that you come across. On top of that, you have a great relaxing voice to listen to and do a great job explaining.
Although this is not my main area of interest, this is real quality content. Keep it up man.
This reminds me of a utility I needed which was available on the Internet only as a C source file. On double-clicking the source file, it opened in Visual C++ 6.0 (which I had installed on my XP PC), and it compiled and ran just fine after changing just one line. After the fact I realized that the source file was actually written on and for the Amiga. It still ran happily on Windows XP. However, it was a command line application with no GUI which, as far as I remember, only served to convert one file format to another.
Well it's called the standard library for a reason 😉
@@SimonBuchanNz Even so, that's definitely a win!
@@davidtaylor6124 yeah, though I have mixed feelings about the small size of the standard C library, it's certainly been very effective over the decades. Security issues (strcpy, scanf, etc) aside.
I really appreciate that you edited the livestream into its own video instead of just cutting it up into a montage
You're not finished you didn't do the minesweeper one.
I salute you for your bravery and success.
It's also amazing how much backward compatible windows is
Great job on the video, it was interesting following the live stream and like a champ you made it through and complied it for so many OS. Definitely look forward to seeing you port more Ancient Windows applications to modern or specialized platforms. MIPS definitely doesn't look like fun.
There is one more step I can see you could go, which is to have the XP+ versions opt-in to themed controls (that always bugs me about older apps that never got updated to do so).
I didn't actually think about that, but yeah, I could have done that.
Although Win 11 for ARM can run x64 just fine; wouldn’t it be fun to get a native arm64 build? :)
I wonder how it performs. Can you run games for x86-64 well on ARM?
@@iDontProgramInCpp Nope, either missing DX API or just lack or performance in general.
@@iDontProgramInCpp yes, some games do run very well.
This video is really a job application for a senior software engineer
You know, I've spent the last five minutes trying to if you called me old in the most subtle way possible. Bravo :)
@@NCommander thank you for the great video
Windows 2003 supports Visual Studio 2010. I also wrote a tool for converting projects between 2010 2015 2017 2019.
can you may send me the Link to the Tool?
@@BJNFNE search vs-convert httpstorm
@@BJNFNE even the hints get filtered here
The commitment amazes me. This should be more popular.
Very interesting. And that's quite productive for "just" 8 hours I think!
Great recap. I always love your videos! Maybe one of these days, the scheduling planets will align so I can attend a live stream for reals. Good job, man! 😺
It's pretty crazy what you put through in this project. I'm very glad that somebody really did it, because i'm tired that windows come with a lot of crap that we don't use. If i had to buy an windows it will be you're windows project :)
Your
Omg, you're awesome but live chat was sadistic :D
I have a Itanium I HPi2000 server that I bough new some time in the very early 2000's. To this day it is still the most expensive computer I'd ever spent my own money on. Last time I powered it up (10 years ago?) it would boot into NT but shut off after about 10-15 minutes. Most probably an issue in the power supply that may be easy to fix.
That sounds like thermal overheat production kicking in. You should be getting a BMC log information about it. If the plastic guides in the case aren't properly installed, it gets very toasty, and then shuts down.
I actually disassembled a (very) simple windows 1.0 program, converted it to C and recompiled it to 32 bits
Which program you ported to 32 bit?
@@BJNFNE Clock, unfortunatly I've since lost it in a disk crash
You don't have to DRAW assets when you just missing a converter. Just copy them from screenshots. I once had a problem with designing a simple Windows UI. I compared my app to a one built in Windows. I forgot which one now. My app looked dull because no icons. So I took the simplest path - I made a screenshots of the native app, moved the icons to GIMP, set transparency with color to alpha tool and bang, my app looked exactly like the native one without a single pixel drawn by hand. As for the timing - if whole process took you about 8 hours, this would probably take you no more than 30 minutes, downloading and installing GIMP included ;) Yes, I like GIMP ;) And I can't draw at all, I just use GIMP to build icons from images.
Seeing what the task of porting an app to the newest version of Windows from the oldest version was rather interesting. I do wonder if "every released version of Windows" mentioned at the end includes the mobile/phone versions. That'd be interesting.
Yeah, the CE family of Win32 program file formats are fun to work with, but the debugging tools are sorely lagging . Windows Phony 7 (based on Zune) was a disaster of uselessness. Windows Phone 8 was a version of Desktop Windows artificially locked to running a useless subset of code that would be distributed through Microsoft's app store.
@@johndododoe1411 Windows Phone 8 was basically just the NT kernel as far as desktop components go. 10 was more like a locked-down version, particularly with how limited Continuum was.
I understood about 10% of this video...which I'm actually quite pleased about!
You should get that ex Microsoft engineer that has a TH-cam channel to help you with this stuff, he used to develop with windows on risc platforms so he is the right guy for the job.
Daves Garage
dave plummer? lo
Late to the party, informative! I had a range of in-house 16-bit monitoring applications I'd developed in Delphi and ported them to 32-bit back in the day. Although Borland had done a fantastic job of allowing you to port existing applications, I'd made extensive use of functions directly calling the Windows subsystem. Suffice to say, it was still a chore to successfully recompile and I also ran into you problem of functions that didn't exist (or were renamed, took different size parameters etc.).
One of my _"just for fun"_ projects I made was a Delphi custom control for the Task Dialog (introduced in Windows Vista) for Delphi 7. Besides supporting the underlying native dialog, I built a complete emulation of the dialog for earlier Windows OS's (well, Windows 2000 & XP) that necessitated coding *more* custom controls. Yeah, you could say I got rather carried away.
Virtual machines are huge fun and hugely educational. Thanks for your work. Subscribed!
DUDE, YOU'RE A GENIUS!
Love videos on when new tech meets low tech. There used to be a program that was shareware back in the 90's that after installed
It could take any of your programs and optimize them to run better with less memory leaks. Sadly they were sent a stop desist legal notice that they
are voiding copyright law. lol so sad. great concept though.
Name of the program?
@@serraramayfield9230 No idea so long ago. sorry
Thanks for this condensed recap. I watched some of the live stream, but 8 hours was too much for me. This was much more accessible.
For porting WineMine, Could you use the bitmap files from the version meant to run under Wine, instead of the Windows 1.x port?
I actually considered doing that, but I couldn't find the original Winemine source code when I looked for it. It's appartantly no longer part of WINE, and I was like "yeah, I don't want this to be me googling for 30 minutes"
@@NCommander I found a project called "Adapted WinMine Source for Teaching Win32 API Programming". The source file includes bmp and ico files. Maybe a follow-up video could include it? Also, from what I could find, the issue with the bitmaps seems to be Windows 1.x/2.x doesn't support DIB bitmaps, so the bitmap formats are different between 1.x/2.x and later versions of Windows.
@@NCommander It still is part of WINE. It's in the programs/winemine folder in the source tree.
My office has some applications that have been running on windows ME or XP for 20ish years now, and this video has renewed my confidence that we CAN make those apps run on windows 11!
If you've got the source code and if they're in a non-properitary programming language, its entirely doable. Best of luck!
@@NCommander in this case I think it's a matter of certain protocols available in older operating systems, but I'm confident I can find a way to accommodate them
Adding OS/2 to the mix was a nice touch. :)
To try more processor architectures, Workplace OS could run 16bit Windows on PowerPC. Assuming you can get your hand on both a PowerPC and one of the few pre-releases of Workplace OS.
And I'd love to see the OS/2 port, of course. One of my few regrets about my otherwise not too excessively wasted youth was that I didn't learn OS/2 programming back then.
Pro tip: Get an MSDN documentation CD from before 1999 and use the included guide for porting OS/2 programs to Windows, only in reverse. Also remember that GDI was called GPI (even in Windows XP internals).
@@johndododoe1411 Oh, that's a good idea. Thanks :) I was looking for information comparing the APIs, but I hadn't thought of looking at Microsoft's porting guides.
Kudos on the well balanced background music.
This actually serves as a good template for programming your own applications.
Earned another sub - great content, I look forward to watching you do all the geeky things. Woohoo!!
8:05 System.fon is a variable-width raster font, sadly. When you installed high-resolution video drivers on Win3x, they would often have a "Large Font" variant of the driver, which swapped system.fon for an equivalent with larger glyphs. Pretty sure 3.x, 9x , NT, 2K and even XP used raster fonts for all UI widgets, ClearType on XP notwithstanding. What a shamozzle! :D
You're supposed to make sure you have sizing to work regardless of fonts (this is one of the main reasons why German was one of the first languages that Microsoft releases betas for since statistically, it's one of the more verbose languages by character count.
@@NCommander For sure! I was mostly just surprised that they used a bitmap font by default for so long. (Although given what you covered in the video, maybe less surprised!)
Pretty smooth it went I'd say! The only thing I don't really like is modifying things for a higher WinAPI version, this can be a source of typos and bugs. Instead I'd go with a wrapper-header approach, say instead of replacing MoveTo() with MoveToEx() everywhere I'd just write an inline MoveTo() calling MoveToEx() itself (won't really work in some other cases though).
Oooh, is this the summary of the livestream I peeked into recently? Didn’t have the time then, but it sure seemed exciting.
NCommander: 16-bit is one helluva code drug.
It all a matter of segments until someone shoots their eye out.
Now try to do that with an application from the very first next step os up to the latest macOS release, it’s surprising how a lot of the core api hasn’t really changed that much, and I know of people who marinated some applications this long that said they really hadn’t to do substantial changes to their code base
I don't think that's true anymore, if it was ever really true?
I don't know about NextStep, but Mac OS 1 software was written in Pascal, officially. You should have been able to use C but it would likely not be, and some point you would have to port that to C. But let's say you've gotten to a more popular "classic" Mac OS 7, that would port to the OS X Carbon API pretty easily, since that was the intent (probably about the effort of windows 16 to 32bit at worst).
The problem is,regardless of Next or Classic Mac, that the, as far as I know, only UI API of 10.0, Carbon was removed in OS 10.15 Catalina, and Carbon to its replacement Cocoa is *not* an easy port. You could probably also hit things like the permission hardening in various versions.
Apple, for better or worse, have not been as backwards compatible as Microsoft.
@@SimonBuchanNz note the capitalisation and spacing, they’re actually only referring to OSX under the new name, not the Classic OS.
And even core system UI elements like the colour and font picker are unchanged from NeXT, Quartz is a descendant of Display PostScript (and can still, with the right interpreter software, export the entire screen into a PSD with every window its own layer; just like NeXTSTEP could save and send a PostScript print document of the GUI to a connected printer) so I wouldn’t be surprised if some third party applications can still work with minimal tweaking.
OSX has Swift now but last I checked (which was a few years ago) there was nothing stopping you from using legacy Objective-C code.
@@kaitlyn__L they said "from the first next step os..." so, no, I don't think they were saying from the first branded as "macOS" (which was only somewhere around 10.12ish, IIRC? Hardly impressive if it was what they meant)
Yes, I'm aware of Quartz. It was introduced in OS 10.0, and isn't a common or sufficient API to target: it's a 2d graphics library, not a UI library. (Or you're talking about the compositor, thanks Apple for the overloaded name). You *might* be able to compile a very specific type of application with entirely custom UI components on 10.0 up to 11.x, but I'm very suspicious. On the other hand, it's very likely that many Windows 95 samples compile on current Windows (modulo compiler fixes in practice), and that Windows 1.0 samples need only minor changes.
Again, this isn't *intrinsically* a good thing, the API is often quite bad in comparison when ignoring the history (11 parameters to CreateWindow!?), but it's the users that really pay the price: losing access to older software, vs worse quality on average for native apps.
Not sure why you're bringing up iOS, it's lineage isn't that relevant or interestingly long here.
@@kaitlyn__L You see NeXTSTEP's influence all over modern macOS with so many of the APIs starting with "NS". I know Apple is strongly pushing people to Swift, but Obj-C still has its place - I liken it to how even Python programmers sometimes use C-based libraries for performance or compatibility reasons.
Loving the classic music backgrounds.
I wonder if you could port it to windows RT? I also think that messing with Metro/UWP in general might be fun.
Well done, that was an interesting watch :) You seem to have a great deal old software on original media!
ok, that. was. beautiful!
Back in the 90s I ran a render farm on Windows NT on Dec Alphas.... Oh man was that all the pain.
I love the red of the mips windows
it looks devilish almost
I notably set it by hand, to make it look distinct.
@@NCommander It gives me a Ubuntu Satanic Edition vibe, like it's just normal windows but something's off
Given that Microsoft had recently discontinued development of NTVDM with the release of Windows 11, nobody has rereleased any 16-bit Windows games designed for Windows 1.0, 2.0, 3.0 and 3.1 on digital distribution platforms like Steam and GOG via OTVDM to do the same thing that DOSBox had been doing for rereleasing MS-DOS games for years.
Amazing stuff here. So many platforms. Love it.
The only thing I would like to see here additionally is updated GUI to match those versions of Windows you're running those apps on ;)
Would be cool to see correct GUI elements (size, fonts, etc.) in NT and 11!
Amazing! You've earned my sub sir. Can't wait for a sequel!
List of things to buy at the store
- Apples
- Oranges
- Milk
- *Sanity*
They were out of both milk and sanity.
@@NCommander i suppose so.
What's interesting about coding is how there's 1000 ways to do the same thing. This really shows how amazing Windows is, there are games and programs from Windows 95 that I can literally just double click and run, and it runs. Somehow, it just works. Whereas there's other programs made for just a different version of the same windows that will throw a fit if anything changed.
I think it's very cool what you have done here, I don't understand that well some of the technicalities but I appreciate the concept.
What a great content! Thank you. So much enthusiasm right here.
Very interesting.
I spent months for a company doing this for an industrial controller application. It was made of multiple modules that cooperatively multitasked and shared pointers over DDE. Had to reimplement 16-bit memory model and work around a lot of limitations. Good project though
Very neat.. you may get a lot of mileage out of covering TempleOS.. its existence still amazes me
Love the attention to details. Great video.
i can never feel bored on the classic window interface on windows
You should backport something from Windows 10 to windows 1.0-3.0.
oof anticringe
Crazy dedication. Nice job
Kudos Sir, you have my sincere respect!
Very interesting and unique videos! Great channel!
Thanks for the compilation video. Good job on porting to all those systems. I hope one day my skills will have evolved in a way like that.
With practice, you can do cool stuff
Sounds like MS isn't making it easy by striking knowledge articles as the years roll by.
A second part would be cool ! Great video
Fantastic video!!! 👏👏👏👏
It might be cool if you could write something for LLVM, wherein it takes the original executable, and outputs a converted appropriate binary for your target platform.
I know a few people have tried to do do some 16-bit emulators like this, but ran into issues.
namely that the game was writing code into memory and expected to be able to branch to it and run it.
insane video, enjoyed every second of it.
Glad you enjoyed
Holy s**t! now *that* is hardcore tech skills!! (i have a degree in IT) great work dude! 🙂
"adding a bit of compatibility"
You just need to fit the extra 48-bits in.
👍 profesonal dev
And yet, code I wrote on Unix systems back then will compile perfectly now.
In my experience, I just copy paste the source code,
re-add all the objects,
and go through changing all the syntax and code, line by line.
Essentially re-writing everything, but having a reference of intended functions.
I'm gonna make an application for Windows 1.0 now. I used to run that as a kid (on a beautiful monochrome CGA screen) on our 8086.
Why not use #define macros to generalize all the porting, and make via conditional compilation a way to compile any source files on any compiler version and target bitsize. Even resource files and assembly files have support for it possibly at least in the more modern tools. But the macro approach makes your translation procedure much more well documented, generalized and faster, less mistake prone and flexible. Porting the interupt calls sounds like a by hand procedure when moving to 32bit. MASM is abandonware and I think you can safely find it as such. Using Borland for the visual assets is a great idea or even writing a tool to parse the old files and translate them yourself, given graphics files are not too complex. Anyway cool project, well done
Had the same exact idea regarding using macros
MASM is not "abandoned", but the old linker it is. Strictly speaking, all interrupt stuff can be moved just from binaries and linked executables, but no one knows enough about microsoft obscure win16/32 apps. One of the most annoying things are the timer calls from old apps, most are only delays and modern cpu's heat a lot wasting time in those loops.
Honestly, the main reason I didn't was because this topic was virtually undocumented. There are some pointers in the VC++4/6 documentation, but it wasn't compherensive so I had no idea how complex this would be. Also, for comparsion sake, its easier to see how each one is different on Git.
@@NCommander it's sad microsoft has not preserved the old MSDN documentation. I remember CDs and DVDs full of it years in the past. Now that the job is done, you are right, some diffing could easily convert the work you already did to macros and conditional compilation. In a way, unless still needing to support old Windows, it just muddies up the code. But just for the fun of having portable source, might be worth it, as well as to aid future projects
@@bigalejoshileno the old ml.exe is indeed what I meant. There are a bandonware sites with downloads of the latest ML supporting 16bit. Legal gray area but its not considered IP that microsoft is interested in at all anymore
I'm interested in what those ARMv4 target architectures were for, surely there wasn't a Windows Phone all the way back then?
Windows CE ran on Arm
Windows CE and Windows Mobile. Windows phones did exist and were completely different from the Windows Phone disaster.
Windows CE, aka the original Windows Mobile. I did a video about Windows CE (the HP Jornada) abliet with a SUperH vs. ARM processor.
@@nonci6 I wouldn’t call Windows Phone a disaster.
@@NCommander WinCE was an unfortunate contraction, which is likely why Microsoft soon changed the name to Pocket PC. WinCE 5 was still holding out as the OS on many GPS receivers, mainly running CoPilot or iGO or some proprietary navigation software.
I managed to accidentally erase the software on a RightWay RW200. I figured out how to bypass the built in nav software by using the unit's built in option to change the navigation executable to launch the WinCE GUI instead. Got something with Chinese and poked the wrong button. Oops!
Then I figured out how to install a version of iGO to the internal storage, which was good because the CoPilot it came with was terrible.
What die I just see? I mean... thank you algorithm.
Honestly that this can be done at all is amazing to me.
This was great! (Though I don’t think I’ve ever heard anyone who pronounces “DOS” as “dahz”!)
This is a massive achievement. Hats off!
You paid so much effort that I just had to subscibe.
This is just amazing - This summary video highlights reel is too much fun - even if YOU didn't have much of it making it. lol The vagaries of inter-generational backwards and cross platform support is interesting.
Actually about a third is new footage, and the remainder is heavily edited.
IIRC, the typewriter would send an individual line and carriage return to the configured printer with no form feed.
You missed a trick. There was actually a library that mapped the Win16 API onto 16-bit Presentation Manager, Micrografx Mirrors. You could have used that and built an actual (16-bit) OS/2 program.
Fonally a video about this, ive actually been wondering what it would take
Have you ever wonder what it takes to convert a 16 bits application to a 64 bits application?
... "No. The answer is no. But go on..."
Questions you didn't know you needed the answer to until you did ...
@@NCommander I wondered why Windows 1.0 programs wouldn't run on Windows 3.0, but that was 31 years ago. ;)
You are a hardcore programmer! Awesome!
btw, that nov 1983 demo build is from september. someone found a disk of it, but it was ended via magnet
Visual Studio 6.0. OMG. My whole youth just snapped back in an instant! LOOVEE
Was it a flash of compiler errors? :)
@@NCommander It was the reason why I switched to having my OS, Dev Env, mobile phone, and everything else setup in English, because they actually translated EVERYTHIGN to German. Even the names of "Create objects for ..." "Application", "Server", etc. in the "Create new MFC application" dialog.
@@der.Schtefan German is actually one of the first languages targetted for internationalization, because, statistically, it has the longest words per any latin language, so if you translate to german, you'll findmost, if not all the UI layout issues.
(the other major ones you see is generally arabic for right-to-left writing, and Chinese or Japanese for unicode support (or multibyte characters in older languages))
For that MoveTo to MoveToEx migration et al, I would likely create a library reimplementing those removed functions using their counterparts.
Did you try running the executables as-is on Windows 10 32-bit? I seem to remember that someone got them working somehow.
Yeah, I did the original video on getting them working as it ;) (first retrotech video on this channel)
36 years man. It's worth to get up and running on a modern Windows 11.
Out of curiousity, have you considered doing the same for ancient Linux and Mac OS software?
Lol Linux requires no changes, you can literally bring a statically compiled executable from the earliest version to today and it will run fine. Linus has committed to never breaking userspace. Generally tools to build software are backward compatible as well.
xclock from the 80's still runs perfectly fine in modern day x11 (maybe xwayland too but haven't tried)
Was going to port a program I wrote 20 years ago to modern windows. After watching this I just set up a virtual machine.
What?! You didn't cross compile to the mac using Visual C++ 4.0 for Macintosh?
I have disassembled and ported 16-bit DOS programs to modern systems before, it is a trip. :+ )
Way easier with source code lol.