Dual core processor with too old an operating system.
 

Hi:
(a)
Let's say your machine has a CPU which is a processor with two cores. Let's further suppose that the O.S. boots correctly and works OK. Can this O.S. be so old that only one of the processor cores is being used all the time?

(b)
As an example, CPU= Pentium G620, O.S.= Windows XP
As another example, same CPU, O.S.= Slackware 12.0

In the second case, one can choose the symetric multiprocessor kernel (smp) so, I think this kernel would use the dual core feature of the CPU.

So, these are three questions really. That in (a), and what would happen in each of the examples in (b).

NOTE: In (a) I have used the words O.S. as meaning the kernel as well as the set of GNU programs in the case of GNU/Linux.

Linux has the SMP option for a long time. With any older OS you can recompile the kernel with that option, if you don't have a kernel available with that option. Otherwise the kernel would just use only one CPU core.
The real problem with older OSes/kernels is not multicore support, but lack of drivers for newer hardware.
May I ask why you want to run an older OS on your new hardware? Especially with Slackware the differences between the versions are not so significant, except better hardware support (especially the free video drivers) and better support from SBo.

Yes and no.

It is (or was) possible to install OSes that dont support multicore CPUs e.g. Win98. There isissues around support, and hardware (you've got to have the right hardware for win98 to install to, too much RAM, to big a video card etc. and it wont install. Anything you will find now will not support win98).

But in that case I wouldnt say that the OS 'works OK'. Its at best crippled, at worst a disaster that will kill hardware.

I was wondering the same thing. I'll take a guess that stf92 is using slackware 12.0 on the older system they have and want to use the version they are used to.

I'd be loading slackware 14.0 on that system.

@TobiSGD:

Those of (b) were only examples to make myself clearer. The true scenario is Pentium G620 with two OSs on the hard disk: slackware 14.0 and windows XP. Is XP a multiprocessor O.S.?

@cascade9:

You know I'm installing 14.0 in my newer machine right now? The stronger reason I have had for using old Slackware versions has been the greater ease if I have to study, as someday I'll do, startup scripts for example. And so many other things. The smaller the system, the more intimate knowledge you can aspire to get. For me, the ideal system is one made by me from scratch, with everything designed by me. With natural exceptions, of course. I wont't be designing the CPU or the CRT controller (love CRTs) which would be included in that system. But I did once designed a dynamic memory controller for eight dynamic RAMs. And it worked. Have you ever wondered why the slogan of utorrent is tiny but powerful?

Yes, it is. It isn't good with a mix of multicore and Hyperthreading, but since your CPU does not support Hyperthreading that is not an issue for you. But don't expect that your old installation will run on the newer system (without major complications), you will have to make a fresh install.

The G620 is a perfect example for what I said earlier. While from the CPU side there should be no problems with Slackware 12.0, the inbuilt videochip will only work with the generic vesa drivers, but not with the Intel drivers, since they don't support that device on the older version. With Slackware 14 there should be no problem.

As stated earlier, the differences between the versions are not that big. But keep in mind that sometimes what you learn on those older versions will no longer apply to newer versions, but you may need a newer version for hardware support.

Sounds to me that you rather want to run LFS, Gentoo or one of the other source based distros.

My first desktop with a color monitor and, oh!, a CD-ROM unit, came with the CD to install Win95. But there was a problem in connection with some software components in Win95, and I soon saw myself using Win98. The machine was a Pentium I, the first member of the P5 family of Intel's processors, also known as 80586 for consistency with the old naming convention. I still have a machine running Win98 and everything said about this OS matters me (though I liked Win95 better).

When all I knew was MS-DOS, save for some exotic machines/OSes (I began as an assembler programmer working for the Motorola 6800, and soon shifted to Intel's 8080), I had a rule of thumb, regarding compatibility. there is the machine (supposed here to be some model within the IMP PC range through the years), there is the OS (some version of the DOS/Windows OS), and there are the applications (in fact there are as many layers of software as you want to define). And you may ask: will this version of the OS work on a machine this old (or this new)? Is that too old a program for this machine? To have compatibility all the way through, the following must be true (I did not read this anywhere; it's what experience guided by logic has taught me within the IBM/Intel/Microsoft world):

Application program <= OS <= machine.

Here, '<=' relates ages. E.g., 'OS <= machine' means the machine must be as old as the OS or newer. If intel went from 286 to 386, then every program written for 286 was guaranteed to work on 386. The inverse was not necessarily true.

So any question about compatibility could be answered by substituting into the equation and checking if the inequalities were satisfied, provided, of course, that the software manufacturer had stick to the rules.

But then, ... I just now see your point. According to the equation, one should expect new machines to run Win98 OK (Win98 would just be unaware of a large subset of the hardware, and that would be all). And your point is that they don't.

Very well. I have written a lot, and faced now with the necessity to erase it all, I deny that necessity and leave this post as is. Else it would be too frustrating.

Behind the scenes, there's bus widths, addressing modes, and cpu behaviour.

I had a €4k machine which was feeding my family here 1994-2006 and it needed dos. Once we passed i586, the software wouldn't run because (if you wrote assembler you'd get this) the program startup behaviour changed - internal cpu modes I think. Nothing can run 16 bit software now. I had to keep an i586 for it.

Every machine machine I come across (assuming it is an IA32 or AMD64 machine) is still able to run DOS and 16 bit programs.

i am familiar with older os's, having starting with dos and win 3.1 on a 286, as a user and a software/hardware repair specialist since windows 2000 on MS based systems, but not from the view of a programmer, or as a linux user, having only recently switched... i understand the enjoyment of older os's, windows 2000 was my personal favorite of the microsoft family, as it felt like win 98 with the power and networking capabilities of nt...

Having said this, as i understand your question is you have alot of software you have written that is designed for use with older OS'S that will be unusable under new architecture due to the way the older systems handled interaction with the hardware... couldn't you achieve you desire to continue to use those tools on a modern os and new hardware through hardware and software emulation within the newer system? i know microsoft implemented this technique pretty poorly, but in linux from what i have seen there are alot more powerful tools that directly emulates older hardware within it's own sandbox, that handles the interaction with the modern hardware and os pretty seamlessly, or even creating it's own filesystem within the new enviroment allowing installation of older OS's within the hardware emulation sandbox (probably not the proper terminology, but i hope you understand what i mean). unless i am misunderstanding your problem, is this a workable solution that would suit your needs?

-OcO-

That may be. Nothing would run that, above an i586 and I had every generation of amd cpu up to the Athlon

A yes. The OS and hardware are separate. We have many single thread systems still in use and the hardware has been updated.

B the kernel is only part of the issue. Drivers and and other parts of the OS and apps need to utilize the extra core. It also has to have chip set support in some place.

If you don't believe your system will boot into dos then try freedos. It is not really improved dos, it just adds in some modern hardware outside of the original dos.

It actually booted command.com - perhaps I didn't make that clear. No user programs with a .ovl worked - some chipset or cpu error. I'm happy to hear it works for others. I also had an ISA eprom programmer in the same box, with similar issues.

And I did put a closing date on the issue (2006) as I'm not trying to use it now, so there's not much point in thrashing it out now.