42.9 GB Of Microsoft Source Code Leaked: Historicans Can Now Study The Source Code For MS-Dos 3.3 To Windows XP

From LinuxReviews
Jump to navigationJump to search

The mother-lode of Microsoft source code hit the web today. A 42.9 GiB torrent with MS-DOS 3.3, MS-DOS 6, Windows NT 3.5 & 5, Windows CE 6 & 7, Windows 2000, Windows Server 2003 and Windows XP, and some XBox code, can now be acquired from your local friendly BitTorrent site.

written by 林慧 (Wai Lin) 2020-09-26 - last edited 2020-09-28. © CC BY

Microsoft source code leak 2020-09-24.jpg
The Deepin desktop environment showing folders and files with leaked Microsoft source code.

Today's mother-lode of all source code leaks does not appear to be officially endorsed by Microsoft even though all the code is all old enough to be released into the public domain with zero impact on Microsoft's bottom line. The massive 42.9 GiB torrent leak contains compressed source code for most of the operating systems released by Microsoft between 1987 and 2001.

Those who want to study ancient Microsoft code for historical research purposes can now have a look at:

  • MS-DOS 3.3 & 6.0
  • Windows NT 3.5 & 4
  • Windows CE 6 & 7
  • Some old XBox source code
  • Windows 2000
  • Windows Server 2003
  • Windows XP

There's also some media files and things like that in the "Microsoft leaked source code archive_2020-09-24" folder.

It is important to understand that this leak does not make any Microsoft code free software. All the leaked files remain immoral proprietary software, unusable to anyone with a semblance of a moral compass, even though the source is out there. Microsoft has not granted anyone the right to use this source code for any purpose, so free software projects that could have benefited from this source to some degree, like Wine and ReactOS, can't use it. Those who are working on re-implementing Windows APIs shouldn't even look at it.

Directx code.jpg
Some ancient DirectX code from Windows Server 2003.

Perhaps Microsoft will decide that Windows XP is so old that they might as well release it under some free software license now that its source code is readily available all over the Internet. It's not like they would lose a single sale if they do, none of the operating systems in the leak have any kind of official support. Not that it really matters, the Linux kernel is decades ahead of anything Microsoft has, old or new, so the leaked source code is mostly interesting for those who want to do historical research.

We'll leave you with a few very touching stories:

File: /XPSP1/net/upnp/upnp/api/iconutil.cpp
* ulMyAbs (stolen from "MyAbs")
* Calcules my weighted absolute value of the difference between 2 nums.
* This of course normalizes values to >= zero.  But it also doubles them
* if valueHave < valueWant.  This is because you get worse results trying
* to extrapolate from uless info up then interpolating from more info down.
* I paid $150 to take the SAT.  I'm damned well going to get my vocab's
* money worth.
File: /XPSP1/enduser/stuff/hhctrl/hhctrl.cpp
            Workaround for bug #5851
            Once upon a time there was a bug in that window types were not CHM specific.
            HTML Help shipped with this bug. Many people depended on the bug. In 1.1b we
            fixed the bug and broke exisiting content. Bug 5851 is such a case. Before, the fix
            below, the code was working EXACTLY as it should. However, we can't break those who
            have shipped no matter how broken the previous version. So, here we actually add in
            a bug to upbreak the already broken.

            The fix is as follows. If you are jumping to an url and you provide a window type,
            we check to see if there is a collection open which contains that url. If there is,
            we check to see if that window type is defined by the master chm in the collection
            and if it is open. If both of these are true, then we just navigate and don't create
            a new window.

            The result is that included CHMs cannot define windows with the same name as the MASTER CHM.

        // Is this file part of a collection?
        CExCollection* pCollection = GetCurrentCollection(NULL, pszUrl);
        if (pCollection)
File: /Win2K3/sdktools/masm/asmconf.h
**      XENIX     - Once upon a time long, long ago was used to build for
**                  XENIX. I garentee this code is broken.
**      XENIX286  - Dito.
**      MSDOS     - Generates a hodge-podge of usefull code.
**                  This is automatically defined for OS2_NT and OS2_2.
File: /XPSP1/sdktools/debuggers/imagehlp/binplace.c
__inline BOOL
                  IN  LPSTR Directory,
                  IN  LPSTR FileToFind,
                  IN  LPSTR SourceFullName,
                  IN  LPSTR SourceFilePart,
                  OUT PBOOL FoundInTree
    // This was way too slow. Just say we didn't find the file.
    *FoundInTree = FALSE;
File: /dos-6.0/45/beef/cw/kernel/int24.asm
        dec     fSingleFloppy

; On a single floppy system, the byte at 0040:0104 is 00 if the floppy is
; currently acting as A:, and 01 if the floppy is currently acting as B:.
; This is using a totally undocumented DOS data location; it's the sleaziest
; CW operation that I know of.  For safety's sake (ha!), we check the 
; obscure case of 1, and assume B: is the phantom for !1.
; If this breaks in a future version of DOS, I would suggest adding a DOS
; check, and not just punting this stuff altogether.

        xor     ax,ax
        mov     es,ax
    assumes es,NOTHING

        mov     bl,1                    ; Guess it's currently acting as B:,
        mov     ax,":a"                 ;   so that A: is the phantom drive.
        cmp     es:[0504h],bl
        jz      @F
        inc     ax                      ; Guessed wrong: B: is the phantom
        inc     bx                      ;   drive.
   	mov     chDrivePhantom,ax	; "a:" if A is phantom, "b:" if B is.
        mov     drivePhantom,bl         ;   1  if A is phantom,   2  if B is.

; We should do something to reselect to avoid phantom drives (???)

