Support for older computers

[oldman]

What is the ReactOS policy for older computers, will they be supported or will support be abandon?

I have an old Fujitsu Ergo-Pro that is now about 20 years old. When I install Ros; to run the second stage of the installation, I have to do a fdisk /mbr to make it boot from the hard drive. I have just tried to install revision 66082 and it has completed the first stage, but in the second stage it fails after loading the boot drivers and goes to a blank screen with a flashing cursor. No debug info is sent to the serial port or to the screen, so no point in making a Jira report. I have successfully installed this revision on a newer test computer of about 9 years old and that does go through both stages of the installation and boots into the desktop; it also outputs debug info to the screen.

So will I have to abandon this computer as a testing computer for ReactOS?

[karlexceed]

IMHO, I think that asking ROS (or dang near almost any modern software) to run on a machine that's 20 years old is asking a bit much.

I guess the way I see it is: ROS targets 2003 as a 'gold standard' for Windows compatability. It was released in April 2003. You could expect that existing hardware in production at the time would have been able to be upgraded, so let's say a box running Server 2000 in theory could've ran 2003. That hardware was likely build around 2000 or so, making it 15 years old at this point. Assuming (again) that then by this logic, that this hardware would be able to run ROS as intended means.... That's pretty much the limit. About 15 years of hardware to be compatible with. Anything older is purely luck.

But again, this is just my thoughts... And I don't mean to sound like I'm anti old hardware either, because trust me, I have a few ancient boxes of my own; I just don't expect them to do much more than what they were originally intended (Win95, Knoppix, etc).

[Black_Fox]

On my 16 years old notebook FreeLDR won't even start loading because it can't allocate enough memory. So that's one of limitations that may be hard to overcome.
The other is (IIRC) that anything older than the original Pentium (or its AMD/Cyrix/... equivalents) is not supported due to instruction set requirements. That would need to be confirmed by someone who knows for sure, though.

On the other hand, computers the size of USB flash drive (with x86 CPUs) you just plug into a monitor are now appearing with substantially larger performance than those machines from 90's, so I don't mind that much.

[Forever Winter]

Afaik ReactOS uses some of the atomic compare-and-exchange instructions, which (at least some of them) require a pentium class cpu.
Sorry, I am not 100% sure for that but I hope it helps.

[middings]

On which processors will ReactOS run?

ReactOS currently only supports the x86 processor architecture, although AMD64 and ARM ports are making good progress. A PowerPC port was started but never completed.

The User FAQ is just a bit out of date.

...at a certain point a processor is at its end of life. A 486 definitely fits that category, considering it's nearly two decades old. We require a Pentium class processor as a minimum because we need certain instructions that were introduced with it.

A necessary instruction is CMPXCHG8B. Since r65326 Freeloader has tested for it and will bugcheck if it is not available. See CORE-6427 "freeldr: Halt system if processor used is too old."
.

[PurpleGurl]

Yes, since NT 4.0, Microsoft has required that instruction. Maybe someone could rewrite the parts of ROS that require that to work on older machines (and maybe modify the installer to put in the most compatible one for a specific machine), despite the penalties imposed. But then you might run into software that won't run (since if NT 4.0 or later is reported, the software may assume it exists and crash when it isn't). And like another said, memory would also be a possible problem. But really, it seems we'd do best overall to stay within the compatibility that Windows 2003 works in.

Personally, I'd like to see optimizations for newer systems too, but that would either be done with multiple code paths which would increase compile size and effort to maintain, or with multiple files, and a non-ROS team maintaining the alternatives and providing a way to use them, whether by service pack, ROS installer choices, or a specific installer and manager to copy in the files. I'd love to see finely-tuned assembly for more critical parts and tuned for newer hardware. Yes, we had that discussion before and discussed the pitfalls (like too much work v benefit, when a C compiler might be close enough). That could all be done 3rd-party too and giving the option to revert to standard before updates or transferring to a different PC. But this is just a sideways mention and not an attempt to hijack the topic.

[oldman]

I will give you more detail; it was designed for windows NT and windows 95, the processor is a Pentium2 233Mgz, a 3.? Gb hard drive, with 96 Mbs of ram (I think it originally had 128Mb), it has 2 usb-1 ports (1 at the front, the other at the back), it has (I think) 3 PCI expansion slots (2 are shared with ISA slots).

I have used it as my main Ros test comp in the past. In those days, I had no problems installing Ros, but last year or maybe the year before, I came across a none booting error, which I over came with a 'fdisk /mbr', now, with revision 66082, it loads the ntoskrnl and drivers in second stage of installation, then stops with a flashing cursor.

I am now wondering if this latest issue is related to this Jira Issue - CORE-8899 - [patch] FreeLoader: MEMORY_INIT_FAILURE, but that does not make sense, because it is booting so far, then stopping. FreeLoader should have done it's job, unless it is passing some wrong info to ntoskrnl (I don't know how they work).

[Kargaroc586]

Isn't Win 2003 requirements what we're aiming for?
That pretty much includes everything this side of the millennium, and a fair bit of things from the late 1990s.

I have a Pentium 1 (actually an MMX) downclocked to 150mhz, that I can test with to be sure.
Is there anyway to get a memory dump over the serial port?

[middings]

I will give you more detail; it (a 20-year old Fujitsu Ergo-Pro) was designed for windows NT and windows 95, the processor is a Pentium2 233Mgz, a 3.? Gb hard drive, with 96 Mbs of ram...

My wild guess is ReactOS now needs more than 96 MB of RAM at some point during ReactOS's installation. Your hard drive should be big enough, mine is 4 GB and after installing ReactOS less than 1.6 GB is used.

