MS-DOS code leak on google
MS-DOS code leak on google
some guy discovered full MS-DOS 6.0 code on code.google.com
see here http://digg.com/security/MS_DOS_6_0_app ... ode_Search
read the comments(at the website) they show some pretty funny comments(in code) that ms-dos developers put down(many with lots of cursing and user insulting)
see here http://digg.com/security/MS_DOS_6_0_app ... ode_Search
read the comments(at the website) they show some pretty funny comments(in code) that ms-dos developers put down(many with lots of cursing and user insulting)
I don't know if those are added there afterwards or something.
One thing is that if somebody has the need to curse that much while doing, I wonder whether he is capable to write proper code. Definitely, not the master in programming.
One thing is that if somebody has the need to curse that much while doing, I wonder whether he is capable to write proper code. Definitely, not the master in programming.
Windows Vista rapes you, cuts you and pisses inside. Thought these are just nifty side-effects.
- Schol-R-LEA
- Member
- Posts: 1925
- Joined: Fri Oct 27, 2006 9:42 am
- Location: Athens, GA, USA
Oh, how droll. I can assure you, this isn't the actual MS-DOS source, if for only one reason, something that has long been known to industry insiders which MS would prefer people forgot: until 1994, Microsoft did all of their development on Xenix (which they had actually licensed and developed before buying QDOS; they initially offered that to IBM, in fact, but were told that the idea of licensing UNIX from Bell had already been considered and discarded - IBM saw PCs primarily as an enhanced terminal, and also didn't trust AT&T's stability due to the ongoing court-ordered breakup). They certainly would not have used batch files for builds! There were dozens of programmers working on MS-DOS at that time; batch builds and no version control would have been absurdly inadequate even by the standards of the time. Also, every version of MS-DOS was written entirely in assembly language, not a mix of C and assembly.
There are other things as well; for example, the boot sector code is only for a floppy disk, and couldn't be used for a hard disk; it also contains an anachronistic reference to 32-bit sector sizes in the comments, something which would not be introduced until the release of NTFS in 1994, and later still, FAT32 (niether of which were ever supported by any version of DOS). Similarly, the POWER.EXE APM driver could not have been developed in 1991, as stated in the comments, because the APM standard wasn't introduced until 1992, with the standard itself taking until 1993 to complete (the first version of POWER.EXE wasn't released until 1995).
Finally, by the time of MS-DOS 6.0, Microsoft had long since adopted Hungarian notation across the board, and one would expect it to show in at least some of the labels and variable names. Hell, assembly programming is one of the places even I agree that HN can (potentially) be useful, which is saying quite a bit considering how little I generally think of HN.
As for the charming terminology used in some of the comments , I can't see that sort of thing occurring in MS code any later than 1979; by the mid-1980s Gates had already gone into full-blown Control Freak mode, and under Simonyi's re-organization the MS development system became rigidly hierarchical. There's no way that sort of thing would have passed a code review - it would be a lot less likely to get missed that bugs would be.
This looks to be nothing more than an elaborate practical joke; I'm guessing this was the code for an MS-DOS clone along the lines of FreeDOS, which someone then altered the comments and file names on.
There are other things as well; for example, the boot sector code is only for a floppy disk, and couldn't be used for a hard disk; it also contains an anachronistic reference to 32-bit sector sizes in the comments, something which would not be introduced until the release of NTFS in 1994, and later still, FAT32 (niether of which were ever supported by any version of DOS). Similarly, the POWER.EXE APM driver could not have been developed in 1991, as stated in the comments, because the APM standard wasn't introduced until 1992, with the standard itself taking until 1993 to complete (the first version of POWER.EXE wasn't released until 1995).
Finally, by the time of MS-DOS 6.0, Microsoft had long since adopted Hungarian notation across the board, and one would expect it to show in at least some of the labels and variable names. Hell, assembly programming is one of the places even I agree that HN can (potentially) be useful, which is saying quite a bit considering how little I generally think of HN.
As for the charming terminology used in some of the comments , I can't see that sort of thing occurring in MS code any later than 1979; by the mid-1980s Gates had already gone into full-blown Control Freak mode, and under Simonyi's re-organization the MS development system became rigidly hierarchical. There's no way that sort of thing would have passed a code review - it would be a lot less likely to get missed that bugs would be.
This looks to be nothing more than an elaborate practical joke; I'm guessing this was the code for an MS-DOS clone along the lines of FreeDOS, which someone then altered the comments and file names on.
Your ignorance astounds me. Are you suggesting that someone would decompile 2/3 of FreeDOS, throw in some random real source from said OS, and then take quite some time to reorganize and comment the code to make it appear to have several authors over the course of many years? Is there any reason to spend all that time and effort doing an "elaborate practical joke"? No, that simple bit of logic explains that this is the real deal.Schol-R-LEA wrote:Oh, how droll. I can assure you, this isn't the actual MS-DOS source, if for only one reason, something that has long been known to industry insiders which MS would prefer people forgot: until 1994, Microsoft did all of their development on Xenix (which they had actually licensed and developed before buying QDOS; they initially offered that to IBM, in fact, but were told that the idea of licensing UNIX from Bell had already been considered and discarded - IBM saw PCs primarily as an enhanced terminal, and also didn't trust AT&T's stability due to the ongoing court-ordered breakup). They certainly would not have used batch files for builds! There were dozens of programmers working on MS-DOS at that time; batch builds and no version control would have been absurdly inadequate even by the standards of the time. Also, every version of MS-DOS was written entirely in assembly language, not a mix of C and assembly.
There are other things as well; for example, the boot sector code is only for a floppy disk, and couldn't be used for a hard disk; it also contains an anachronistic reference to 32-bit sector sizes in the comments, something which would not be introduced until the release of NTFS in 1994, and later still, FAT32 (niether of which were ever supported by any version of DOS). Similarly, the POWER.EXE APM driver could not have been developed in 1991, as stated in the comments, because the APM standard wasn't introduced until 1992, with the standard itself taking until 1993 to complete (the first version of POWER.EXE wasn't released until 1995).
Finally, by the time of MS-DOS 6.0, Microsoft had long since adopted Hungarian notation across the board, and one would expect it to show in at least some of the labels and variable names. Hell, assembly programming is one of the places even I agree that HN can (potentially) be useful, which is saying quite a bit considering how little I generally think of HN.
As for the charming terminology used in some of the comments , I can't see that sort of thing occurring in MS code any later than 1979; by the mid-1980s Gates had already gone into full-blown Control Freak mode, and under Simonyi's re-organization the MS development system became rigidly hierarchical. There's no way that sort of thing would have passed a code review - it would be a lot less likely to get missed that bugs would be.
This looks to be nothing more than an elaborate practical joke; I'm guessing this was the code for an MS-DOS clone along the lines of FreeDOS, which someone then altered the comments and file names on.
Code: Select all
IF IBMCOPYRIGHT
Bio DB "IBMBIO COM"
Dos DB "IBMDOS COM"
ELSE
Bio DB "IO SYS"
Dos DB "MSDOS SYS"
ENDIF
- Schol-R-LEA
- Member
- Posts: 1925
- Joined: Fri Oct 27, 2006 9:42 am
- Location: Athens, GA, USA
It never pays to underestimate the lengths a person will go for a pratical joke, Niteice. Trust me only this fnord.
I wouldn't claim that it was specifically a de-compiled version of freeDOS; there have been any number of MS-DOS workalikes developed over the years, free and proprietary, and the code could come from one or more of those. Nor would it be necessary to change all of the commenst and identifiers, just those which would identify the code as being from something other than MS-DOS. I'll admit that it is possible - likely even - that some of the code really is from Microsoft, though not necessarily from MS-DOS. I'm simply arguing that at least part of it isn't what it is claimed to be.
I'll admit that I may be wrong in this, but I don't think so. Perhaps it's just my suspicious nature, but I'd definitely say that the anomalies in the code and documentation give me reason to question the authenticity. For example, this C file, clone.c. This isn't MS-DOS code; as far as I can determine, MS-DOS was written entirely in assembly throughout it's lifespan, which I said before. In fact, it probably isn't Microsoft C code at all - the <conio.h> library is a Borland extension library for accessing the DOS console, and while MS later added a version of it to Visual C++ (one which was incompatible with the Borland version), it is rather unlikely that MS ever used it internally. The various calling-convention warts (e.g., 'far pascal', 'cdecl') are specific to Windows, and while it does refer to the DOS console as well, it is clear that the DOS code is for connecting to a different system remotely. 'FastLynx' is the name of a file transfer program similar to LapLink; while it is possible that Microsoft had an internal program of the same name, the rest of the code does indeed seem to be related to file transfer. Thus, it is safe to say that at least some of the code isn't part of any version of MS-DOS.
[EDIT: Apparently, there was an earlier file transfer program by the same name, from a Rupp Technology, which MS licensed for MS-DOS 5 and later. Thus, I will partly retract this section, as there is indeed a connection between MS-DOS and at least one product called FastLynx.]
Or take the following header file. There are a number of entries which make no sense in the context of DOS, but which, by remarkable coincidence, match the library header files from later versions of OS/2, from after the period when MS was involved with the project; compare them to this header used in osFree, an open-source Warp workalike. While it is possible that it was copied from 0S/2, it almost certainly was not copied from MS-DOS, as it refers to features not supported by DOS. For example, the defines for drive joining (something MS-DOS does not support):
Here we have defines for a DOS mode - support for emulating DOS, which obviously DOS itself would not need to do. I suppose that it could be for Windows, but it is surely out of place in code that is supposed to be for MS-DOS:
Swap file defines:
These are significant because at the time of the MS-IBM split, OS/2 was targetting 80286 protected mode, and 286 p-mode does not have any significant support for virtual memory. While it is possible to use swap without virtual memory management, it is both slower and less stable, and to the best of my knowledge OS/2 didn't use swapping until Warp, which was released after Windows 95. Thus, not only can't it be a DOS header - DOS never has any form of swapping or VM, of course - but also cannot be Windows headers from that period, either.
While this is hardly concrete evidence, I'd say that it is enough to raise a reasonable doubt as to the origin of at least part of the code.
I will add that I'm fairly certain that at least some of the code comes from an OS dev project that I recall studying the source from when it was linked to on alt.os.development years ago; however, it is possible that I'm mistaken in this, and I won't be certain until I can go through my old OS code examples to try and find it. On second thought, I won't bother; I've wasted enough time on this as it is.
I wouldn't claim that it was specifically a de-compiled version of freeDOS; there have been any number of MS-DOS workalikes developed over the years, free and proprietary, and the code could come from one or more of those. Nor would it be necessary to change all of the commenst and identifiers, just those which would identify the code as being from something other than MS-DOS. I'll admit that it is possible - likely even - that some of the code really is from Microsoft, though not necessarily from MS-DOS. I'm simply arguing that at least part of it isn't what it is claimed to be.
I'll admit that I may be wrong in this, but I don't think so. Perhaps it's just my suspicious nature, but I'd definitely say that the anomalies in the code and documentation give me reason to question the authenticity. For example, this C file, clone.c. This isn't MS-DOS code; as far as I can determine, MS-DOS was written entirely in assembly throughout it's lifespan, which I said before. In fact, it probably isn't Microsoft C code at all - the <conio.h> library is a Borland extension library for accessing the DOS console, and while MS later added a version of it to Visual C++ (one which was incompatible with the Borland version), it is rather unlikely that MS ever used it internally. The various calling-convention warts (e.g., 'far pascal', 'cdecl') are specific to Windows, and while it does refer to the DOS console as well, it is clear that the DOS code is for connecting to a different system remotely. 'FastLynx' is the name of a file transfer program similar to LapLink; while it is possible that Microsoft had an internal program of the same name, the rest of the code does indeed seem to be related to file transfer. Thus, it is safe to say that at least some of the code isn't part of any version of MS-DOS.
[EDIT: Apparently, there was an earlier file transfer program by the same name, from a Rupp Technology, which MS licensed for MS-DOS 5 and later. Thus, I will partly retract this section, as there is indeed a connection between MS-DOS and at least one product called FastLynx.]
Or take the following header file. There are a number of entries which make no sense in the context of DOS, but which, by remarkable coincidence, match the library header files from later versions of OS/2, from after the period when MS was involved with the project; compare them to this header used in osFree, an open-source Warp workalike. While it is possible that it was copied from 0S/2, it almost certainly was not copied from MS-DOS, as it refers to features not supported by DOS. For example, the defines for drive joining (something MS-DOS does not support):
Code: Select all
#define MSG_JOIN_ON_DRIV_IS_TAR 133 /* directory on drive is target of a jo */
#define MSG_JOIN_DRIVE_IS 134 /* drive is joined */
#define MSG_SUB_DRIVE_IS 135 /* drive is substed */
#define MSG_DRIVE_IS_NOT_JOINED 136 /* drive is not joined */
#define MSG_DRIVE_NOT_SUBSTED 137 /* drive is not substituted - subst */
#define MSG_JOIN_CANNOT_JOIN_DRIVE 138 /* cannot join to a joined drive */
#define MSG_SUB_CANNOT_SUBST_DRIVE 139 /* cannot sub to sub drive */
Code: Select all
#define MSG_SYSINIT_DOS_FAIL 1200 /* Cannot create DOS mode */
/* 1201 - 1204 not used */
#define MSG_SYSINIT_DOS_MODIFIED 1205 /* DOS mode memory modified by DD */
Code: Select all
#define MSG_SWAP_INVALID_DRIVE 1470 /* Invalid drive %1 specified SWAPPATH */
#define MSG_SWAP_INVALID_PATH 1471 /* Invalid path %1 specified in SWAPPATH */
#define MSG_SWAP_CANNOT_CREATE 1472 /* Cannot create swap file %1 */
#define MSG_SWAP_DISABLED 1473 /* Segment swapping is disabled */
#define MSG_SWAP_CANT_INIT 1474 /* Cannot initialize swapper */
While this is hardly concrete evidence, I'd say that it is enough to raise a reasonable doubt as to the origin of at least part of the code.
I will add that I'm fairly certain that at least some of the code comes from an OS dev project that I recall studying the source from when it was linked to on alt.os.development years ago; however, it is possible that I'm mistaken in this, and I won't be certain until I can go through my old OS code examples to try and find it. On second thought, I won't bother; I've wasted enough time on this as it is.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Apparently It's MS-DOS 5 not MS-DOS 6.
The dates just don't add up, A lot of utilities like MSD/dosshell and interlnk are included in the source and don't have free alternatives so I'm guessing it's unlikely to be fake.
But none of us should be looking at this anyway....
(Besides, Historic UNIX source is far prettier to look at )
The dates just don't add up, A lot of utilities like MSD/dosshell and interlnk are included in the source and don't have free alternatives so I'm guessing it's unlikely to be fake.
But none of us should be looking at this anyway....
(Besides, Historic UNIX source is far prettier to look at )
I don't think this is the real full M$ DOS code, for a couple of reasons, one microsoft always likes to put prefixes to there variables(which could mean that they didn't write it at all).
I just did a comparison between the boot/msboot,asm
and a disassembled version
http://www.ata-atapi.com/hiwdos.htm
and they were pretty much identical
I just did a comparison between the boot/msboot,asm
and a disassembled version
http://www.ata-atapi.com/hiwdos.htm
and they were pretty much identical
Microsoft: "let everyone run after us. We'll just INNOV~1"