• Please review our updated Terms and Rules here

What fun-OS can be run on a 386SX?

one -bit tricky- OS to try is CTOS (Convergent Technologies later UNISYS), any CTOSian here?
I wrote 'bit tricky' as this wont be installed on *any* 386/486 this OS is very picky, it normally requires a ClusterCard for the networking, bit it can be installed as standalone - if you are lucky.
 
Eudimorphodon said:
Doesn’t work on 486 (or less) CPUs at all, and is considered unlikely to work with a lot of software on less than a “686”
Click to expand...

ReactOS originally targeted Windows XP compatibility, which makes sense. Windows XP RTM dropped support for the i486 architecture. By the time that SP3 rolled around, CPUs without SSE support were dropped (not officially, but you'd experience system instability and crashes from updates/drivers/apps trying to use SSE.) SSE2 was also starting to become a requirement on some software, so anything pre Pentium 4 Northwood or Athlon 64 was dropped as well.

I recently tried Windows XP SP3 on an Athlon 800 and it was basically unusable. Several Windows updates by that point had integrated SSE instructions, as did some of the drivers. It was constantly blue screening or having processes crash at random.

deanimator said:
For me, I find the POSIX "i386" platform definition to be somewhat ambiguous. Recently there was a guy on another forum that was trying to run the "i386" build of Free Pascal on his "Pocket 386" laptop that has been mentioned above, and failing at it; according to him it was built with 486 instructions. I consider "i386" to be a shorthand for "32-bit x86" which doesn't generally mean it will execute on a physical 80386, even if the rest of requirements could be potentially satisfied. Your mileage may vary.
Click to expand...

It's been that way since the late 90s/early 2000s. There was some minimal effort by people to specify the architecture a package was compiled for, but you couldn't trust that either. This resulted in a pile of nonsense package suffixes like i386, i486, i586, i686 and I remember seeing at least a handful of i786, which was an unofficial term used for Pentium 4 and Athlon 64 chips. All this did was exacerbate dependency hell.

These days, "i386" is just a generic moniker for 32 bit. But, it is not explicitly limited to only 32 bit processors. Both Intel and AMD further extended 32 bit x86 well into the 64 bit era, so there are some cases where you require a 64 bit processor to run 32 bit code.
 
GiGaBiTe said:
This resulted in a pile of nonsense package suffixes like i386, i486, i586, i686 and I remember seeing at least a handful of i786, which was an unofficial term used for Pentium 4 and Athlon 64 chips. All this did was exacerbate dependency hell.

These days, "i386" is just a generic moniker for 32 bit. But, it is not explicitly limited to only 32 bit processors. Both Intel and AMD further extended 32 bit x86 well into the 64 bit era, so there are some cases where you require a 64 bit processor to run 32 bit code.
Click to expand...

Heh, never ran into i786. The entire nomenclature is stupid, 786 sounds off because it's like a fictitious platform, 586 and 686 sound "ok", reminiscent of those old Cyrix chips, but they're not that.
Funny situations were with RH based distros, some of them used i686, some still used i386, so when you install rpm from another distro, in package tree you have i386 package dependent on i686 packages...

Spot on about the moniker - it's dead wrong to associate it to 386 the CPU. There is alot of 32-bit software around still especially OSS on Windows. I did some tweaking of GPG4Win package recently and the default crosscompilation target is 32-bit, that's also in the release installer, regardless of the flags being set for a very modern CPU. Labeling this package as "i386" would be highly misleading.
 
You must log in or register to reply here.
Back
Top