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. ×

ppgrainbow

Member
  • Posts

    694
  • Joined

  • Last visited

  • Donations

    $0.00 
  • Country

    United States

Posts posted by ppgrainbow

  1. paint.NET 4.3.3 is the last version to work on Windows 7 SP1 and Windows 8.1. Starting with version 4.4 paint.NET will only work on a more recent version of Windows 10 and Windows 11. paint.NET is also discontinuing 32-bit versions of its app even under 32-bit versions of Windows 10: https://forums.getpaint.net/topic/118933-paintnet-433-is-now-available/

    If paint.NET doesn't work on Windows 8, can you use Dependency Walker to determine which entry points are missing in Windows 8?

    Windows 10 will be supported until October 14, 2025 and Windows 11 will be supported until October 14, 2031.

  2. Thank you for telling me. Ifound that even if the MSI GeForce GT 710, the graphics card supports level 11_0 only which unfortunately can be problematic for software titles that require either DirectX 11.1 or DirectX 12.

  3. 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.

  4. 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?

  5. 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.

    jaclaz

    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. :)

  6. 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! :)

    QTWebWorking.thumb.png.4eaf0eeedbf1a32c54fc06e0b3682eb2.png

    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.

  7. 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:

    Quote

    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:

    Quote

    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? :}

  8. 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?

  9.  

    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:

    924623473_QtWeberror.thumb.png.f47c354a8cc0be515910d0a5520c60c3.png

    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?

  10. 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.

  11. 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:

    startx.thumb.png.d7494c5a8bcd5b585e38644cea43b8c9.png

    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.

  12. 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:

    xterm.thumb.png.05675238376dea625300c970d81555ee.png

    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:

    fontforge.thumb.png.02a345626942fde384ce09445dd11d26.png

    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?

  13. 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.

    :)

  14. 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. :)

  15. 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.

    :)

  16. 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

    jaclaz

    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 :

    xclock.thumb.png.4690da21f327d4e364c764f42f9e4be0.png

    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, :)


×
×
  • Create New...