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

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

> 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