I’ve been trading emails with various people from the project after I had made my post, and helping them integrate more of Visual Studio 2003 into the project and working through a few issues to bring far better compatibility to VS 2003.
And the best part is being able to build projects in parallel!
10.2 seconds in parallel!
I haven’t ordered new processors, so the 2.1Ghz parts are… lacking. However being able to use all available cores makes building DOSBox pretty fast.
Restricting the build to a single process takes 1:13 while the full parallel build on this machine takes a mere 10 seconds!
I uh, also saw this on archive.org, which may help people looking for this stuff from the future as old tools get harder and harder to find. Especially bigger editions like the Enterprise Architect version.
That’s right ARM Linux userland! I still have high hopes for Windows on ARM (I have 2 Windows RT devices now!!) although I’m not holding my breath.
Maybe there will be some ARM boards that are suitable for the desktop that aren’t over 1k USD.. That’d be nice.
Interesting trivia is that the Linux Subsystem started it’s life on ARM as a way to run Android binaries on Windows Phone. And true to everything Microsoft does, it got to the point where it could start to run things (albeit poorly) and was summarily killed. Although it’s found life despite the original false start as a general ‘text mode’ subsystem for Windows.
However running Linux binaries on Windows currently just shows that NTOS isn’t as efficient as the Linux kernel when it comes to emulating the Linux ABI. Although this was the original ‘dream’ of the microkernel, and a POSIX subsystem for NT was always part of the original design, although it really was more of a checkbox for GSA contracts, and outside of being able to use pax & vi it really was handicapped by not having BSD extensions, and especially by not having any access to the TCP/IP stack.
EDIT*
I should add these notes from the future past for the future me, when messing around with Windows Server 2019 build 1809 when they finally brought the Linux Subsystem into the fold. Unpacking the distribution and running the ‘setup’ sets it up DIRECTLY into that directory. So put it where you want it.
When you mess that up, you have to use the wslconfig program!
Of note is:
wslconfig /list /all Lists all distributions, including ones that aren’t currently usable. They may be in the process of installing, uninstalling, or are in a broken state.
wslconfig /unregister <DistributionName> Unregisters the distribution from WSL so it can be reinstalled or cleaned up.
This way you can now clean up your mess, and get Linux installed right.
I saw this the other day, VC6 Ultimate. It’s an interesting ‘update’ on the old Visual C++ 6.0 product with an improved UI, along with updated compiler toolchain taken from later versions of Visual C++. Naturally something like this is 1000000% unofficial.
Features include:
Portable and compatible with Win7 / Win10
bye bye regedit, hello .hjson setting file !
also meaning it should not mess with your current install
More compatible compiler
multicore version of VC7.1 compiler (It’s fast)
you can compile with other compilers (64bit), but not debug yet
Real-time highlighting and diagnostics
based on libclang 6.0 and compatible with VisualAssistX
Real multicursor editing
search, sort, number, evaluate, etc. while in multicursor mode
Improved UX and UI
32bit icons, dark skin, lot of visual hints
multi-monitor friendly
revamped dialogs (project settings, threads, breakpoints, …)
searchable command palette
It’s free (as in free beer)
ever had to pay for a birthday present ? 😉
Every change has a toggle
only take what you like, but we can not check each combination
It’s an internal spare time project
don’t expect everything to work in every setup, but feel free to reach out
Included in the bundle is the following compilers:
clang version 3.8.0 (branches/release_38)
Target: i686-pc-windows-msvc
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80×86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation. All rights reserved.
It’s an interesting project, although I tried to re-build some Visual C++ 2003 projects and it bombed out. Maybe it’s just more geared towards VC 6 as indicated.
I picked this 20 disc set recently and ugh the cringe is just… insane. And yes, that is Bill Nye…
STUDS from Microsoft . (Video in MPEG-1/Audio MPEG-2 care of JSMpeg).
I had this ages ago, although I couldn't remember if the NT 3.5 SDK/DDK had shown up at this point, but it's only the Japanese version in this set. Since I'm having such a PITA in tracking down a 3.5 set, and I'm not sitting on this, I may as well archive it.
Yes, I had to rip 20 of these!
So you too can find the early Video for Windows, and all kinds of other things from the mid '90's on archive.org.
Or Wallpapers like this 'puppy' from the Japanese version of Windows 3.1
There was a shift years ago from the old help system that has it’s roots going back to Windows 3.0, and was certainly one of the killer features of Windows 3.0, the hyperlinked and searchable help files. They were a form of compiled RTF files, and could also embed image resources, and later audio & video with the evolution of Windows. This allowed for a platform for early multimedia encylopedias and other refrence books of sorts.
Starting with Windows Vista, however the WinHelp engine was being retired out for a CHM or compiled HTML help engine. And for a whlie there optional updates and later downloads to re-enable WinHelp. However starting with Windows 10 the downloads no longer work.
All is not lost however, if you copy any of the 32bit WinHelp programs from NT 3.1 onward it will still function on Windows 10. And thanks to this great post on TenForums, you can re-enable the hook so that Windows 10 will integrate again with WinHelp.
@echo off
set crtpth=%CD%
takeown /f "%windir%\winhlp32.exe" >nul
icacls "%windir%\winhlp32.exe" /grant *S-1-5-32-544:F >nul
copy /y "%crtpth%\winhlp32.exe" %windir%
icacls "%windir%\winhlp32.exe" /setowner "NT Service\TrustedInstaller" >nul
echo.
echo Done.
echo.
echo Press any key to Exit
pause >nul
WinHelp from Windows NT 3.1 refresh on Windows 10
And there we go, now I can load obsolete refrence docs from great old programs like Visual C++ 1.10 for Windows NT!
Naturally Microsoft removed all this stuff as it was a security risk, in that they apparently never revamped or updated it, so yeah it may be another infection vector.
So I came across this recently, and unlike the previous version I had for Windows 3.1, This version is for Windows NT. And unlike the Windows 3.1 version this version does actually run on the shipping version of Windows NT 3.1, and thus will work all the though including Windows 10 on x64. The setup program unfortunately doesn’t complete leaving it ‘unlicensed’ however it’ll still run.
The diskettes for the Windows 3.1 version I have are dated 11-23-93, but once installed the compiler is actually from February of 1993, with the Windows NT version being dated October of 1993.
So the nice thing with the Windows NT version is that you don’t have to mess with the compiler, and linker, it’ll just run. And just like Visual C++ 1.0 / 1.10 for NT the linker doing a release build will always result in an exe being at least 2 megabytes in size.
I know that this is pretty much useless for 99.9999% of people. Yes it’s ancient Fortran. Yes Fortran PowerStation 4.0 is far more comprehensive. Yes after it was sold to Compaq as part of some deal over the collapse of Dec & Windows NT, then sold out to Intel. And GFortran is free.
It’s incredible how much it’s improved since I last touched on WineVDM, the port of Wine to run on Windows using the MS-DOS Player (and Mame 80386 emulation) at it’s heart.
The latest source build WineVDM_2018_07_30b.7z is now capable of loading and running Sim City for Windows 1.0.
I found it best to install Windows 3.0 into DOSBox, and then your application. After the install I copy the application so the physical drive of the hosts matches where it was installed, and then unpack the 7z build archive into that directory. There is a ‘WINDOWS’ directory and I xcopy the installed Windows directory into there so it has all the INI files, fonts and all that jazz. To make sure it doesn’t conflict I delete the following from Windows 3.0:
del windows\system\*.drv
del windows\system\*.exe
del windows\system\*.mod
del windows\system\WIN87EM.DLL
Since these files are most certainly going to be emulated by WineVDM. After that it’s time to run stuff!
130 KLOC!
I should also add that I’ve been able to use QuickC for Windows, and build a ‘non trivial’ program, the Fortran f2c compiler weighing in at 104,245 lines , and use that to compile 16,182 lines of Fortran 77 into C, and then compile the resulting C + the Fortran runtime library a staggering 130,405 lines of code, and the resulting binary works, just like it did on Windows 3.0!
I’ve also been able to print a text file using Microsoft Word 2.0 much to my amazement, although anything involving fonts just locks or crashes. I can’t say I’m all that surprised.
So no need to wait for Win3mu, there is WineVDM which is being developed RIGHT NOW, and the source is already available. You can see my notes on building it here.
This is super cool, building on Takeda Toshiya’s excellent MS-DOS Player, is a fusion of the MS-DOS emulation with portions of Wine to run Win16 applications on Win32 capable OS’s.
Excel 3.0a
Yes, it really can run Excel 3.0a. I don’t know how much people will want a 27 year old spreadsheet, but here we go! It’s incredibly buggy, and many Microsoft programs don’t like their accelerators, or menus, more things don’t run than do, but when they do it’s great.
The releases on the github page are quite old, and you’ll really want to bulid this from source. You will need Visual Studio 2017 to build this, and I used the Community Edition. While trying to compiling I got this error:
Really it’s no help at all
Performing Custom Build Tools
The system cannot find the path specified.
Well that doesn’t help us at all!
Setting the Tools -> Options -> Build and Run, MSBuild sections to both detailed verbosity revealed:
“C:\Users\neozeed\source\repos\winevdm-master\Release\convspec” “krnl386.exe16.spec” KERNEL > “krnl386.exe16.asm” && “C:\msys32\mingw64\bin\as” –32 -o “krnl386.exe16.obj” “krnl386.exe16.asm”
Performing Custom Build Tools
The system cannot find the path specified.
So it turns out it is using GNU GAS to assemble itself. So I just copied in an ‘as.exe’ from another MinGW install I have lying around.
c:\msys32\mingw64\bin\as.exe –version
GNU assembler 2.17.50 20060824
So it doesn’t even have to be a hyper modern version, as you can see with the –32 we are building 32bit based stuff anyways.
And with that all done we have a release build.
F2c Dungeon
I had no luck with Sim City, but Sim Life & Sim Earth load at least, but not being able to use the menus means you can’t really use them. Microsoft Word 1.1 won’t load at all, while Word 2.0 will load but again no menus, and it’s unable to register enough OLE to open documents so it’s not very useful again. Although my ancient QuickC for Windows F2c port of Dungeon, works okay, although QuickC for Windows itself does not currently run.
WinHelp 3.00
Another great thing is that you can run WinHelp for all your ancient documenation fixes! Also MS Write from the ancient days of Windows 3.0/3.1 works as well
The latest version allows the menus to work properly so you can actually use Word for Windows 2.0 and SimEarth & SimLife now! Further updates let you actually select and open files in Word for Windows 2.0!
(This is a guest post by Antoni Sawicki aka Tenox)
In a recent blog post Wanted: Console Text Editor for Windows I lamented about lack of a good console/cmd/PowerShell text editor for Windows. When researching for the article I made rather interesting discovery. There in a fact has been a native Windows, 32bit, console based text editor. It was available since earliest days of NT or even before. But let’s start from…
…in the beginning there was Z editor. Developed by Steve Wood for TOPS-20 operating system in 1981. Some time after that, Steve sold the source code to Microsoft, which was then ported to MS-DOS by Mark Zbikowski (aka the MZ guy) to become the M editor.
M editor
The DOS-based M editor was included and sold as part of Microsoft C 5.1 (March 1988), together with the OS/2 variant, the MEP editor (perhaps M Editor Protected-mode). The official name of M/MEP was simply Microsoft Editor. The same editor was also available earlier (mid-1987) as part of the MS OS/2 SDK under a different name: SDKED. Note that normally SDKED insists in operating in full screen mode. Michal Necasek generously spent his time and patched it up so that it can be run in windowed mode for your viewing pleasure.
SDKED on OS/2
However my primary interest lies with Windows NT. The NT Design Workbook mentions that in the early days a self-hosting developer workstation included compiler, some command line tools and a text editor – MEP. Leaked Windows NT builds sometimes include IDW, Internal Development Workstation, which also seem to contain a variant of the same editor. In fact some these tools including MEP.EXE can be found on Windows NT pre-release CD-ROMs (late 1991) under MSTOOLS. It was available for both MIPS and 386 as a Win32 native console based application.
MEP on Windows NT Pre-Release
The editor was later also available for Alpha, i386, MIPS, and PowerPC processors on various official Windows NT SDKs from 3.1 to 4.0. It survived up to July 2000 to be last included in Windows 2000 Platform SDK.
M editor from NT SDK 3.1 running on Alpha AXP
MEP from NT SDK on Windows NT 4.0
The Win32 version of MEP also comes with an icon and a file description which calls it M Editor in NT 3.1 SDK and later Microsoft Extensible Editor.
From time perspective, it was rather unfortunate that this gem was buried in the SDK rather than being included on Windows NT release media. However I can understand that the editor wasn’t very user friendly or intuitive, compared to say edit.com from MS-DOS. It came from a different era and similar to VI or Emacs, didn’t have “PC user friendly” key bindings or menus.
But that’s not the end of the story. The editor of many names survives to this day, at least unofficially. If you dig hard enough you can find it on OpenNT 4.5 build. For convenience, this and other builds including DOS M, OS/2 MEP and SDKED, NT SDK MEP can be downloaded here.
Digging through the archive I found not one but two copies of the editor code, lurking in the source tree. One under the name MEP inside \private\utils\mep\ folder and a second copy under name Z (which was the original editor for TOPS) in\private\sdktools\z folder. MEP was included in Platform SDK, while Z was only available as part of IDW.
Doing a few diffs I was able to get some insight on the differences. Looks like MEP was initially ported from OS/2 to NT and bears some signs of being an OS/2 app. The Z editor on the other hand is a few years newer and has many improvements and bug fixes over MEP. It also uses some specific NT only features.
Sadly the internal Z editor was never released anywhere outside of Redmond. All the versions outlined so far had copyrights only up to 1990, while Z clearly has copyright from 1995. Being a few years newer and more native to NT I wanted to see if a build could be made. With some effort I was able to separate it from the original source tree and compile stand alone. Being a pretty clean source code I was able to compile it for all NT hardware platforms, including x64, which runs comfortably on Windows 10. You can download Z editor for Windows here.
Z editor on flashy Windows 7 x64
But how do you even use this thing?
Platform SDK contains pretty solid documentation in tools.chm.
Here is a handy cheat sheet:
Last but not least there is a modern open source re-implementation of Z editor named K editor. It’s written from scratch in C++ and LUA and has nothing to do with the original MEP source code. K is built only for x64 using Mingw. There are no ready to run binaries so I made a fork and build.
K editor on Windows 10 x64
The author Kevin Goodwin has kindly included copies of original documentation if you actually want to learn how to use this editor.
So as promised, a while back I had built a GCC 2.7.2.3 / Binutils 2.8.1 cross compiler toolchain suitable for building old Allegro based programs, such as MAME. Of course the #1 reason why I’d want such a thing is that being able to do native builds on modern machines means that things compile in seconds, rather than an hour + compiling inside of DOSBox.
Why not use a more up to date version of both GCC/Binutils? Well the problem is that the pre EGCS tools ended up with macro and inline assembly directives that were dumped along the way so that later versions simply will not assemble any of the later video code in Allegro, and a lot of the C needs updating too. And it was easier to just get the older tool chain working.
It took a bit of messing around building certain portions inside of each step of the tools, but after a while I had a satisfactory chain capable of building what I had needed.
Lib Allegro is already pre-built in my cross compiler tool chain, all that I needed to add was SEAL, with only one change, 1.0.7 is expecting an EGCS compiler, which this is not, so the -mpentium flag won’t work, however -m486 will work fine.
Otherwise, in MAME all I did was alter some include paths to pickup both Allegro and SEAL, and in no time I had an executable. And the best part is checking via DOSBox, it runs, with sound!
MAME 0.1 on DOSBox PACMAN hiding
Thankfully MAME has been really good about preserving prior releases, along with their source tree, and it’s pretty cool to be able to rebuild this using the era correct vintage tools, and I can’t stress how much more tolerable it is to build on faster equipment.
