Mixing
Which operating systems for 80286 computers allowed a process to use more than 128k data?
Clash Royale CLAN TAG#URR8PPP
up vote
6
down vote
favorite
Out of all the operating systems for the 80286 processor I found, only two make use of the protected mode's ability to load more than one segment for text and one for data. These are MS-DOS (through various DOS extenders) and Windows. All other operating systems I checked would only give one text segment and one data segment to each process and call it a day. Were there any other operating systems that made full use of protected mode segmentation on the 80286?
operating-system 80286 segmentation
edited 22 mins ago
IconDaemon
1033
asked 5 hours ago
fuz
469416
 |Â
show 3 more comments
up vote
6
down vote
favorite
Out of all the operating systems for the 80286 processor I found, only two make use of the protected mode's ability to load more than one segment for text and one for data. These are MS-DOS (through various DOS extenders) and Windows. All other operating systems I checked would only give one text segment and one data segment to each process and call it a day. Were there any other operating systems that made full use of protected mode segmentation on the 80286?
operating-system 80286 segmentation
edited 22 mins ago
IconDaemon
1033
asked 5 hours ago
fuz
469416
I can find a lot of sources that strongly imply that MINIX is an answer, but none that is a smoking gun. Certainly there is a whole-system limit of 16mb but confirmation of per-process limits so far eludes me. Maybe somebody else can help?
– Tommy
5 hours ago
2
@Tommy Minix is not the answer as far as I'm concerned. On Minix, each process has one text and one data/stack segment. Segment sizes are fixed at link time and can be changed by thechmemutility to give programs more space. It's not possible to change segment sizes at runtime, there isn't even abrksyscall!
– fuz
5 hours ago
you have definitively stomped on that suggestion. I'll wager there's at least one CP/M-86 program that just runs away with the environment and thereby is as valid an answer as DOS, but that also feels like a cheat. It'd be interesting to know what VisiOn does given that programs are interpreted, not natively compiled.
– Tommy
5 hours ago
3
What about Xenix 286?
– mannaggia
4 hours ago
1
Your title is a bit misleading - The answer to that question is "all".
– tofro
4 hours ago
 |Â
show 3 more comments
up vote
6
down vote
favorite
up vote
6
down vote
favorite
Out of all the operating systems for the 80286 processor I found, only two make use of the protected mode's ability to load more than one segment for text and one for data. These are MS-DOS (through various DOS extenders) and Windows. All other operating systems I checked would only give one text segment and one data segment to each process and call it a day. Were there any other operating systems that made full use of protected mode segmentation on the 80286?
operating-system 80286 segmentation
edited 22 mins ago
IconDaemon
1033
asked 5 hours ago
fuz
469416
Out of all the operating systems for the 80286 processor I found, only two make use of the protected mode's ability to load more than one segment for text and one for data. These are MS-DOS (through various DOS extenders) and Windows. All other operating systems I checked would only give one text segment and one data segment to each process and call it a day. Were there any other operating systems that made full use of protected mode segmentation on the 80286?
operating-system 80286 segmentation
operating-system 80286 segmentation
edited 22 mins ago
IconDaemon
1033
asked 5 hours ago
fuz
469416
edited 22 mins ago
IconDaemon
1033
asked 5 hours ago
fuz
469416
edited 22 mins ago
IconDaemon
1033
edited 22 mins ago
IconDaemon
1033
edited 22 mins ago
IconDaemon
1033
1033
asked 5 hours ago
fuz
469416
asked 5 hours ago
fuz
469416
asked 5 hours ago
fuz
469416
469416
I can find a lot of sources that strongly imply that MINIX is an answer, but none that is a smoking gun. Certainly there is a whole-system limit of 16mb but confirmation of per-process limits so far eludes me. Maybe somebody else can help?
– Tommy
5 hours ago
2
@Tommy Minix is not the answer as far as I'm concerned. On Minix, each process has one text and one data/stack segment. Segment sizes are fixed at link time and can be changed by thechmemutility to give programs more space. It's not possible to change segment sizes at runtime, there isn't even abrksyscall!
– fuz
5 hours ago
you have definitively stomped on that suggestion. I'll wager there's at least one CP/M-86 program that just runs away with the environment and thereby is as valid an answer as DOS, but that also feels like a cheat. It'd be interesting to know what VisiOn does given that programs are interpreted, not natively compiled.
– Tommy
5 hours ago
3
What about Xenix 286?
– mannaggia
4 hours ago
1
Your title is a bit misleading - The answer to that question is "all".
– tofro
4 hours ago
 |Â
