> An x86 CPU will start in 16-bit mode when it's powered-up. I don't think
> there's any way to bypass that via anything. The only thing that a
> 32/64-bit BIOS can do is to make the switch to 32/64-bit mode earlier
> in the bootup process.
>
> However, such a BIOS could theoretically allow for a x86 CPU to drop
> 16-bit support completely (if the OS can, thanks to such a BIOS, assume
> the CPU is already running in 32/64-bit mode when it boots.)

Let us hope this happens someday.

> There are some completely different CPU architectures where the
> distinction between 32-bit and 64-bit modes is much more transparent.
> The UltraSparc would be a perfect example. It's so transparent that it
> doesn't even need separate modes for 32-bit and 64-bit code: They both
> run just fine as-is, even if you mix them up.

The Motorola 68000 was a 16-bit CPU, but it had opcodes for 32-bit 
operations. It's just that they take twice as long. Then if you upgrade 
to an M68020 (?), it's 32-bit, and all your software goes 2x as fast. 
(Because ALMOST EVERYTHING uses mostly 32-bit arithmetic.)

Going to 64-bit took longer, because nobody really needs 64-bit integer 
arithmetic (and we already have 80-bit floating-point arithmetic), so 
the only real advantage is increased address space. [Which only matters 
once GB-sized RAM started to be manufactured.]

Post a reply to this message

