Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×


  • Posts

  • Joined

  • Last visited

  • Donations

  • Country

    United States

Posts posted by ppgrainbow

  1. I don't know if I'm correct, but I would like to point out that Pixia v3.3b is the last to support Windows NT 4.0. I don't know about Windows 95, Windows 98 or Windows Me.

    I had to install Pixia v3.1 first and then update to Pixia v3.3b. The files names are pix31je.exe and pix33be.exe.

    By the way, does anyone have idea which version of Blender is the last to support Windows NT 4.0? I currently have v2.2.8 installed.

  2. I have been trying out the latest version of DOSBox 0.74-3 running on Windows NT 4.0 SP6 under VMware Workstation Player 16.1.2.

    When starting DOSBox, I get the following output in the Command Prompt window:

    SDL_Init: Starting up with SDL windib video driver.
              Try to update your video card and directx drivers!
    CONFIG: Generating default configuration
    Writing it to C:\WINNT\Profiles\ppgrainbow\Application Data\DOSBox\dosbox-0-74-3.conf
    CONFIG: Writing it to C:\WINNT\Profiles\ppgrainbow\Application Data\DOSBox\dosbox-0-74-3.conf
    MIXER: Got different values from SDL: freq 44100, blocksize 512
    MIDI:Opened device:Win32

    However, when I try to close the DOSBox window, DOSBox hangs hard and robs 100% of the CPU usage! :(

    Using Process Explorer, I tried to terminate DOSBox.exe, but instead I get an error message:

    Error terminating process: Access is denied.

    Here's a screenshot of this issue: https://imgur.com/a/74tilnb

    The only way to resolve the issue was to perform a hard reset of the guest OS.

    Since Windows NT 4.0 has limited DirectX support (up to version 3 officially), how can I get around this issue?

  3. 21 hours ago, jaclaz said:

    Yep, but when compared to a "normal" install of a "recent" MS OS, let's say 20 GB, it is "only" 4-5x.


    So true. I can't imagine that so many software got ported over to Cygwin over the years which is the reason why the repositories have gotten so large. :)

  4. 1 hour ago, roytam1 said:

    that ddns domain provider is no longer exist.

    Thank you for telling me.

    I also managed to get VLC Media Player 0.8.6e and Connectix Virtual PC 5.2 build 418 to work under Windows NT 4.0 SP6 with your SSE patch:


    Sorry if the output of the screenshot is turning out not so good, but I need to reduce the size of the image to be under the 191.36 KB maximum image size. :)

  5. 11 hours ago, roytam1 said:

    Thank you so much! :)

    I tried your ntsse.zip patch file found here, I managed to install your patch, by running the nt4sse.reg file and replacing the intlfxsr.sys file that was shpped with SP6 with your patched versiom and...what do you know. QTWeb now works! :)


    I'm gonna try testing out the last working versions of VLC Media Player and Connectix Virtual PC 5.2 to see if it works now that the patch has been applied! :D

    I tried to find the ntsse.zip file on your original website, but it seems that it's no longer there. The webpage appears to be blank.

  6. 5 minutes ago, roytam1 said:

    there should be an INF file come among with the sys file, right-click on INF file and select "Install" to install. if your host CPU is not Intel, you have to patch the sys file.

    Okay, I ran the installer manually by using RUNDLL32 with this command:


    rundll32 setupapi.dll,InstallHinfSection IntelSection 132 "K:\Temp\SP6a\update\update.inf",

    The installer requested the file \intlfxsr.sys and the file was in K:\Temp\SP6a\ sub-directory. After I rebooted, I checked the Event Viewer and found that a Event 3 warning has occurred in intlfxsr driver:


    Streaming SIMD extensions are not supported by some of the processors in this system.

    My host CPU is AMD FX-4300. How can I patch the intlfxsr.sys file to make it work with AMD host processors? :}

  7. 27 minutes ago, roytam1 said:

    QtWeb needs SSE instructions. I don't know if VPC supports it or not. VMWare supports SSE if your host CPU supports it.

    and NT4 needs installing SSE driver to enable usage of SSE instructions.

    Thank you for telling me. Apparently, when Connectix released Virtual PC 5.2, it apparently made improvements to the CPU that requires SSE instructions.

    The driver that I need is the Windows NT Intel SSE driver (intlfxsr.sys) which is included in Service Pack 5. How can I install it?


    I'm currently trying to run QtWeb 3.8.4 with QtWebKit v2.2 (QtWeb-qtwebkit22.exe) that is designed to work under Windows NT 4.0.

    I'm currently running Windows NT 4.0 under VMware Workstation Player v16.1.2 and when attempting to run QtWeb 3.8.4, the browser crashes with the following error provided by Dr. Watson:


    The error message that I received was a Illegal Instruction (0xC000001D) and this error might have also occured when attempting to run a Virtual PC 5.2 virtual machine under Windows NT 4.0 guest.

    Does anyone have any idea what I could be missing here and how this can be resolved?

  9. Has anyone gotten Conectix Virtual PC v5.2 build 418 to work under Windows NT 4.0?

    I tried to run the emulation window and Virtual PC v5.2 crashed with a Illegal Instruction 0cC000001D error when running it under VMware Workstation Player 16.1.2.

    Update: In order to get Connectix Virtual PC v5.2 build 418 working under Windows NT 4.0, I had to install roytam1's patched Windows NT SSE driver that can be found here. I ran the nt4sse.reg to get it to work and replace the intlfxsr.sys driver with a newer version. More information about it can be found here: https://www.betaarchive.com/forum/viewtopic.php?t=28694

    Without the patched SSE driver, Virtual PC v5.1 build 370 is the last version that will work under Windows NT 4.0 on a PC without SSE support.

  10. Okay! I solved the problem. :)

    I couldn't post an update, because MSFN.org went down for a few days.

    I somehow had the Windows Subsystem for UNIX 3.0 installed and somehow, its environmental variables somehow interfered with the xterm shell inside TWM...so, I wound up uninstalling the Windows Subsystem for UNIX and restored POSIX.

    Everything seems to work now. Here's a screenshot:


    This was taken before I started using bbLean on my Windows NT 4.0 VM.

    A full installation of Cygwin 1.5.25 will take up approximately close to 3.8 GB with close to 879 MB of repositories downloaded.

  11. Okay, I managed to use install Cygwin 1.5.25 (setup-legacy.exe with the -X paramater, Setup v2.674).

    I have pointed the link to http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa-legacy/2009/12/27/103117 for the repository to show up.

    Then, I followed this procedure to install the prequists for Fontforge 2009-09-14. I have managed to follow instructions on how to install Fontforge from the Cygwin shell:

    $ bunzip2 fontforge_cygwin-*.tar.bz2
    $ tar xf fontforge_cygwin-*.tar
    $ cd fontforge
    $ ./doinstall

    Then when I typed in startx, I got the twm shell. However, the keyboard input does NOT work, meaning that I have fallen one step short of getting FontForge to work on Cygwin under Windows NT 4.0!

    Here's a screenshot so far:


    The XWindow display is there, but I cannot type anything on the keyboard (fontforge -new) in order to launch Fonrforge.

    How can I fix this? Would I need to obtain a older version of Cygwin that works correctly? Just curious.


    UPDATE: Okay, somehow, I managed to start thee seamless X Windows server by clicking on startxwin.bat located in K:\Cygwin\bin, then I launched FontForge by typing "fontforge -new" at the X Terminal:


    I'm lucky that I can run FontForge seamlessly by launching startxwin.bat, but not through the rxvt or twm shell due the broken keyboard input.

    The size of the Cygwin 1.5.25 installation is 280 MB and the size of the downloaded local files is 87.9 MB so far.

    Thoughts on this, anyone?

  12. 1 hour ago, loblolly986 said:

    The bugginess of XWin 1.6.2 is not OS-specific and includes messed-up rendering of xeyes with antialiasing enabled (also encountered in testing on Vista) and menus not lining up with the menu bar in FontForge. The source code changes I had to implement to make Cygwin 1.7.9 and XWin 1.11.4 work well on NT 4.0 are frankly pretty insignificant and the issues just reflect the developers' lack of adequate (or any) testing on NT 4 and not paying attention to/being familiar with what API features it supports, combined with—sadly—NT 4 usage evidently having all but evaporated among the community of Cygwin users who might have noticed and reported the issues in a timely manner, or raised objections when the intention to officially drop NT 4 support was brought up on the Cygwin mailing list.

    To be clear, I only got into using Cygwin on NT 4.0 last year. The real hero in all this is Peter Castro of the Cygwin Time Machine project, whose vast archive of snapshots of the Cygwin package repository has preserved the ability to install and use almost any version of Cygwin and its corresponding software from the present to as far back as 2002. The installation method I intend for my fixes will be for the user to have already installed the corresponding original packages using Cygwin Setup and extract my updated files over the originals. Old versions of Cygwin Setup can be acquired via the Wayback Machine or the Setup archive provided by the Cygwin Time Machine, though I also plan on putting up a custom build of Setup 2.752 with improved NT 4 compatibility.

    Thank you for explaining this. I know that XWin 1.6.2 was full of bugs afterall, xeyes rendering messed up and menus not lining up with the menu bar in FontForge to name a few. Customer migration from Windows NT 4.0 to new versions of Windows which resulted in evaporation of the Windows NT 4.0 userbase along with Windows NT 4.0 being out of support since the end of 2004 might have resulted in intentions to pull the plug on Windows NT 4.0 support after Cygwin 1.7.9. :(

    I'm gonna try using the Cygwin snapshots to see how this can play out under Windows NT 4.0.

    If you have plans to put up a custom build of Cygwin Setup 2.752 with improved Windows NT 4 compatibility that would be lots of fun! I would love to see which of the older repository files are compatible with Windows NT 4.0.


  13. I would like to point out that if you want to install VMware Workstation 4.5 (VMware-workstation-4.5.3-19414) when running under Windows NT 4.0 on VMware Workstation Player/Pro, you must add the following line in your VMX file:

    monitor_control.restrict_backdoor = "TRUE"

    If the monitor_control.restrict_backdoor parameter is set to FALSE or if it's not present, VMware Workstation 4.5 will refuse to install or run. :)

  14. 3 hours ago, loblolly986 said:

    1.7.9 was indeed the last release of the Cygwin DLL/runtime that supported NT 4.0. But it does have a handful of compatibility problems, such as the method used for allocating consoles invisibly being ineffective on NT 4.0 (resulting in one being stuck with useless console windows when running, e.g., X11 applications or mintty), bugs in the locale support (notice that locale -a hangs in an infinite loop), issues in a couple of the other runtime utilities (ldd has pre-XP compatibility needlessly broken), etc.

    NT 4.0 compatibility de-facto ended in the XWin X11 server much earlier, the last working version being 1.6.2-2 from when Cygwin 1.7 was still in the development/beta stage (note that the "setup-1.7.exe" referenced above is a special version needed to access those test releases and associated packages, not a regular setup.exe version from the 1.7.x era). This old XWin version does still work on Cygwin 1.7.9, but it's buggy compared to later versions such as 1.11.4-2 (the last version from the 1.7.9 period).

    It just so happens that I undertook producing new builds of Cygwin 1.7.9 and XWin 1.11.4-2 (and other things) with the problems fixed last summer, and just recently revisited this project to implement further fixes and tidy up the patches' code style a bit (I just discovered a way to implement the invisible console code that actually does allocate consoles invisibly on NT 4.0; the best I'd come up with previously had the consoles flashing onscreen after allocation, which still beat the heck out of being stuck with them but was still unsightly). I was thinking of putting these up somewhere and posting a thread here before too long, once I'm satisfied with how I have them. Suffice to say that 1.7.x is a definite advancement over 1.5.x for Windows NT systems, and at least with these fixes there'll be little to no good reason to settle for earlier versions...

    As for the "bloat" of that third-party ISO, in fairness, Cygwin had a sizable amount of software ported to it and available through its repository, and seeing that the ISO is intended as a portable solution that can run directly from a DVD, the author presumably included much of that software to increase the DVD's usefulness. My Cygwin 1.7.9 installation on my NT 4 machine has grown to roughly 1.5 GB (excluding all the stuff under /usr/src ;)), with a fair chunk of that no doubt due to the various packages I had to install to be able to build various things (and otherwise wouldn't have). If all you need is a basic bash shell environment and runtime dependencies for some applications, needless to say you could get away with much less.

    Thank you for your experiences with running Cygwin under Windows NT 4.0 before support was dropped. However, developers just couldn't fix the compatibility problems that you mentioned above with Cygwin 1.7.9. I'm wondering if later versions of XWin after version 1.6.2-2 failing to work correctly, if not at all on Windows NT 4.0 was the final straw that led developers to remove Windows NT 4.0 in Cygwin 1.7.10.

    For once, I did run FontForge 2009-09-14 with TWM under older versions of Windows (Windows 98SE and Windows 2000) before switching to a newer PC. As for the Cygwin Easy 2007-03-21, it's roughly 1.83 GB in size including 112,098 files in 6,302 directories.

    If you have the files containing the downloaded apps from the \cygwin\local directory that were compatible with Cygwin 1.7.9, you're welcome to provide a link to the list of apps along with the Cygwin 1.7.9 setup.

    It's a good thing that older releases of Cygwin exists for Windows NT 4, Windows 9x and Me for a reason - virtualisation purposes.


  15. 15 hours ago, jaclaz said:

    The 1.7 should be the one in which support for NT 4.00 and 9x/Me was dropped, so the 1.5.9 you found might be the last-last one working on your system, possibly better than 1.5.25. :dubbio:

    The BLOAT in this one is strong. :w00t: :ph34r:

    It must somehow be evidenced how a FULL install of NT 4.00 is (was) around 120-150 MB and that a reduced but still fully working system was more like 50-60 MB or however it could fit (with some spare space and commonly used programs) on a "common" (at the time) 100 MB Iomega Zip Disk.

    A common (at the time of NT 4.00, circa 1995-1996) internal disk (IDE) was in the range 1-2.1 GB, and TOP LEVEL workstations (imagine running Autocad and similia professionally in an architectural/engineering context) had  - maybe - a single 9 GB (SCSI) disks, more commonly a single  4-5 GB one


    v1.5.9 was the version that I found on one of the websites so that's correct. v1.5.25 was the last to support Win 9x/Me. v1.7.10 was the version where Windows NT 4.0 support was dropped.

    Copying all of the files from the 1.99 GB Cygwin Easy DVD-ROM took up around 2.23 GB of disk space (or almost 15% of the total space) out of the 15 GB SCSI volume set on drive L. Other than that, I have managed to run a few Linux-based apps ported to Cygwin such as xclock, xcalc and xeyes. Have a look :


    For the time being, I had to run one of the apps off of the CD-ROM in order for it to work. If I can find a way to run it without the use of a DVD ISO, I'll let you know, :)

  16. 17 hours ago, jaclaz said:

    Thank you for the help. :)

    There is also the Cygwin Easy 2007-03-21 release on GitHub! Here's the author's website: https://www.cygwineasy.net/

    And here is the link to the Cygwin Easy ISO on GitHub. It's a 1.99 GB ISO file: https://github.com/whitone/cygwin-easy/releases/download/2007.03.21/Cygwin-Easy-2007.03.21.iso

    There is also Cygwin v1.3.12 and v1.5.9 on Shawn Novak's website, who goes by the name Kernel86 on Discord: https://www.shawnnovak.com/stuff/cygwin/

  17. I've decided to install Cygwin 1.7 under Windows NT 4.0 Workstation. I got the utility (setup-1.7.exe) from the Cygwin Time Machine page on the CrouchingTigerHiddenFruitbat website. In order for Cygwin setup 2.661 to work properly, I had to provide this URL link here:  http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/

    So, I wanted to install the 2009-09-14 build of FontForge to use under Cygwin 1.7. I have followed all of the procedures to get FonFforge to work properly on this page: https://www.iro.umontreal.ca/~boyer/typophile/doc/ms-install.html

    The installation took a while and when I tried to type startx under Cygwin, I get this output:


    Looking to see what could be wrong here, I looked at the XWin.exe file located in L:\bin directory, when I try to execute the file, I get this error:1006531184_CygwinNT2.thumb.png.bd9afaf617f668bc890ae3cb8f3cbb35.png

    XWin.exe failing to execute due to the missing VerSetConditionMask entry point which is not present under Windows NT 4.0 or earlier. VerSetCondition mask entry point is only present on Windows 2000 and later.

    Over a decade ago, I remember running FontForge on Windows 98 Second Edition under Virtual PC and I don't think that I can find an old enough version of Cygwin that will work on these versions of Windows anymore.

    I'm sorry if I'm not providing enough information or if I'm not making sense, but is there any way how I can get an old enough version of Cygwin with the older repositories that will work under Windows NT 4.0?

    Thank you for your time. :)

  18. Windows NT 3.51 has installation and data corruption problems when installing it under Virtual PC 2007 with more than one processor core installed. This is a follow-up to a previous post that I made on April 20, 2014 and I have decided to post a good tutorial on how to install Windows NT 3.51 under Virtual PC 2007. This applies to users who are still using Virtual PC when using Windows XP, Windows Vista, Windows 7 and Windows 8.x as host machines and for Virtual PC 2004 when running Windows 2000 and Windows XP as host machines.

    1. Start Virtual PC 2007.

    2. Using Process Explorer, look for the process that says "VirtualPC.exe" (or equivalent) and set process affinity to use 0. Process Explorer can be downloaded here: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

    3. Create a Virtual Machine using the New Virtual Machine Wizard and with the recommended settings (a 2 GB VHD with 64 MB of RAM). Windows NT 3.51 does not support hard disks larger than 4 GB on install.

    4. Install Windows NT 3.51 as usual using installation diskettes and the Windows NT 3.51 ISO.

    5. You will need to use ImDisk to edit the VHD disk image, apply the Windows NT 3.51 Post-SP5 SuperPack: http://www.ltr-data.se/opencode.html/

    I also recommend to using the IMDisk ToolKit to better manage the hard disk image: https://sourceforge.net/projects/imdisk-toolkit/files/20200727/

    6. Install Windows NT 3.51 install Service Pack 5. The file that you can search on Google is SP5_351I.EXE (1996-09-19) for Intel x86 processors: http://cd.textfiles.com/cica/cica9710/PATCHES/

    7. Shutdown the VM, close Virtual PC 2007 and install the Windows NT 3.51 Post-SP5 SuperPack here: https://bearwindows.zcm.com.au/winnt351.htm#4

    I recommend placing the SP5_351I.EXE and the SuperPack file on the root directory of the hard disk image.

    8. When you're done, you can start Virtual PC 2007 again without the use of setting the process affinity to 0.

    9. If you need to change the drive letter for a Windows NT 3.51 installation, go to Disk Administrator found in the Administrator Tools group.

    10. From the Tools menu, choose Drive Letter and in the Assign Drive Letter box, select a drive letter other than C, commit the changes and reboot. This is useful if you want to move the Windows NT 3.51 installation onto a logical drive.

    11. If you have MS-DOS 5.0 or later installed, place the BOOT.INI file, NTBOOTDD.SYS and NTDETECT.COM on the primary partition of the C drive and leave NTLDR on the drive other than C where Windows NT 3.51 is installed. Please refer to Chapter 16: Disk Administrator starting on page 428 for more information on how to use this feature.

    I must apologise if my tutorial is not 100% perfect, but if you got any questions regarding how to install Windows NT 3.51 under Virtual PC 2007, please let me know. :)

  • Create New...