show 3 more comments
I can find a lot of sources that strongly imply that MINIX is an answer, but none that is a smoking gun. Certainly there is a whole-system limit of 16mb but confirmation of per-process limits so far eludes me. Maybe somebody else can help?
– Tommy
5 hours ago
2
@Tommy Minix is not the answer as far as I'm concerned. On Minix, each process has one text and one data/stack segment. Segment sizes are fixed at link time and can be changed by thechmemutility to give programs more space. It's not possible to change segment sizes at runtime, there isn't even abrksyscall!
– fuz
5 hours ago
you have definitively stomped on that suggestion. I'll wager there's at least one CP/M-86 program that just runs away with the environment and thereby is as valid an answer as DOS, but that also feels like a cheat. It'd be interesting to know what VisiOn does given that programs are interpreted, not natively compiled.
– Tommy
5 hours ago
3
What about Xenix 286?
– mannaggia
4 hours ago
1
Your title is a bit misleading - The answer to that question is "all".
– tofro
4 hours ago
I can find a lot of sources that strongly imply that MINIX is an answer, but none that is a smoking gun. Certainly there is a whole-system limit of 16mb but confirmation of per-process limits so far eludes me. Maybe somebody else can help?
– Tommy
5 hours ago
I can find a lot of sources that strongly imply that MINIX is an answer, but none that is a smoking gun. Certainly there is a whole-system limit of 16mb but confirmation of per-process limits so far eludes me. Maybe somebody else can help?
– Tommy
5 hours ago
2
2
@Tommy Minix is not the answer as far as I'm concerned. On Minix, each process has one text and one data/stack segment. Segment sizes are fixed at link time and can be changed by the
chmem utility to give programs more space. It's not possible to change segment sizes at runtime, there isn't even a brk syscall!– fuz
5 hours ago
@Tommy Minix is not the answer as far as I'm concerned. On Minix, each process has one text and one data/stack segment. Segment sizes are fixed at link time and can be changed by the
chmem utility to give programs more space. It's not possible to change segment sizes at runtime, there isn't even a brk syscall!– fuz
5 hours ago
you have definitively stomped on that suggestion. I'll wager there's at least one CP/M-86 program that just runs away with the environment and thereby is as valid an answer as DOS, but that also feels like a cheat. It'd be interesting to know what VisiOn does given that programs are interpreted, not natively compiled.
– Tommy
5 hours ago
you have definitively stomped on that suggestion. I'll wager there's at least one CP/M-86 program that just runs away with the environment and thereby is as valid an answer as DOS, but that also feels like a cheat. It'd be interesting to know what VisiOn does given that programs are interpreted, not natively compiled.
– Tommy
5 hours ago
3
3
What about Xenix 286?
– mannaggia
4 hours ago
What about Xenix 286?
– mannaggia
4 hours ago
1
1
Your title is a bit misleading - The answer to that question is "all".
– tofro
4 hours ago
Your title is a bit misleading - The answer to that question is "all".
– tofro
4 hours ago
 |Â
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
11
down vote
accepted
OS/2 supported “huge memory†on 286s. Using the DosAllocHuge function, programs could allocate more than 64KiB of memory, and would get a sequence of segment selectors which could be used to easily access all the allocated memory. The process is detailed in section 9.2.2 of Gordon Letwin’s Inside OS/2.
Xenix 286 also supported multiple text and data segments; processes with multiple segments were called “large model processes†(the same terminology as was used with C compilers under DOS). See Overview of the Xenix 286 Operating System.
FlexOS 286 (and perhaps Concurrent DOS 286) also allowed programs to allocate multiple segments. malloc could only allocate up to 64KiB at once, but programs could call it multiple times to allocate more than 64KiB in total in multiple segments.
I suspected Coherent 3 might have supported multiple segments, but it turns out that’s not the case, at least according to the Coherent 3.2 FAQ (question 7).
answered 4 hours ago
Stephen Kitt
32.4k4130151
Oh yeah, I totally forgot about OS/2. Any others you know of?
– fuz
4 hours ago
I'm pretty sure Concurrent DOS 286 could give something close to 1 Meg. (depending on how many holes for BIOS, video, etc.) per process. Even older CDOS on 8088/8086 could do that using LIM EMS - limiting processing to 128k in CDOS 286 would have made it totally useless. Of course once the 386 came along CDOS 386 did it all much better.
– manassehkatz
4 hours ago
2
QNX is another likely candidate. Versions up to 4 ran on 286s. Some applications of the system (eg "QNX Windows", a variant with an openlook based GUI) required multiple megabytes of memory, so must have been running in protected mode. It would seem unusual for a system to require that much memory but only give out 128KiB per process.
– Jules
3 hours ago
OS/2's New Executable format, the same format used by 16-bit Windows executables, allows programs to start off with multiple code and data segments, just like with Xenix.
– Ross Ridge
2 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
accepted
OS/2 supported “huge memory†on 286s. Using the DosAllocHuge function, programs could allocate more than 64KiB of memory, and would get a sequence of segment selectors which could be used to easily access all the allocated memory. The process is detailed in section 9.2.2 of Gordon Letwin’s Inside OS/2.
Xenix 286 also supported multiple text and data segments; processes with multiple segments were called “large model processes†(the same terminology as was used with C compilers under DOS). See Overview of the Xenix 286 Operating System.
FlexOS 286 (and perhaps Concurrent DOS 286) also allowed programs to allocate multiple segments. malloc could only allocate up to 64KiB at once, but programs could call it multiple times to allocate more than 64KiB in total in multiple segments.
I suspected Coherent 3 might have supported multiple segments, but it turns out that’s not the case, at least according to the Coherent 3.2 FAQ (question 7).
answered 4 hours ago
Stephen Kitt
32.4k4130151
Oh yeah, I totally forgot about OS/2. Any others you know of?
– fuz
4 hours ago
I'm pretty sure Concurrent DOS 286 could give something close to 1 Meg. (depending on how many holes for BIOS, video, etc.) per process. Even older CDOS on 8088/8086 could do that using LIM EMS - limiting processing to 128k in CDOS 286 would have made it totally useless. Of course once the 386 came along CDOS 386 did it all much better.
– manassehkatz
4 hours ago
2
QNX is another likely candidate. Versions up to 4 ran on 286s. Some applications of the system (eg "QNX Windows", a variant with an openlook based GUI) required multiple megabytes of memory, so must have been running in protected mode. It would seem unusual for a system to require that much memory but only give out 128KiB per process.
– Jules
3 hours ago
OS/2's New Executable format, the same format used by 16-bit Windows executables, allows programs to start off with multiple code and data segments, just like with Xenix.
– Ross Ridge
2 hours ago
add a comment |Â
up vote
11
down vote
accepted
OS/2 supported “huge memory†on 286s. Using the DosAllocHuge function, programs could allocate more than 64KiB of memory, and would get a sequence of segment selectors which could be used to easily access all the allocated memory. The process is detailed in section 9.2.2 of Gordon Letwin’s Inside OS/2.
Xenix 286 also supported multiple text and data segments; processes with multiple segments were called “large model processes†(the same terminology as was used with C compilers under DOS). See Overview of the Xenix 286 Operating System.
FlexOS 286 (and perhaps Concurrent DOS 286) also allowed programs to allocate multiple segments. malloc could only allocate up to 64KiB at once, but programs could call it multiple times to allocate more than 64KiB in total in multiple segments.
I suspected Coherent 3 might have supported multiple segments, but it turns out that’s not the case, at least according to the Coherent 3.2 FAQ (question 7).
answered 4 hours ago
Stephen Kitt
32.4k4130151
Oh yeah, I totally forgot about OS/2. Any others you know of?
– fuz
4 hours ago
I'm pretty sure Concurrent DOS 286 could give something close to 1 Meg. (depending on how many holes for BIOS, video, etc.) per process. Even older CDOS on 8088/8086 could do that using LIM EMS - limiting processing to 128k in CDOS 286 would have made it totally useless. Of course once the 386 came along CDOS 386 did it all much better.
– manassehkatz
4 hours ago
2
QNX is another likely candidate. Versions up to 4 ran on 286s. Some applications of the system (eg "QNX Windows", a variant with an openlook based GUI) required multiple megabytes of memory, so must have been running in protected mode. It would seem unusual for a system to require that much memory but only give out 128KiB per process.
– Jules
3 hours ago
OS/2's New Executable format, the same format used by 16-bit Windows executables, allows programs to start off with multiple code and data segments, just like with Xenix.
– Ross Ridge
2 hours ago
add a comment |Â
up vote
11
down vote
accepted
up vote
11
down vote
accepted
OS/2 supported “huge memory†on 286s. Using the DosAllocHuge function, programs could allocate more than 64KiB of memory, and would get a sequence of segment selectors which could be used to easily access all the allocated memory. The process is detailed in section 9.2.2 of Gordon Letwin’s Inside OS/2.
Xenix 286 also supported multiple text and data segments; processes with multiple segments were called “large model processes†(the same terminology as was used with C compilers under DOS). See Overview of the Xenix 286 Operating System.
FlexOS 286 (and perhaps Concurrent DOS 286) also allowed programs to allocate multiple segments. malloc could only allocate up to 64KiB at once, but programs could call it multiple times to allocate more than 64KiB in total in multiple segments.
I suspected Coherent 3 might have supported multiple segments, but it turns out that’s not the case, at least according to the Coherent 3.2 FAQ (question 7).
answered 4 hours ago
Stephen Kitt
32.4k4130151
OS/2 supported “huge memory†on 286s. Using the DosAllocHuge function, programs could allocate more than 64KiB of memory, and would get a sequence of segment selectors which could be used to easily access all the allocated memory. The process is detailed in section 9.2.2 of Gordon Letwin’s Inside OS/2.
Xenix 286 also supported multiple text and data segments; processes with multiple segments were called “large model processes†(the same terminology as was used with C compilers under DOS). See Overview of the Xenix 286 Operating System.
FlexOS 286 (and perhaps Concurrent DOS 286) also allowed programs to allocate multiple segments. malloc could only allocate up to 64KiB at once, but programs could call it multiple times to allocate more than 64KiB in total in multiple segments.
I suspected Coherent 3 might have supported multiple segments, but it turns out that’s not the case, at least according to the Coherent 3.2 FAQ (question 7).
answered 4 hours ago
Stephen Kitt
32.4k4130151
edited 4 hours ago
answered 4 hours ago
Stephen Kitt
32.4k4130151
answered 4 hours ago
Stephen Kitt
32.4k4130151
answered 4 hours ago
Stephen Kitt
32.4k4130151
32.4k4130151
Oh yeah, I totally forgot about OS/2. Any others you know of?
– fuz
4 hours ago
I'm pretty sure Concurrent DOS 286 could give something close to 1 Meg. (depending on how many holes for BIOS, video, etc.) per process. Even older CDOS on 8088/8086 could do that using LIM EMS - limiting processing to 128k in CDOS 286 would have made it totally useless. Of course once the 386 came along CDOS 386 did it all much better.
– manassehkatz
4 hours ago
2
QNX is another likely candidate. Versions up to 4 ran on 286s. Some applications of the system (eg "QNX Windows", a variant with an openlook based GUI) required multiple megabytes of memory, so must have been running in protected mode. It would seem unusual for a system to require that much memory but only give out 128KiB per process.
– Jules
3 hours ago
OS/2's New Executable format, the same format used by 16-bit Windows executables, allows programs to start off with multiple code and data segments, just like with Xenix.
– Ross Ridge
2 hours ago
add a comment |Â
Oh yeah, I totally forgot about OS/2. Any others you know of?
– fuz
4 hours ago
I'm pretty sure Concurrent DOS 286 could give something close to 1 Meg. (depending on how many holes for BIOS, video, etc.) per process. Even older CDOS on 8088/8086 could do that using LIM EMS - limiting processing to 128k in CDOS 286 would have made it totally useless. Of course once the 386 came along CDOS 386 did it all much better.
– manassehkatz
4 hours ago
2
QNX is another likely candidate. Versions up to 4 ran on 286s. Some applications of the system (eg "QNX Windows", a variant with an openlook based GUI) required multiple megabytes of memory, so must have been running in protected mode. It would seem unusual for a system to require that much memory but only give out 128KiB per process.
– Jules
3 hours ago
OS/2's New Executable format, the same format used by 16-bit Windows executables, allows programs to start off with multiple code and data segments, just like with Xenix.
– Ross Ridge
2 hours ago
Oh yeah, I totally forgot about OS/2. Any others you know of?
– fuz
4 hours ago
Oh yeah, I totally forgot about OS/2. Any others you know of?
– fuz
4 hours ago
I'm pretty sure Concurrent DOS 286 could give something close to 1 Meg. (depending on how many holes for BIOS, video, etc.) per process. Even older CDOS on 8088/8086 could do that using LIM EMS - limiting processing to 128k in CDOS 286 would have made it totally useless. Of course once the 386 came along CDOS 386 did it all much better.
– manassehkatz
4 hours ago
I'm pretty sure Concurrent DOS 286 could give something close to 1 Meg. (depending on how many holes for BIOS, video, etc.) per process. Even older CDOS on 8088/8086 could do that using LIM EMS - limiting processing to 128k in CDOS 286 would have made it totally useless. Of course once the 386 came along CDOS 386 did it all much better.
– manassehkatz
4 hours ago
2
2
QNX is another likely candidate. Versions up to 4 ran on 286s. Some applications of the system (eg "QNX Windows", a variant with an openlook based GUI) required multiple megabytes of memory, so must have been running in protected mode. It would seem unusual for a system to require that much memory but only give out 128KiB per process.
– Jules
3 hours ago
QNX is another likely candidate. Versions up to 4 ran on 286s. Some applications of the system (eg "QNX Windows", a variant with an openlook based GUI) required multiple megabytes of memory, so must have been running in protected mode. It would seem unusual for a system to require that much memory but only give out 128KiB per process.
– Jules
3 hours ago
OS/2's New Executable format, the same format used by 16-bit Windows executables, allows programs to start off with multiple code and data segments, just like with Xenix.
– Ross Ridge
2 hours ago
OS/2's New Executable format, the same format used by 16-bit Windows executables, allows programs to start off with multiple code and data segments, just like with Xenix.
– Ross Ridge
2 hours ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8097%2fwhich-operating-systems-for-80286-computers-allowed-a-process-to-use-more-than-1%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
I can find a lot of sources that strongly imply that MINIX is an answer, but none that is a smoking gun. Certainly there is a whole-system limit of 16mb but confirmation of per-process limits so far eludes me. Maybe somebody else can help?
– Tommy
5 hours ago
2
@Tommy Minix is not the answer as far as I'm concerned. On Minix, each process has one text and one data/stack segment. Segment sizes are fixed at link time and can be changed by the
chmemutility to give programs more space. It's not possible to change segment sizes at runtime, there isn't even abrksyscall!– fuz
5 hours ago
you have definitively stomped on that suggestion. I'll wager there's at least one CP/M-86 program that just runs away with the environment and thereby is as valid an answer as DOS, but that also feels like a cheat. It'd be interesting to know what VisiOn does given that programs are interpreted, not natively compiled.
– Tommy
5 hours ago
3
What about Xenix 286?
– mannaggia
4 hours ago
1
Your title is a bit misleading - The answer to that question is "all".
– tofro
4 hours ago