OSDev.org

I'm not actually an operating system developer, or even terribly knowledgeable about these things, but I thought there might be someone knowledgeable who could tell me: all the OSs that I'm aware of that run on the i386 platform use a flat address space model where user programs have access to a single 4 GB segment, divided up between OS space and program space. If so, why does the 386 platform have such complicated segmented memory capabilities if no commercial OS actually uses them? (Yes, I know that even with the flat address mode, segmentation is implicitly involved, but I'm talking about fully exploiting the capabilities of the processor).

I've read that the segmentation on the 80386 was influenced by the Multics operating system. Which begs the question: did the Intel designers expect Multics to be ported to the 80386? Were they expecting some other operating system would be written to use segmented memory?

I'm just wondering why the processor designers went to all that trouble to design a highly complex memory model that no system seems to have actually ever used.

glasper wrote:I'm just wondering why the processor designers went to all that trouble to design a highly complex memory model that no system seems to have actually ever used.

The answer is easy, your timeline has just the wrong direction.

At first the i386 design was createt, and after that OSs are developed for the i386 design.

So the correct question is: Why OS designers don't use this stuff?

hmm..


that is not the full truth! Operating Systems use the segmentation for other things like tss and so on. But there is no need to use segmentation on everything!

Segementation existed before the 386, of course. I'd imagine the undertaking of implementing a segmented model would be lessened by prior experience. The 386's segmentation is a beefed up, protected, etc, extension of crappy 286 extensions... almost

It probably also made a dual mode (real and protected) CPU easier to implement if they both shared the same memory model. Segments in real mode are effected by the GDT, etc, just like pmode (hense the introduction of "unreal" mode, et al).

Lastly, some OSs do use segments... at least I've heard of some amateur OSs doing so, in an attempt to make a highly secure OS. I was under the impression Linux also made *some* use of segments... I could be mistaken, though.

--Jeff

Windows also makes 'some' limited use of segmentation, but its right that major OSs don't really use segmentation, though i believe win3.1 did (it was a fully 32bit PMode OS)

the problem is segmentation is complicated and paging can do everything segments can, and more -- thats why x86-64 doesn't support segmentation at all

win 3.1 fully 32 bit? maybe you meant protected 16-bit mode?

no i don't, windows 3.0 supported 16bit PMode, but win3.1 was a fully 32bit OS and ran in 32bit PMode as did all win3.1 native applications -- however there wern't very many -- developers prefered compatability with win3.0

all drivers for win3.1 are 32bit PMode drivers (and can be identified by the .vxd extensions instead of the .drv extension used by 16bit PMode and windows-RMode, DOS RMode drivers use a .sys extension)

unfortunately, win3.1 (which should have been called windows 4 as it had a completely rewitten kernel iirc), never gained much popularaty from developers

The 80286 had a protected mode without paging. For memory protection it used ... segmentation!
But there haven't been really too many 16 bit pmode operating systems. OS/2 1.x would be another example.

The 80386 inherited all this and added paging.

JAAman wrote:no i don't, windows 3.0 supported 16bit PMode, but win3.1 was a fully 32bit OS and ran in 32bit PMode as did all win3.1 native applications -- however there wern't very many -- developers prefered compatability with win3.0

all drivers for win3.1 are 32bit PMode drivers (and can be identified by the .vxd extensions instead of the .drv extension used by 16bit PMode and windows-RMode, DOS RMode drivers use a .sys extension)

This is just wrong. Entirely wrong. Windows 3.1 was a 16-bit shell that ran on top of DOS. For most things, it relied on DOS drivers.

However, Windows 3.1 did use the 386 segmentation extensions. This allowed it exceed the 16 MB memory limitation of 286-style protected mode. Earlier versions of Windows did not support this, so they could only take advantage of 16 MB of memory.

JAAman wrote:unfortunately, win3.1 (which should have been called windows 4 as it had a completely rewitten kernel iirc), never gained much popularaty from developers

Funny you should say that. The OS that <i>was</i> originally called Windows 4.0 was later renamed Windows 95, and it did have a lot of 32-bit code, and it supported 32-bit programs.

no its not just a shell -- infact win3.1 is not even capable of using DOS drivers!! it had its own drivers for everything

DOS programs under win3.1 even run in VMode! (not the case with win3.0) -- however win3.1 did still have the 16MB limit (artificially imposed by the design of the memory manager)

win95 is called windows version 4 (the version number), but that doesn't change the fact that win3.1 was a total rewrite

win3.1 cannot use RMode drivers, and only uses 16bit PMode drivers for 3rd party devices that don't have 32bit drivers

however the winAPI interface, remained largely 16bit until win95

JAAman wrote:no its not just a shell -- infact win3.1 is not even capable of using DOS drivers!! it had its own drivers for everything

Funny, then, how back in the day I needed to get the DOS sound card drivers working before I could play sound in Windows 3.1, or how I had to get the DOS cdrom drivers working to access the cdrom drive in Windows 3.1.

I think perhaps anyone who is interested should just read the <a href="http://en.wikipedia.org/wiki/Windows_3.1x#Windows_3.2">wikipedia article</a>, however I'll point out a couple of your misconceptions about Windows 3.1.

JAAman wrote:DOS programs under win3.1 even run in VMode! (not the case with win3.0) -- however win3.1 did still have the 16MB limit (artificially imposed by the design of the memory manager)

It's true that in 386 enhanced mode, Windows 3.1 would run DOS programs in vm86 mode. It would also use vm86 mode to call DOS drivers which were still required for many things. If you were running into the 16 MB memory limitation, you were probably running in Standard Mode, not 386 Enhanced mode. This limit is not arbitrary, but rather a result of the fact that Standard Mode was designed for use on the 286, which had 24-bit physical addresses.

Standard mode and 386 Enhanced mode both ran in protected mode. The difference is that Standard Mode did not use any of the new features introduced in the 386, such as segments starting at addresses over 16 MB, vm86 mode, and paging. However, all programs for any of the modes were 16-bit, with the exception of the programs supported by the Win32s pacakge released later by Microsoft as an add-on.