Mixing
Were later MS-DOS versions still implemented in x86 assembly?
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Recently, Microsoft published the source code of old MS-DOS versions on Github: https://github.com/Microsoft/MS-DOS
What is odd in my opinion is the use of x86 assembly language for everything. The assembly language would not be my first choice for implementing an operating system. At the time MS-DOS was created, the C programming language had already been invented in Bell Labs, offering a good compromise between low level and high level programming.
Was this assembly language approach used also in the newest versions of MS-DOS in the 1990s?
history assembly operating-system
asked 5 hours ago
juhist
1955
add a comment |Â
up vote
2
down vote
favorite
Recently, Microsoft published the source code of old MS-DOS versions on Github: https://github.com/Microsoft/MS-DOS
What is odd in my opinion is the use of x86 assembly language for everything. The assembly language would not be my first choice for implementing an operating system. At the time MS-DOS was created, the C programming language had already been invented in Bell Labs, offering a good compromise between low level and high level programming.
Was this assembly language approach used also in the newest versions of MS-DOS in the 1990s?
history assembly operating-system
asked 5 hours ago
juhist
1955
The MS_DOS ABI (if we can call it that) is an assembly register interface. It would be quite inconvenient to implement that in C.
– tofro
1 hour ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Recently, Microsoft published the source code of old MS-DOS versions on Github: https://github.com/Microsoft/MS-DOS
What is odd in my opinion is the use of x86 assembly language for everything. The assembly language would not be my first choice for implementing an operating system. At the time MS-DOS was created, the C programming language had already been invented in Bell Labs, offering a good compromise between low level and high level programming.
Was this assembly language approach used also in the newest versions of MS-DOS in the 1990s?
history assembly operating-system
asked 5 hours ago
juhist
1955
Recently, Microsoft published the source code of old MS-DOS versions on Github: https://github.com/Microsoft/MS-DOS
What is odd in my opinion is the use of x86 assembly language for everything. The assembly language would not be my first choice for implementing an operating system. At the time MS-DOS was created, the C programming language had already been invented in Bell Labs, offering a good compromise between low level and high level programming.
Was this assembly language approach used also in the newest versions of MS-DOS in the 1990s?
history assembly operating-system
history assembly operating-system
asked 5 hours ago
juhist
1955
asked 5 hours ago
juhist
1955
asked 5 hours ago
juhist
1955
asked 5 hours ago
juhist
1955
asked 5 hours ago
juhist
1955
1955
The MS_DOS ABI (if we can call it that) is an assembly register interface. It would be quite inconvenient to implement that in C.
– tofro
1 hour ago
add a comment |Â
The MS_DOS ABI (if we can call it that) is an assembly register interface. It would be quite inconvenient to implement that in C.
– tofro
1 hour ago
The MS_DOS ABI (if we can call it that) is an assembly register interface. It would be quite inconvenient to implement that in C.
– tofro
1 hour ago
The MS_DOS ABI (if we can call it that) is an assembly register interface. It would be quite inconvenient to implement that in C.
– tofro
1 hour ago
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
4
down vote
accepted
C did exist when DOS was developed, but it wasn’t used much outside the Unix world. SCP developed DOS in assembly for a few very pragmatic reasons:
The last design requirement was that MS-DOS be written in assembly language. While this characteristic does help meet the need for speed and efficiency, the reason for including it is much more basic. The only 8086 software-development tools available to Seattle Computer at that time were an assembler that ran on the Z80 under CP/M and a monitor/debugger that fit into a 2K-byte EPROM (erasable programmable read-only memory). Both of these tools had been developed in house.
As you’ve seen from the code available for MS-DOS 1.25 and 2.11, these versions were also written in assembly language. That code was never entirely rewritten, so there never was the opportunity to rewrite it in a higher-level language; nor was the need ever felt, I suspect — assembly was the language of choice for system tools on PCs for a long time, and system developers were as familiar with assembly as with any other language.
Some tools added in later versions were developed in C; a quick look through MS-DOS 6.22 shows that, for example, DEFRAG, FASTHELP, MEMMAKER and SCANDISK were written in C. FDISK is also a C program in 6.22; I haven’t checked its history if it started out in assembly and was rewritten (in early versions of DOS, it wasn’t provided by Microsoft but by OEMs).
answered 2 hours ago
Stephen Kitt
31.3k4126149
add a comment |Â
up vote
2
down vote
This isn't an answer but too long for a comment.
Yes - C has been around since 1972 but there were no MSDOS C compilers until the late 80s. To convert an entire OS from Assembler to C would be a mammoth task. Even though it might be easier to maintain, it could be a lot slower.
You can see the result of conversion when you compare Visual Studio 2008 to VS2010. This was a full blown conversion from C to C#. OK - it is easier to maintain from the Vendor's point of view but the new product is 24 times slower: on a netbook, 2008 loads in 5s, 2010 takes almost 2 minutes.
answered 4 hours ago
cup
48117
1
Assembly to C, and C to C# cannot really be compared, as C# is a JIT'd GC'd memory-safe language, whereas C is very close to Assembly in the features it provides, being just easier to write and maintain. Anyway, "entire OS" for MS-DOS is quite little code, so converting it to C, either completely or partially, wouldn't be such a large task.
– juhist
3 hours ago
OK, maybe C to C# was a bad example. It is the little specialist instructions like IN and OUT, which are used a lot in device drivers that cause no end of problems with many C compilers. I don't know what instructions are used but stuff like REPZ often has to be hand coded: there are no C equivalents.
– cup
3 hours ago
@juhist Try actually doing some of the conversion yourself, then tell us whether it was really a large task or not. (Oh, and make sure you regression test every edge and corner case, just to be sure your C version doesn't change the behaviour of anything, not just what the (buggy and incomplete) user documentation says is valid!
– alephzero
3 hours ago
add a comment |Â
up vote
1
down vote
Answering the question - yes.
For the rationale: there's very little gain in rewriting functioning code (unless for example you have portability specifically in mind).
The "newest version" of any major program generally contains much of the code of the previous version, so again, why spend programmer time on rewriting existing features instead of adding new features?
answered 2 hours ago
dave
111
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
From The OS/2 Museum page about DOS3: "The new ATTRIB.EXE utility allowed the user to manipulate file attributes (Read-only, Hidden, System, etc.). It is notable for being the first DOS utility written in C (up to that point, all components in DOS were written in assembly language) and contains the string “Zbikowski C startup Copyright 1983 (C) Microsoft Corpâ€Â, clearly identifying Mark Zbikowski’s handiwork."
I realise that this doesn't really answer the question, but gives an idea of how DOS was implemented. Also remember that the operating system had to be as small as possible so as to leave room for user programs, so the resident part of COMMAND.COM would have stayed written in Assembly.
answered 1 hour ago
No'am Newman
246125
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
C did exist when DOS was developed, but it wasn’t used much outside the Unix world. SCP developed DOS in assembly for a few very pragmatic reasons:
The last design requirement was that MS-DOS be written in assembly language. While this characteristic does help meet the need for speed and efficiency, the reason for including it is much more basic. The only 8086 software-development tools available to Seattle Computer at that time were an assembler that ran on the Z80 under CP/M and a monitor/debugger that fit into a 2K-byte EPROM (erasable programmable read-only memory). Both of these tools had been developed in house.
As you’ve seen from the code available for MS-DOS 1.25 and 2.11, these versions were also written in assembly language. That code was never entirely rewritten, so there never was the opportunity to rewrite it in a higher-level language; nor was the need ever felt, I suspect — assembly was the language of choice for system tools on PCs for a long time, and system developers were as familiar with assembly as with any other language.
Some tools added in later versions were developed in C; a quick look through MS-DOS 6.22 shows that, for example, DEFRAG, FASTHELP, MEMMAKER and SCANDISK were written in C. FDISK is also a C program in 6.22; I haven’t checked its history if it started out in assembly and was rewritten (in early versions of DOS, it wasn’t provided by Microsoft but by OEMs).
answered 2 hours ago
Stephen Kitt
31.3k4126149
add a comment |Â
up vote
4
down vote
accepted
C did exist when DOS was developed, but it wasn’t used much outside the Unix world. SCP developed DOS in assembly for a few very pragmatic reasons:
The last design requirement was that MS-DOS be written in assembly language. While this characteristic does help meet the need for speed and efficiency, the reason for including it is much more basic. The only 8086 software-development tools available to Seattle Computer at that time were an assembler that ran on the Z80 under CP/M and a monitor/debugger that fit into a 2K-byte EPROM (erasable programmable read-only memory). Both of these tools had been developed in house.
As you’ve seen from the code available for MS-DOS 1.25 and 2.11, these versions were also written in assembly language. That code was never entirely rewritten, so there never was the opportunity to rewrite it in a higher-level language; nor was the need ever felt, I suspect — assembly was the language of choice for system tools on PCs for a long time, and system developers were as familiar with assembly as with any other language.
Some tools added in later versions were developed in C; a quick look through MS-DOS 6.22 shows that, for example, DEFRAG, FASTHELP, MEMMAKER and SCANDISK were written in C. FDISK is also a C program in 6.22; I haven’t checked its history if it started out in assembly and was rewritten (in early versions of DOS, it wasn’t provided by Microsoft but by OEMs).
answered 2 hours ago
Stephen Kitt
31.3k4126149
add a comment |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
C did exist when DOS was developed, but it wasn’t used much outside the Unix world. SCP developed DOS in assembly for a few very pragmatic reasons:
The last design requirement was that MS-DOS be written in assembly language. While this characteristic does help meet the need for speed and efficiency, the reason for including it is much more basic. The only 8086 software-development tools available to Seattle Computer at that time were an assembler that ran on the Z80 under CP/M and a monitor/debugger that fit into a 2K-byte EPROM (erasable programmable read-only memory). Both of these tools had been developed in house.
As you’ve seen from the code available for MS-DOS 1.25 and 2.11, these versions were also written in assembly language. That code was never entirely rewritten, so there never was the opportunity to rewrite it in a higher-level language; nor was the need ever felt, I suspect — assembly was the language of choice for system tools on PCs for a long time, and system developers were as familiar with assembly as with any other language.
Some tools added in later versions were developed in C; a quick look through MS-DOS 6.22 shows that, for example, DEFRAG, FASTHELP, MEMMAKER and SCANDISK were written in C. FDISK is also a C program in 6.22; I haven’t checked its history if it started out in assembly and was rewritten (in early versions of DOS, it wasn’t provided by Microsoft but by OEMs).
answered 2 hours ago
Stephen Kitt
31.3k4126149
C did exist when DOS was developed, but it wasn’t used much outside the Unix world. SCP developed DOS in assembly for a few very pragmatic reasons:
The last design requirement was that MS-DOS be written in assembly language. While this characteristic does help meet the need for speed and efficiency, the reason for including it is much more basic. The only 8086 software-development tools available to Seattle Computer at that time were an assembler that ran on the Z80 under CP/M and a monitor/debugger that fit into a 2K-byte EPROM (erasable programmable read-only memory). Both of these tools had been developed in house.
As you’ve seen from the code available for MS-DOS 1.25 and 2.11, these versions were also written in assembly language. That code was never entirely rewritten, so there never was the opportunity to rewrite it in a higher-level language; nor was the need ever felt, I suspect — assembly was the language of choice for system tools on PCs for a long time, and system developers were as familiar with assembly as with any other language.
Some tools added in later versions were developed in C; a quick look through MS-DOS 6.22 shows that, for example, DEFRAG, FASTHELP, MEMMAKER and SCANDISK were written in C. FDISK is also a C program in 6.22; I haven’t checked its history if it started out in assembly and was rewritten (in early versions of DOS, it wasn’t provided by Microsoft but by OEMs).
answered 2 hours ago
Stephen Kitt
31.3k4126149
answered 2 hours ago
Stephen Kitt
31.3k4126149
answered 2 hours ago
Stephen Kitt
31.3k4126149
answered 2 hours ago
Stephen Kitt
31.3k4126149
31.3k4126149
add a comment |Â
add a comment |Â
up vote
2
down vote
This isn't an answer but too long for a comment.
Yes - C has been around since 1972 but there were no MSDOS C compilers until the late 80s. To convert an entire OS from Assembler to C would be a mammoth task. Even though it might be easier to maintain, it could be a lot slower.
You can see the result of conversion when you compare Visual Studio 2008 to VS2010. This was a full blown conversion from C to C#. OK - it is easier to maintain from the Vendor's point of view but the new product is 24 times slower: on a netbook, 2008 loads in 5s, 2010 takes almost 2 minutes.
answered 4 hours ago
cup
48117
1
Assembly to C, and C to C# cannot really be compared, as C# is a JIT'd GC'd memory-safe language, whereas C is very close to Assembly in the features it provides, being just easier to write and maintain. Anyway, "entire OS" for MS-DOS is quite little code, so converting it to C, either completely or partially, wouldn't be such a large task.
– juhist
3 hours ago
OK, maybe C to C# was a bad example. It is the little specialist instructions like IN and OUT, which are used a lot in device drivers that cause no end of problems with many C compilers. I don't know what instructions are used but stuff like REPZ often has to be hand coded: there are no C equivalents.
– cup
3 hours ago
@juhist Try actually doing some of the conversion yourself, then tell us whether it was really a large task or not. (Oh, and make sure you regression test every edge and corner case, just to be sure your C version doesn't change the behaviour of anything, not just what the (buggy and incomplete) user documentation says is valid!
– alephzero
3 hours ago
add a comment |Â
up vote
2
down vote
This isn't an answer but too long for a comment.
Yes - C has been around since 1972 but there were no MSDOS C compilers until the late 80s. To convert an entire OS from Assembler to C would be a mammoth task. Even though it might be easier to maintain, it could be a lot slower.
You can see the result of conversion when you compare Visual Studio 2008 to VS2010. This was a full blown conversion from C to C#. OK - it is easier to maintain from the Vendor's point of view but the new product is 24 times slower: on a netbook, 2008 loads in 5s, 2010 takes almost 2 minutes.
answered 4 hours ago
cup
48117
1
Assembly to C, and C to C# cannot really be compared, as C# is a JIT'd GC'd memory-safe language, whereas C is very close to Assembly in the features it provides, being just easier to write and maintain. Anyway, "entire OS" for MS-DOS is quite little code, so converting it to C, either completely or partially, wouldn't be such a large task.
– juhist
3 hours ago
OK, maybe C to C# was a bad example. It is the little specialist instructions like IN and OUT, which are used a lot in device drivers that cause no end of problems with many C compilers. I don't know what instructions are used but stuff like REPZ often has to be hand coded: there are no C equivalents.
– cup
3 hours ago
@juhist Try actually doing some of the conversion yourself, then tell us whether it was really a large task or not. (Oh, and make sure you regression test every edge and corner case, just to be sure your C version doesn't change the behaviour of anything, not just what the (buggy and incomplete) user documentation says is valid!
– alephzero
3 hours ago
add a comment |Â
up vote
2
down vote
up vote
2
down vote
This isn't an answer but too long for a comment.
Yes - C has been around since 1972 but there were no MSDOS C compilers until the late 80s. To convert an entire OS from Assembler to C would be a mammoth task. Even though it might be easier to maintain, it could be a lot slower.
You can see the result of conversion when you compare Visual Studio 2008 to VS2010. This was a full blown conversion from C to C#. OK - it is easier to maintain from the Vendor's point of view but the new product is 24 times slower: on a netbook, 2008 loads in 5s, 2010 takes almost 2 minutes.
answered 4 hours ago
cup
48117
This isn't an answer but too long for a comment.
Yes - C has been around since 1972 but there were no MSDOS C compilers until the late 80s. To convert an entire OS from Assembler to C would be a mammoth task. Even though it might be easier to maintain, it could be a lot slower.
You can see the result of conversion when you compare Visual Studio 2008 to VS2010. This was a full blown conversion from C to C#. OK - it is easier to maintain from the Vendor's point of view but the new product is 24 times slower: on a netbook, 2008 loads in 5s, 2010 takes almost 2 minutes.
answered 4 hours ago
cup
48117
answered 4 hours ago
cup
48117
answered 4 hours ago
cup
48117
answered 4 hours ago
cup
48117
48117
1
Assembly to C, and C to C# cannot really be compared, as C# is a JIT'd GC'd memory-safe language, whereas C is very close to Assembly in the features it provides, being just easier to write and maintain. Anyway, "entire OS" for MS-DOS is quite little code, so converting it to C, either completely or partially, wouldn't be such a large task.
– juhist
3 hours ago
OK, maybe C to C# was a bad example. It is the little specialist instructions like IN and OUT, which are used a lot in device drivers that cause no end of problems with many C compilers. I don't know what instructions are used but stuff like REPZ often has to be hand coded: there are no C equivalents.
– cup
3 hours ago
@juhist Try actually doing some of the conversion yourself, then tell us whether it was really a large task or not. (Oh, and make sure you regression test every edge and corner case, just to be sure your C version doesn't change the behaviour of anything, not just what the (buggy and incomplete) user documentation says is valid!
– alephzero
3 hours ago
add a comment |Â
1
Assembly to C, and C to C# cannot really be compared, as C# is a JIT'd GC'd memory-safe language, whereas C is very close to Assembly in the features it provides, being just easier to write and maintain. Anyway, "entire OS" for MS-DOS is quite little code, so converting it to C, either completely or partially, wouldn't be such a large task.
– juhist
3 hours ago
OK, maybe C to C# was a bad example. It is the little specialist instructions like IN and OUT, which are used a lot in device drivers that cause no end of problems with many C compilers. I don't know what instructions are used but stuff like REPZ often has to be hand coded: there are no C equivalents.
– cup
3 hours ago
@juhist Try actually doing some of the conversion yourself, then tell us whether it was really a large task or not. (Oh, and make sure you regression test every edge and corner case, just to be sure your C version doesn't change the behaviour of anything, not just what the (buggy and incomplete) user documentation says is valid!
– alephzero
3 hours ago
1
1
Assembly to C, and C to C# cannot really be compared, as C# is a JIT'd GC'd memory-safe language, whereas C is very close to Assembly in the features it provides, being just easier to write and maintain. Anyway, "entire OS" for MS-DOS is quite little code, so converting it to C, either completely or partially, wouldn't be such a large task.
– juhist
3 hours ago
Assembly to C, and C to C# cannot really be compared, as C# is a JIT'd GC'd memory-safe language, whereas C is very close to Assembly in the features it provides, being just easier to write and maintain. Anyway, "entire OS" for MS-DOS is quite little code, so converting it to C, either completely or partially, wouldn't be such a large task.
– juhist
3 hours ago
OK, maybe C to C# was a bad example. It is the little specialist instructions like IN and OUT, which are used a lot in device drivers that cause no end of problems with many C compilers. I don't know what instructions are used but stuff like REPZ often has to be hand coded: there are no C equivalents.
– cup
3 hours ago
OK, maybe C to C# was a bad example. It is the little specialist instructions like IN and OUT, which are used a lot in device drivers that cause no end of problems with many C compilers. I don't know what instructions are used but stuff like REPZ often has to be hand coded: there are no C equivalents.
– cup
3 hours ago
@juhist Try actually doing some of the conversion yourself, then tell us whether it was really a large task or not. (Oh, and make sure you regression test every edge and corner case, just to be sure your C version doesn't change the behaviour of anything, not just what the (buggy and incomplete) user documentation says is valid!
– alephzero
3 hours ago
@juhist Try actually doing some of the conversion yourself, then tell us whether it was really a large task or not. (Oh, and make sure you regression test every edge and corner case, just to be sure your C version doesn't change the behaviour of anything, not just what the (buggy and incomplete) user documentation says is valid!
– alephzero
3 hours ago
add a comment |Â
up vote
1
down vote
Answering the question - yes.
For the rationale: there's very little gain in rewriting functioning code (unless for example you have portability specifically in mind).
The "newest version" of any major program generally contains much of the code of the previous version, so again, why spend programmer time on rewriting existing features instead of adding new features?
answered 2 hours ago
dave
111
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
Answering the question - yes.
For the rationale: there's very little gain in rewriting functioning code (unless for example you have portability specifically in mind).
The "newest version" of any major program generally contains much of the code of the previous version, so again, why spend programmer time on rewriting existing features instead of adding new features?
answered 2 hours ago
dave
111
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Answering the question - yes.
For the rationale: there's very little gain in rewriting functioning code (unless for example you have portability specifically in mind).
The "newest version" of any major program generally contains much of the code of the previous version, so again, why spend programmer time on rewriting existing features instead of adding new features?
answered 2 hours ago
dave
111
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Answering the question - yes.
For the rationale: there's very little gain in rewriting functioning code (unless for example you have portability specifically in mind).
The "newest version" of any major program generally contains much of the code of the previous version, so again, why spend programmer time on rewriting existing features instead of adding new features?
answered 2 hours ago
dave
111
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 2 hours ago
dave
111
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 2 hours ago
dave
111
answered 2 hours ago
dave
111
111
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
dave is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
up vote
1
down vote
From The OS/2 Museum page about DOS3: "The new ATTRIB.EXE utility allowed the user to manipulate file attributes (Read-only, Hidden, System, etc.). It is notable for being the first DOS utility written in C (up to that point, all components in DOS were written in assembly language) and contains the string “Zbikowski C startup Copyright 1983 (C) Microsoft Corpâ€Â, clearly identifying Mark Zbikowski’s handiwork."
I realise that this doesn't really answer the question, but gives an idea of how DOS was implemented. Also remember that the operating system had to be as small as possible so as to leave room for user programs, so the resident part of COMMAND.COM would have stayed written in Assembly.
answered 1 hour ago
No'am Newman
246125
add a comment |Â
up vote
1
down vote
From The OS/2 Museum page about DOS3: "The new ATTRIB.EXE utility allowed the user to manipulate file attributes (Read-only, Hidden, System, etc.). It is notable for being the first DOS utility written in C (up to that point, all components in DOS were written in assembly language) and contains the string “Zbikowski C startup Copyright 1983 (C) Microsoft Corpâ€Â, clearly identifying Mark Zbikowski’s handiwork."
I realise that this doesn't really answer the question, but gives an idea of how DOS was implemented. Also remember that the operating system had to be as small as possible so as to leave room for user programs, so the resident part of COMMAND.COM would have stayed written in Assembly.
answered 1 hour ago
No'am Newman
246125
add a comment |Â
up vote
1
down vote
up vote
1
down vote
From The OS/2 Museum page about DOS3: "The new ATTRIB.EXE utility allowed the user to manipulate file attributes (Read-only, Hidden, System, etc.). It is notable for being the first DOS utility written in C (up to that point, all components in DOS were written in assembly language) and contains the string “Zbikowski C startup Copyright 1983 (C) Microsoft Corpâ€Â, clearly identifying Mark Zbikowski’s handiwork."
I realise that this doesn't really answer the question, but gives an idea of how DOS was implemented. Also remember that the operating system had to be as small as possible so as to leave room for user programs, so the resident part of COMMAND.COM would have stayed written in Assembly.
answered 1 hour ago
No'am Newman
246125
From The OS/2 Museum page about DOS3: "The new ATTRIB.EXE utility allowed the user to manipulate file attributes (Read-only, Hidden, System, etc.). It is notable for being the first DOS utility written in C (up to that point, all components in DOS were written in assembly language) and contains the string “Zbikowski C startup Copyright 1983 (C) Microsoft Corpâ€Â, clearly identifying Mark Zbikowski’s handiwork."
I realise that this doesn't really answer the question, but gives an idea of how DOS was implemented. Also remember that the operating system had to be as small as possible so as to leave room for user programs, so the resident part of COMMAND.COM would have stayed written in Assembly.
answered 1 hour ago
No'am Newman
246125
answered 1 hour ago
No'am Newman
246125
answered 1 hour ago
No'am Newman
246125
answered 1 hour ago
No'am Newman
246125
246125
add a comment |Â
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%2f7880%2fwere-later-ms-dos-versions-still-implemented-in-x86-assembly%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
The MS_DOS ABI (if we can call it that) is an assembly register interface. It would be quite inconvenient to implement that in C.
– tofro
1 hour ago