[Pi_User5]

My wild guess is ReactOS now needs more than 96 MB of RAM at some point during ReactOS's installation. Your hard drive should be big enough, mine is 4 MB and after installing ReactOS less than 1.6 MB is used.

WOW! How did you install ReactOS onto a 4MB hard drive?

[middings]

WOW! How did you install ReactOS onto a 4MB hard drive? *

Ha! You caught my blunder. (Fixed now.)

[middings]

I am now wondering if this latest issue is related to this Jira Issue - CORE-8899 - [patch] FreeLoader: MEMORY_INIT_FAILURE, but that does not make sense, because it is booting so far, then stopping. FreeLoader should have done it's job, unless it is passing some wrong info to ntoskrnl (I don't know how they work).

Timo Kreuzer committed another patch in r66087 earlier today. He expects this to be the final patch that resolves CORE-8899. In the comments to CORE-8899, jedi-to-be reported that it works in Virtual PC 7. jim tabor commented "HW works! 1++".

If you try r66087, let us know what happened.

[PurpleGurl]

Isn't Win 2003 requirements what we're aiming for?
That pretty much includes everything this side of the millennium, and a fair bit of things from the late 1990s.

I have a Pentium 1 (actually an MMX) downclocked to 150mhz, that I can test with to be sure.
Is there anyway to get a memory dump over the serial port?

Why is it down-clocked? You wouldn't by chance be running an AMD chip or not using a fan or proper heat sink on it would you? I had to downclock a socket 7 board myself to get Windows 95 to run, since over 300 MHz, Windows 95 would not boot. But then I found the Microsoft patch and applied it, and was able to get the K6-2 to run at 500 MHz without trouble. The K6-2 (and likely the K6-3) breathed new life into the Pentium 1 boards. Then Windows 98 came without the timing bug that forced you to underclock AMD processors.

[oldman]

I have now tested with revision 66087 and it is good news and bad!

The good news is, it boots much further, (the bad news) but I have encounted an hang at the end of the first stage of installation, where the screen says this:

The system is now making sure all data is stored on your disk

This may take a minute
When finished, your computer will reboot automatically

The second stage completes fully, re-booting, but only getting to where the desktop should appear, then a bsod.

I still have to do a "fdisk /mbr".

CORE-9091.

[middings]

I have now tested with revision 66087 and it is good news and bad! ... CORE-9091.

Hooray for the good news. I read your bug report, CORE-9091. I think it is informative. I hope the developers agree and get interested in resolving the issue. We are getting off topic so further discussion particular to CORE-9091 and your Fujitsu Ergo's BSOD while installing ReactOS should probably go to a topic of its own in this Support forum.

I still have to do a "fdisk /mbr".

That is interesting and also probably deserves a topic of its own in this Support forum. I have never seen that problem on my own 14-year old rig I use for testing ReactOS. Is that a known workaround for a problem? A search of all JIRA issues for fdisk /mbr returns very few hits.

Getting back on topic...

What is the ReactOS policy for older computers, will they be supported or will support be abandoned?

All I know is what I read in the forums.

Currently the necessary hardware seems to be:

• Pentium processor (or compatible AMD cpu)
• 96 MB RAM (the goal is to keep ReactOS lightweight and less resource-hungry than its Microsoft counterpart but as ReactOS grows more capable its RAM requirement also grows)
• IDE or SATA hard disk with at least 2GB of space available to ReactOS (expect this to also grow)
• Video hardware supporting VGA (640x480x4 minimum) or VESA 2.0
• PS/2 mouse and keyboard (full USB device support will probably be poor for a long time yet)
• and an IDE or SATA CD drive for loading ReactOS (at least until USB drives are better supported).

Optional:

• serial port on COM1 (highly recommended for using a host PC to capture debugger output)
• network adapter using the Realtek 8139 chip supported by ReactOS's driver (ReactOS doesn't yet play well with other network adapter drivers)

Desktop PCs are much more likely to run ReactOS than laptops. Laptop makers often use hardware and BIOS trickery in their products and their keyboards and mice are sometimes implemented as USB devices. Such tricks can expose portions of ReactOS that are not yet well implemented.

I have never found an explicit definition of a ReactOS hardware target anywhere in the ReactOS.org web site. The developers (devs) might never write one. However the intentions of the devs can be inferred from what devs write in the forums and which hardware related bugs they choose to work on. I believe the devs intend for ReactOS to run on common hardware that can also run Microsoft Windows Server 2003 SP1 or SP2. Of course, their intentions are often frustrated by ReactOS's alpha status. Here is dev Amine Khaldi answering a question last year in the topic "What is needed to get ReactOS to work on real hardware":

So what are the main obstacles to keeping ROS from working on a lot of target hardware?

Hmm, a tricky question, because many factors can be involved.. Off the top of my head:

* We try to prioritize VMs over real hardware because of the convenience and the practicality in terms of debugging/testing...etc. Real hardware with null modem cables and testers who can use CD-RWs for example and try different combinations, get logs, interact with developers suggestions and ideas...etc could be the equivalent of the VM testers, but as you can see only very few can manage that kind of effort.
* We're in the process of rewriting major parts of the OS in general (kernel, drivers, subsystem...etc) and that directly affects hardware compatibility. For example the PnP Manager is not even rewritten yet.
* Hardware compatibility progresses much more efficiently when the developer (familiar with that specific area) tests and debugs the piece of hardware, otherwise we fall back to the testing process mentioned above, which relies on testers doing so much work to help the developer inspect the issue "remotely".
* The obvious problem being lack of resources (developers and testers).