Am 22.01.2014 23:19, schrieb Orchid Win7 v1:
> On 22/01/2014 04:54 PM, Warp wrote:
>> Orchid Win7 v1<voi### [at] devnull>  wrote:
>>> Next up: Why, in the year 2014, am I still running installers that have
>>> 16-bit dithered logos? WTF?
>>
>> Obviously you need to be able to run it in safe mode...
>
> I didn't think even Safe Mode runs in 16-bit colour any more. And even
> if it does... so make the OS convert from 24-bit down to 16-bit on the
> fly! Sheesh.
>
>> Speaking of which, even though the 80386 processor was introduced
>> in 1985 (that's almost 30 years ago), PCs still boot up in 16-bit
>> mode. Yes, even the new 64-bit ones.
>
> I got the impression that 64-bit CPUs cut back on some of the really
> ancient 16-bit stuff. (I don't have an actual site for that though.)

That might well be. After all, you could emulate them via unknown-opcode 
traps.


>> The very first thing that the OS does is to switch to either 32-bit
>> mode (if the CPU is that old) or to 64-bit mode. After that it will
>> usually never revert back to 16-bit mode ever again.
>
> Ah yes - by toggling line 20 on the address bus. Obviously. (WTF?)

No, no - that A20 line thing is just for a small detail of the 16-bit mode.

> Well, that's only in so-called "IBM PC-compatibles". (How compatible are
> any of these with the 30-year old dinosaur?) I think the Apple Mac does
> it differently...

I'd be surprised if Macs came without A20 line gate. After all, it's the 
type of logic that's needed for IBM PC-compatibility but has been moved 
from discrete gates on the mainboard into the chipset decades ago already.


> Overall, PCs are just *full* of this crap. (Some of you may remember I
> once set out on a misguided quest to "write my own OS". I read up on
> some of this stuff.) And yet, when somebody produces a technically
> superior system that lacks lashings of backwards compatibility, nobody
> actually buys it...

... because of that very lack of backwards compatibility.

Actually, MS-DOS - and probably the IBM PCs as well - wouldn't have had 
any chance of success in the first place, had it not been for MS-DOS's 
backwards compatibility with CP/M at the application programming level.

Post a reply to this message

Am 22.01.2014 23:19, schrieb Orchid Win7 v1:

> (Some of you may remember I
> once set out on a misguided quest to "write my own OS". I read up on
> some of this stuff.)

That does sound like an intriguing challenge, provided you don't set out 
to design the best OS that has ever been.

If you get to the point where you can compile, link and run a "Hello 
World" C program on that platform, that's certainly good enough for 
starters.


And if PC hardware seems too messy and non-standardized (which most 
certainly is the case), something like the Raspberry Pi might be an 
interesting target.


Then again, why design a whole OS if I'd only want to run a very limited 
set of programs on it anyway... it can't be too complicated to build a 
POV-Ray version that runs directly atop the BIOS, can it? :-P

Post a reply to this message

On Thu, 23 Jan 2014 01:14:01 +0100, clipka wrote:

>> I got the impression that 64-bit CPUs cut back on some of the really
>> ancient 16-bit stuff. (I don't have an actual site for that though.)
> 
> That might well be. After all, you could emulate them via unknown-opcode
> traps.

I don't know if it's the case or not, but I had a recent discussion with 
someone about supporting NetWare 2.x (don't ask) on modern hardware, and 
the question of whether the A20 line was still supported on modern 
processors came up, because at least 2.15 and earlier require that.

Jim
-- 
"I learned long ago, never to wrestle with a pig. You get dirty, and 
besides, the pig likes it." - George Bernard Shaw

Post a reply to this message

On 1/22/2014 5:14 PM, clipka wrote:
>> Well, that's only in so-called "IBM PC-compatibles". (How compatible are
>> any of these with the 30-year old dinosaur?) I think the Apple Mac does
>> it differently...
>
> I'd be surprised if Macs came without A20 line gate. After all, it's the
> type of logic that's needed for IBM PC-compatibility but has been moved
> from discrete gates on the mainboard into the chipset decades ago already.
>

I thought that, some time back, the only "functional" difference between 
Mac and PC had finally come down to an extra chip on the board, which 
basically prevented the OS from booting, if it wasn't on a machine that 
had it, and.. I am guessing the GUI functionality isn't in firmware/ROM 
anymore, right? But, there was a whole huge thing with trying to get PC 
stuff to boot on a Mac, and a Mac to boot on standard PC hardware, and 
it all came down, not to architectural differences, so much as just, 
"There is this extra chip on the board."

Or, maybe I was just imagining that?

-- 
Commander Vimes: "You take a bunch of people who don't seem any 
different from you and me, but when you add them all together you get 
this sort of huge raving maniac with national borders and an anthem."

Post a reply to this message

>> (Some of you may remember I
>> once set out on a misguided quest to "write my own OS". I read up on
>> some of this stuff.)
>
> That does sound like an intriguing challenge, provided you don't set out
> to design the best OS that has ever been.

Rather, I set out to design an OS that doesn't work like Unix, and 
doesn't work like Windows. (Seemingly all extent OS designs are based on 
one or the other - but I remember a time before that...)

> If you get to the point where you can compile, link and run a "Hello
> World" C program on that platform, that's certainly good enough for
> starters.

Again, my goal was to design an OS where nothing is ever written in C, 
but rather written in safe higher-level languages with don't have buffer 
overrun exploits all over the place.

> And if PC hardware seems too messy and non-standardized (which most
> certainly is the case), something like the Raspberry Pi might be an
> interesting target.

The Raspberry Pi didn't exist ten years ago, but now that I think about 
it, that *would* be an interesting target...

> Then again, why design a whole OS if I'd only want to run a very limited
> set of programs on it anyway... it can't be too complicated to build a
> POV-Ray version that runs directly atop the BIOS, can it? :-P

The key problem with writing your own OS is that it's almost impossible 
to debug it! Not if you run it on real hardware, anyway. Last I checked, 
most VM software isn't really designed for this kind of thing either...

It's probably much, much easier to design something like the Java VM, 
and then write your own proto-OS that runs inside that. And if you ever 
get anywhere with that, *then* try targeting bare metal...

Post a reply to this message

Am 23.01.2014 09:51, schrieb Orchid Win7 v1:

> The key problem with writing your own OS is that it's almost impossible
> to debug it! Not if you run it on real hardware, anyway. Last I checked,
> most VM software isn't really designed for this kind of thing either...

It also can't be more difficult than debugging an embedded system, and 
I've been there, done that. Sending stuff to a serial port dedicated for 
debugging was the standard procedure, even for "applications". For the 
code portions running before the serial port was initialized, it was a 
PWM output line connected to an LED or a scope.

Using the JTAG port to make the MCU single-step through the code and to 
inspect the barebone register or memory values was another important tool.

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> Did you know that your graphics card starts up emulating an 
> IBM-manufactured video board from 27 years ago? And then you have to run 
> special driver software to turn off all the pointless emulation and put 
> the card into 24-bit, memory-mapped mode at a real-world screen 
> resolution. Go figure...

In theory a modern PC ought to be completely backwards-compatible with
the 16-bit PCs and thus, in theory, you ought to be able to run MS-DOS
in a modern PC. (All the required hardware is still there, most of it
artificially dragging the old technology for backwards compatibility,
the BIOS still supports all the system calls used by DOS, etc.)
However, I would be *really* surprised if you actually got MS-DOS
running natively on a modern PC.

There are many hurdles that you'll encounter. Firstly, you'll need a
hard drive that's small and old enough that MS-DOS will actually be able
to use it. Also, you'll need a PS/2 keyboard because MS-DOS has no idea
what USB is. There are also probably many problems you will encounter
due to the fact that your CPU is so damn fast.
(Also, be aware that MS-DOS has no concept of keeping the CPU in idle
mode. It will run it at 100% capacity all the time, so be prepared for
some noise. Luckily it will only keep one core at 100%. The others won't
even start.)

You *might* be able to make it at least boot up, with luck and a lot
of work, and perhaps even run some programs, but eg. the majority of
old DOS games probably won't work very well. Even if a game by some
miracle runs (rather than just crashing because the computer is a
thousand times faster than even the fastest that the programmers
expected), you won't get any sounds, and you won't be able to use a mouse
(unless you have a PS/2 one).

The thing is, nobody runs MS-DOS natively anymore, and haven't done so
for well over a decade. If you really need to run an old DOS program
you'll use DOSBox anyway. Not only will the program work, it's a million
times less hassle.

So why is the PC architecture dragging all the useless stuff for MS-DOS
compatibility, when nobody's running MS-DOS anyway?

-- 
                                                          - Warp

Post a reply to this message

>> The key problem with writing your own OS is that it's almost impossible
>> to debug it! Not if you run it on real hardware, anyway. Last I checked,
>> most VM software isn't really designed for this kind of thing either...
>
> It also can't be more difficult than debugging an embedded system, and
> I've been there, done that. Sending stuff to a serial port dedicated for
> debugging was the standard procedure, even for "applications". For the
> code portions running before the serial port was initialized, it was a
> PWM output line connected to an LED or a scope.
>
> Using the JTAG port to make the MCU single-step through the code and to
> inspect the barebone register or memory values was another important tool.

Yeah, embedded systems have a serial port so you can find out what's 
happening. But if the software on a desktop PC stops working... it's a 
brick. There's no way to interact with it. The best you can do is reboot it.

Post a reply to this message

On 23/01/2014 03:20 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> Did you know that your graphics card starts up emulating an
>> IBM-manufactured video board from 27 years ago? And then you have to run
>> special driver software to turn off all the pointless emulation and put
>> the card into 24-bit, memory-mapped mode at a real-world screen
>> resolution. Go figure...
>
> In theory a modern PC ought to be completely backwards-compatible with
> the 16-bit PCs and thus, in theory, you ought to be able to run MS-DOS
> in a modern PC. (All the required hardware is still there, most of it
> artificially dragging the old technology for backwards compatibility,
> the BIOS still supports all the system calls used by DOS, etc.)
> However, I would be *really* surprised if you actually got MS-DOS
> running natively on a modern PC.

Oh I don't know... It'll probably work.

> There are many hurdles that you'll encounter. Firstly, you'll need a
> hard drive that's small and old enough that MS-DOS will actually be able
> to use it.

I suspect so long as it isn't native 4K sectors, it'll just be reported 
as 2GB.

> Also, you'll need a PS/2 keyboard because MS-DOS has no idea
> what USB is.

Many PCs have a BIOS option for PS/2 emulation. That is, to make a USB 
keyboard appear to be a PS/2 one.

> There are also probably many problems you will encounter
> due to the fact that your CPU is so damn fast.

Hell yes!

> The thing is, nobody runs MS-DOS natively anymore, and haven't done so
> for well over a decade.

I'm pretty sure the in-store management system that John Lewis use is 
still DOS-based. (Whether it's running natively or in some emulation 
layer is another matter...)

> If you really need to run an old DOS program
> you'll use DOSBox anyway. Not only will the program work, it's a million
> times less hassle.
>
> So why is the PC architecture dragging all the useless stuff for MS-DOS
> compatibility, when nobody's running MS-DOS anyway?

No idea. Presumably because it would mean changing stuff?

Post a reply to this message

Am 23.01.2014 22:28, schrieb Orchid Win7 v1:
> On 23/01/2014 03:20 PM, Warp wrote:

>> There are many hurdles that you'll encounter. Firstly, you'll need a
>> hard drive that's small and old enough that MS-DOS will actually be able
>> to use it.
>
> I suspect so long as it isn't native 4K sectors, it'll just be reported
> as 2GB.

Bwahaha! Dream on :-P

I might be wrong, but I'd suspect you'll get anything from 2GB down to 
-2GB, depending on whatever value the result overflows to.

>> There are also probably many problems you will encounter
>> due to the fact that your CPU is so damn fast.
>
> Hell yes!

Indeed. IIRC even in the times of the 386DX-50, programs written in 
Turbo Pascal would already occasionally to crash with a division by zero 
right at the start, because in order to calibrate the delay() loop the 
runtime library would run the loop N times, figure out that it took 0 
seconds, and conclude that for 1 second it would need to run the loop 
N/0 times... Whoops!

Post a reply to this message

>>> There are many hurdles that you'll encounter. Firstly, you'll need a
>>> hard drive that's small and old enough that MS-DOS will actually be able
>>> to use it.
>>
>> I suspect so long as it isn't native 4K sectors, it'll just be reported
>> as 2GB.
>
> Bwahaha! Dream on :-P
>
> I might be wrong, but I'd suspect you'll get anything from 2GB down to
> -2GB, depending on whatever value the result overflows to.

And I think *you* will find that drives larger than 2GB report 
themselves using a different BIOS API.

>>> There are also probably many problems you will encounter
>>> due to the fact that your CPU is so damn fast.
>>
>> Hell yes!
>
> Indeed. IIRC even in the times of the 386DX-50, programs written in
> Turbo Pascal would already occasionally to crash with a division by zero
> right at the start, because in order to calibrate the delay() loop the
> runtime library would run the loop N times, figure out that it took 0
> seconds, and conclude that for 1 second it would need to run the loop
> N/0 times... Whoops!

OK, well I've never seen *that*... I have seen plenty of PCs with a 
"turbo" button though.

It was there for a reason.

Post a reply to this message

>> The thing is, nobody runs MS-DOS natively anymore, and haven't done so
>> for well over a decade.
>
> I'm pretty sure the in-store management system that John Lewis use is
> still DOS-based. (Whether it's running natively or in some emulation
> layer is another matter...)

http://en.wikipedia.org/wiki/MSDOS

"As of 2011, MS-DOS is still used in some enterprises to run legacy 
applications, such as this US Navy food service management system."

It is unclear whether this is with or without emulation, however. And 
they could just be running this stuff on really ancient hardware. (When 
I left my previous company, we still had a box in storage with Windows 
98 installed on it. Mercifully, I *never* needed to power it up!)

Post a reply to this message

Le 2014-01-23 16:28, Orchid Win7 v1 a écrit :
>
> Oh I don't know... It'll probably work.
>
>> There are many hurdles that you'll encounter. Firstly, you'll need a
>> hard drive that's small and old enough that MS-DOS will actually be able
>> to use it.
>
> I suspect so long as it isn't native 4K sectors, it'll just be reported
> as 2GB.

No.  The boot drive had to have a primary partition that is less than 
2GB, and fits entirely below cylinder 1023 or else DOS won't understand 
it.  You also need a special driver that loads before IO.SYS in order to 
fake the number of heads and cylinders because it doesn't understand LBA 
mode.  This has been the case as far back as drives that had more than 
1GB of space (Anyone remember OnTrack Disk Manager?), since it usually 
meant more than 1024 cylinders, as you couldn't fit more than 2 platters 
in a regular drive bay.

>> So why is the PC architecture dragging all the useless stuff for MS-DOS
>> compatibility, when nobody's running MS-DOS anyway?
>
> No idea. Presumably because it would mean changing stuff?

You can rest assured that somewhere, there's a nuclear reactor or a 
stock-exchange trading application, or an airline flight scheduler or 
something of the sort that still relies on a DOS based controller, ans 
as long as this exists, no hardware maker is going to risk stopping 
support for it for fear of losing business.

Heck, I just saw today that IBM still officially releases JREs of its 
own flavor of Java for OS/2 Warp.  There mu$t be a good rea$on for it.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2014-01-22 16:18, Dre a écrit :
> On 22/01/2014 1:40 AM, Francois Labreque wrote:
>> not quite, but...
>>
>> Ever since I tried to install the latest Blender, whenever I boot my PC,
>> I get the system32 folder that opens.  I suppose there's a registry
>> entry somewhere that got created improperly and instead of trying to
>> load "C:\Windows\System32\whatchamacallit.dll" or
>> "%SYSTEM_ROOT%\System32\foobar.exe" it simply loads
>> "C:\Windows\System32".
>>
>> How do I find out which one it is?  Regedit's search function is not
>> smart enough to let me search for ( "system32" except when it's
>> "system32\" )
>>
>>
>
> I've seen this before, have a look here:
>
> http://support.microsoft.com/kb/170086
>
> Cheers Dre

This KB article sent me on the proper path...

I paid a closer look at the syntax of the entries in 
HLCU\Software\Microsoft\Windows\CurrentVersion\Run, and bingo.

It was an invalid entry created by the Epson Printer software installer. 
  (Apologies to the Blender Foundation for wrongly acusing them!)

I also found a gazillion entries where rundll32.exe is not using the 
full path, which could lead to very easy trojan horse injections.

ex:
Good:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\htmlfile\shell\print\command]
@="\"C:\\WINDOWS\\system32\\rundll32.exe\" 
\"C:\\WINDOWS\\system32\\mshtml.dll\",PrintHTML \"%1\""


Bad:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\jpegfile\shell\open\command]
@="rundll32.exe C:\\WINDOWS\\system32\\shimgvw.dll,ImageView_Fullscreen %1"

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

> The Raspberry Pi didn't exist ten years ago, but now that I think about
> it, that *would* be an interesting target...

Here's a start:

http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/index.html

Post a reply to this message