File: /Win2K3/com/ole32/olethunk/ole16/makefile.inc
# Replace .\ with $(OBJDIR)
# Unfortunately we can't do this directly so we have to explicitly check
# the value of OBJDIR
# JohnDoty:
# The build will break with $(O) has a new range of supported types.
# This sucks.  However, I don't think I can do this correctly.
!if "$(OBJDIR)" == "obj\i386"
OBJFILES = $(OBJFILES:.\=obj\i386\)
RESFILES = $(RESFILES:.\=obj\i386\)

!error Unknown OBJDIR: $(OBJDIR)
File: /XPSP1/ds/ds/src/ntdsa/dblayer/dbfilter.c
        // Once upon  time, we turned all filters of (objectClass=FOO) into
        // (objectCategory = BAR).  For a variety of reasons (i.e. incorrect
        // search results, weird results when you have different READ privileges
        // on objectClass and objectCategory, cases where exact objectClass is
        // necessary, so is done on the client, and deleted objects where
        // objectCategory is removed)  we are no longer doing this.  The code
        // that did this was right here.

        if (!(pAC = SCGetAttById(pTHS, 
                                 pFil->FilterTypes.Item.FilTypes.ava.type))) {
File: /Win2K3/shell/comctl32/v6/prshti.h
//  The history of PROPSHEETHEADER
//      This is the property sheet header that shipped in an early
//      Win95 beta (sometime between Sep 1993 and Sep 1994, maybe M5).
//      It is just like the shipping Win95 property sheet header,
//      except that it lacks the PFNPROPSHEETCALLBACK at the end.
//      We grudgingly accept it but don't publicize the fact.
//      For some reason, we have always supported this wacky
//      ancient unreleased PROPSHEETHEADER, so there's no point
//      in dropping support for it now...  If you think it's not
//      worth retaining support for this ancient structure,
//      feel free to nuke it.  But you become responsible for the
//      potential app compat bugs from Norton Utilities for
//      Windows 95 v1.0.
File: /XPSP1/inetsrv/iis/svcs/ftp/server/userdb.cxx
    if( dwError != NO_ERROR &&
        dwError != ERROR_SEM_TIMEOUT )

     	// Geezsh, I hate my life.
        // Once upon a time, there was a bug in ATQ that cause it to
        // always pass NO_ERROR as the status to the async completion
        // routine. This bug caused, among other things, FTP to never
        // time out idle connections, because it never saw the
        // ERROR_SEM_TIMEOUT status. So, I fixed the bug in ATQ.
        // Now, this completion routine gets the actual status. Well,
        // that breaks service shutdown when there are connected users.
        // Basically, when a shutdown occurs, the connected sockets are
        // closed, causing the IO to complete with ERROR_NETNAME_DELETED.
        // USER_DATA::ProcessAsyncIoCompletion() is not handling this
        // error properly, which causes 1) an assertion failure because
        // USER_DATA::DisconnectUserWithError() is getting called *twice*
        // and 2) the service never stops because of a dangling reference
        // on the USER_DATA structure.
        // Of course, the proper thing to do would be to fix the offending
        // code in USER_DATA::ProcessAsyncIoCompletion() so that it DID
        // handle the error properly. Unfortunately, that fix requires a
        // nontrivial amount of surgery, and we're a scant three days
        // from releasing K2 Beta 1. So...
        // As a quick & dirty work around for K2 Beta 1, we'll map all
        // errors other than ERROR_SEM_TIMEOUT to NO_ERROR. This should
        // provide the lower software layers with the old ATQ behavior
        // they're expecting.
        // 3/12/98
        // N.B. The debug output below has been changed to be a little
        // more customer friendly but I hate to prevent future developers
        // for enjoying the original message which read:
        // "Mapping error %d to NO_ERROR to mask FTP bug (FIX!)\n"
        // I'm removing this message because it was the source of some
        // embarrasment, when a checked version of this DLL was sent to
        // Ernst & Young to track the now famous bug #138566.

..and one question worth pondering: Did Richard Stallman and the Free Software Foundation give Microsoft permission to use GNU General Public Licensed code in Windows XP and Windows Server 2003?

File: /Win2K3/inetsrv/query/sqltext/bison.cpp
/* Skeleton output parser for bison,
   Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */

/* As a special exception, when this file is copied by Bison into a
   Bison output file, you may use that output file without restriction.
   This special exception was added by the Free Software Foundation
   in version 1.24 of Bison.  */

#pragma hdrstop
#include <malloc.h>

/* This is the parser code that is written into each bison parser
  when the %semantic_parser declaration is not specified in the grammar.
  It was written by Richard Stallman by simplifying the hairy parser
  used when %semantic_parser is specified.  */

/* Note: there must be only one dollar sign in this file.
   It is replaced by the list of actions, each action
   as one case of the switch.  */

Microsoft has not given anyone permission to download these possibly stolen source code files. It may therefore be illegal to acquire them using this magnetic link: magnet:?xt=urn:btih:3d8b16242b56a3aafb8da7b5fc83ef993ebcf35b

We do understand if you would want a copy. For historical research purposes only, of course.

(10 votes)



15 months ago
Score 0++

> Perhaps Microsoft will decide that Windows XP is so old that they might as well release it under some free software license now that

That's a silly request. It would be irresponsible to release such obsolete software with known security vulnerabilities if they aren't going to maintain it.

Anonymous (536a35b224)

25 days ago
Score 0
That makes absolutely no sense, they obviously wouldn't be releasing it with the intention people use it so the vulnerabilities would not matter


14 months ago
Score 0++
The password to unrar the windows XP is internaldev


14 months ago
Score 0++
The Windows XP password is internaldev

Anonymous (f1f6024df9)

6 months ago
Score 0
Thank you so much Dsousa :)

Anonymous (cd5f9cb2b6)

4 months ago
Score 0
thanks Dsousa!
Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.