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.
But here we go.
32bit Fortran from 1993 in 2018!
I’m part of the 0.0001%. This is cool. I’ve compiled the original Fortran source code from Berkeley for SPICE* on VAX/VMS and the UNIX version on Linux. No f2c for me. 🙂
*SPICE is Simulation Program with Integrated Circuit Emphasis – it’s an electronic circuit simulation program.
Seeing as you just downloaded the Microsoft FTP site, I think you want Softlib\MSLFILES\LNK100.EXE . AFAICT the original linker was using memory mapped IO to write and tried to truncate with it still active, which newer OSes don’t like, resulting in files that are multiples of 2Mb. The fix is simple enough, but it’s in the linker. Also, it shouldn’t have the 2Mb behavior if run on NT 3.1. I don’t know if the service packs for 3.1 broke this; I don’t use the service packs on 3.1 because they did break other things that I care about (aka Word.)
That makes perfect sense. I’ve run into some other issue with larger executables not linking correctly and I just dumped the 1.x linker for the Visual C++ 2.0 linker which seems okay as well, although the MSVC ui for 2.0 doesn’t install/load on Windows 10, while Visual C++ 1.10 for NT loads just fine….
I thought i was the last person in the world running Windows NT 3.1, although I just have this rather un-inspiring web site. What version of Word do you use on NT 3.1?
If it’s 16bit, have you tried WineVDM?
I haven’t tried MSVC2 on 10; I’m using it on 8.1 without issue. It has a few quirks, like a 16 bit stub installer and getting the system architecture wrong then trying to use the wrong architecture of its Winhelp helper DLL, but after fighting with it for a while it always acquiesces. And after patching the subsystem version (http://www.malsmith.net/blog/pe-subsystem-version/) it looks decent too.
I was using Word 1.1a on NT 3.1 IIRC. Since these were designed for real mode 2.x they’re a bit quirky. Win9x refuses to even try to load them. NT 3.1 RTM worked okay, but later service packs complained about “Out of memory.” Since neither WfW 1.x nor NT 3.1 were high volume, and WfW 1.x wasn’t the current release, I don’t think too many people cared. But it was the version I had, so…
What I’m really doing with NT 3.1 is still supporting it in my software. It always seems to be that I can have something “just work” on version N but if I do some tiny little change it works on N-1, and so after a pile of tiny little changes it ends up running the first release. Once that’s done there’s no reason to make it not work on something that it previously worked on. One of the reasons for starting Yori (https://github.com/malxau/yori) was realizing I can’t live without tab completion, and that works in Yori on NT 3.x. I’ve mentioned this to you before, but Visual C++ 6 (and 2002) will target 3.1 (http://www.malsmith.net/blog/vc6-nt31-support/), so writing software for it doesn’t need to be too painful.
I did try WineVDM after your earlier posts. I was using a debug build and was shocked how slow it was. Like you I saw Excel 3 work okay, but not much else – things like Publisher 1 and Word 2 weren’t happy. I’m sure I could spend some time with a debugger and make these things work, because obviously the vast bulk of what’s needed is there so it’ll just be implementing or stubbing a function call here or there, but I haven’t felt motivated enough to dig deeper just yet.
I should have spent time learning how to actually program on Windows. I’ve been meaning to either learn, or find somewhere to hire someone to do it, but I don’t think there is that many people out there… I’ve been rebuilding all the old Quake1/QuakeWolrd/ and starting on Quake2 to use the release Windows NT 3.1 SDK (cl386 v8.0.3190a) to get them to run. I was lucky to find someone cut down the GDI stuff to something that’ll run on NT 3.5 & Windows 95, but going from the magic that is CreateDIBSection into whatever the old GDI function would be is going to take some time.
Oh the newer updates WineVDM was able to load Word 2.0 for me, and I could spell check some documents, and I could compile with QuickC for Windows, but yeah the MAME 386 isn’t very fast..
Speaking of Word 1.1, they did release the source, one day I need to try to build it. Something more crazy would be something like a Win32s port of MS Word 1.1 …. Or that Watcom Win386 Windows Extender.
Good luck with the Word 1.1 source. I downloaded it when it was released, but it really is one of those “wow” things.
On the plus side, it followed Microsoft tradition by including all of the tools used to build it, so the source happens to contain a complete Windows 2.x build environment. On the bad side, it compiled using a C-to-PCode compiler (not Microsoft C), which is how it could do paging in real mode and fit in 640Kb. So the build environment includes useful things like MASM, LINK5, NMAKE 1.0 (haha), the Windows 2.x RC, but not an actual C compiler, only the PCode one; and only the PCode port of windows.h and corresponding CRT libraries, etc.
Building it will require some historic environment too. It’s designed to be built from DOS or OS/2, but trying to do it on NT is problematic because NT tries to run all the OS/2 binaries and fails.
I hadn’t bothered trying to do anything with it because the license really prevents any type of redistribution. Obviously moving to 32 bit would be a big undertaking – first, move the code to real C, then move it to 32 bit C, replacing the entire toolchain.
The other thing is that although I know Win32 reasonably well and am proficient with the tools (eg. WinDbg), the tools in 16 bit land were never as good. As you probably know, since it’s cooperatively multitasked and single threaded, it’s not really possible to pause a program’s execution in order to debug it. Visual C++ 1 did some impressive but horrifying things to pretend it halted a program without halting it, but that was late in the day for 16 bit (around 1993.) Going earlier that that requires CodeView/W or WDEB386 to debug the Windows kernel on a second monitor which incidentally allowed you to debug your program. (Ever wonder why quality 16 bit apps were hard to come by? Yeah.) For something like Word 1.x this is particularly bad, because using its own compiler etc, how much compatible symbolic debugging information will it emit? I’m sure people working on it had a setup to allow it to be debugged, but it may not be documented or easy to recreate. It sure won’t be as easy as stepping through code in Visual C++.
I am running Fortran 1.0 in win3. 1.1 using dosbox in my smartphone.
Maybe I will ran powerstation 4 or Compaq 6 in winehq for Android.
Question : Fortran powerstation 1 support Fortran 90?
How yo download this version? for WinNT.?
Try this.
You’ll get a 404, follow the instructions