Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

8086 rules (Miscellaneous)

posted by mceric, Germany, 21.02.2024, 11:07

> https://en.wikipedia.org/wiki/Protected_mode
>
> This was not without its limitations. If an application utilized or relied
> on any of the techniques below, it would not run:
>
> Segment arithmetic
Segment arithmetic IS a limitation. A workaround to soften the pain of only being able to access 64k at a time by allowing those 64k to start at any multiple of 16 bytes. Being able to use 32-bit offsets directly is much better.

> Privileged instructions
> Direct hardware access
This is configurable. You can use protected mode to tap or block direct I/O, but you can also give protected mode tasks full permissions for all I/O ports.

Many instructions which are privileged did not even exist on 8086. They are privileged to make it possible to prevent tasks from interfering with each other.

> Writing to a code segment
This also is configurable: https://en.wikipedia.org/wiki/Segment_descriptor

As far as I remember, write-protected code segments became the default for Windows much later than Win9x, because app writers were used to overwriting code :-p

> Executing data
> Overlapping segments
Both probably is a misunderstanding: You can easily use the same area of memory for code and data, but you may have to use different segment descriptors. Nobody stops you from letting segment descriptors point to identical or at least overlapping areas of RAM.

You even get the flexibility to let the areas start at any offset instead of only multiples of 16 bytes like on 8086. However, the segment length has to be a multiple of 4 kB if you want it to be more than 1 MB. Operating systems with paging will want you to set both length and offset to multiples of 4 kB.

> Use of BIOS functions, due to the BIOS interrupts being reserved by
> Intel[31]
Very few PC designs kept the first 32 interrupts reserved for the CPU. I think the TI Professional PC did. However, most BIOSes will not like being called directly in protected mode. On the other hand, VESA VBE graphics BIOS explicitly offer a protected mode entry point.

> In reality, almost all DOS application programs violated these rules
Because of this, you have VM86 hardware support which makes it relatively easy for operating systems and even for drivers like EMM386 to create a task which runs believing that it would be running NOT in protected mode. To make old apps happy.

> ... what could I actually do, assuming I had an 80286 computer?
You can compile your apps to use protected mode to use all the advantages, or run your apps in real mode or in a VM86 task without having to change them.

> "binary compatibility with real-mode code" - sounds good.
You can either stay away from protected mode or use a VM86 host for that.

> "the ability to access up to 16 MB of physical memory, and 1 GB of virtual
> memory" - sounds good.
You will have to use protected mode for that. With 386, even the 16 MB limit no longer applies.

> But ... WHERE?
With a DOS Extender or by using any protected mode operating system of your choice.

> Is this something I could do on OS/2 1.x?
Probably.

> With an MZ executable? A .com?
Only with a DOS Extender.

> What are they advertising?
Hardware features. To use them, you would have to use them.

> NE executables didn't exist except on MSDOS 4.0,
> which may or may not buy something. Is that what
> they are advertising?
Probably not. I do not think MS DOS directly supported protected mode EXE files. So you still had to use a DOS Extender and you can use most of those with MSDOS 3.xx already.

> I didn't use OS/2 1.x, but it may have had an
> MSDOS window and an MSDOS fullscreen (as modern
> OS/2 does).
Probably, but if you only want MS DOS apps, then
you have no need to buy OS/2 or Windows. Unless
you want to run several of them in parallel, in
multiple windows. But then you will be limited
by how well OS/2 and Windows can keep them from
interfering with each other, because DOS apps
were not originally meant to be run like that.

> Or was the problem that MSDOS itself had used
> segment arithmetic in the MZ executable format
> such that it was not possible to run an
> unmodified MZ executable (at least one with
> more than 64k of code), in protected mode, no
> matter how well behaved the actual code was?
I doubt that anybody would recommend to run any
DOS app as-is directly in protected mode. That is
exactly what VM86 mode is for: To create an illusion
of "everything is as in those good old 8086 times"
for old DOS apps. If you want to use NEW features,
you also have to compile your apps to know them.

Anyway, https://wiki.syslinux.org/wiki/index.php?title=Doc/comboot
is an example of running a limited subset of DOS
com binaries outside an actual DOS, so you might
enjoy hearing about those. They are run in real
mode, though. The SYSLINUX family of boot loaders
and boot menus does not provide VM86 services.

---
FreeDOS / DOSEMU2 / ...

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 167 users online (0 registered, 167 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum