[OFFER] Chicago build 89e

[Overdoze]

From warez, dated 17th March 1994. Original SUWIN.EXE would crash even with the correct betasite ID and password (same as 81/90c), so I replaced it with the provided cracked copy that works. Original has been renamed to SUWIN.OLD.

Looks like there's some minor differences compared to 90c, haven't really investigated it beyond first install yet. This is now the earliest leaked build to feature the new Microsoft Paint instead of the old Paintbrush. Download here.




EDIT: The original SUWIN.EXE has been confirmed to crash even on real hardware, so this doesn't seem like an emulator problem.

[Lucas Brooks]

WOW! Thanks for the leak! Here is the rebuilt ISO with correct timestamps and directory structure (and the original SUWIN.EXE): https://mega.nz/file/lFlzHRrY#T02ExV3p_ ... ww2MMj3MHU

[German]

Does this build have links to "Windows 94"?

It seems to me that this build was at one time a public (recompilation of" e ").

[nerd70]

Lemme point out that having the original SUWIN.EXE makes this build uninstallable...

[Lucas Brooks]

Does this build have links to "Windows 94"?

It seems to me that this build was at one time a public (recompilation of" e ").

Nope... Too bad.

Edit: This build is the first leaked one to have the boot screen stored in WINBOOT.SYS, the first build with MS-DOS 7.00 reference and the first build to support creation of an EBD. It is a pretty interesting build but not as interesting as 90c in my opinion.

[Overdoze]

WOW! Thanks for the leak! Here is the rebuilt ISO with correct timestamps and directory structure (and the original SUWIN.EXE): https://mega.nz/file/lFlzHRrY#T02ExV3p_ ... ww2MMj3MHU

Anything in particular that's wrong with timestamps in this case too?

[PlyrStar93]

Anything in particular that's wrong with timestamps in this case too?

The folders it seems... 2nd archive is the "rebuilt" one


Upon second check, suwin.exe timestamp is different between the two archive. The other files are several hours off but it appears they are on a different timezone.

[Lucas Brooks]

WOW! Thanks for the leak! Here is the rebuilt ISO with correct timestamps and directory structure (and the original SUWIN.EXE): https://mega.nz/file/lFlzHRrY#T02ExV3p_ ... ww2MMj3MHU

Anything in particular that's wrong with timestamps in this case too?

You agree Chicago build 73f is original, right? By comparing identical files, you'll see that all of them are a few hours off. That was caused by zipping as ZIP files in the 90s always use local timestamps. All I have done is adding/subtracting offsets until timestamps of identical files match.

Don't worry, I am not here trying to claim all the credits - in fact, I don't mind everything I upload gets credited to other people. I do what I see is right and surely an ISO created by ImgBurn does not sound right.

[Overdoze]

You agree Chicago build 73f is original, right? By comparing identical files, you'll see that all of them are a few hours off. That was caused by zipping as ZIP files in the 90s always use local timestamps. All I have done is adding/subtracting offsets until timestamps of identical files match.

So if I understand you correctly, you think that all these early builds must have had the exact same modified time, just different date? What lead you to that conclusion? And this was actually packed with ARJ, not ZIP.

Your theory falls apart as soon as you compare 58s and 73f, both original dumps. Identical files have different timestamps there, because timestamps don't change only when the file is last written too. They can change for other reasons too that you're not considering here. So it's just more guess work that doesn't serve any practical purpose.

[Lucas Brooks]

So if I understand you correctly, you think that all these early builds must have had the exact same modified time, just different date? What lead you to that conclusion? And this was actually packed with ARJ, not ZIP.

When did I say different date? 89e is 11 hours ahead... Zipping is not the only way timestamps can change... FAT uses local time as well and FAT is one of the most commonly used file-system in 1994. ARJ also uses local time if I recall correctly. BTW, why not provide the original ARJ archives?

Your theory falls apart as soon as you compare 58s and 73f, both original dumps. Identical files have different timestamps there, because timestamps don't change only when the file is last written too. They can change for other reasons too that you're not considering here. So it's just more guess work that doesn't serve any practical purpose.

Seriously, compare identical files from 58s and 73f, there are identical files with same timestamp. Lets use SYSLOGO.RLE as an example, it is the same in 58s and 73f and compare it to 89e, it is exactly 11 hours off. Since the file itself and the timestamp is identical in both original dumps, and it is 11 hours ahead (no other differences) in build 89e, it is safe to conclude that happened because of file operation. If one file is 11 hours ahead, all files should be 11 hours ahead and there are multiple identical files (to 73f) exactly 11 hours ahead to consolidate the claim.



BTW, here is something interesting, maybe related to ester-eggs:

Code: Select all

531	Sidewalks are for walking, not parking
532	Tip of the day:  There is NOOOO tip if the day
533	I didn't ask for violence.... -- (Steven Segal)
534	It's almost Beta 1 ... do you know where 32-bit bunny is?
535	RonG has left the building
536	Mrs. Silverbug, this button is for you
537	'80 hours a week, and all I got was this headband...' -Brad's report
538	>>> Censored quote <<<
539	Friends don't let friends run LOR
540	DennisAd, turn your sound card down!

[Overdoze]

it is safe to conclude

When something is only "safe to conclude" but not really 100% certain and at the same time has no practical effect, does it really matter so much that you must always come up with a "fixed" ISO? All this does is create multiple copies of the same thing that function exactly the same, and neither is original, so it's completely arbitrary which is used in the end. The only real effect that can come out of this is cause confusion. And once an original dump is provided, both previous copies become garbage that then continues to circulate around the internet for eternity.

Restoring the original SUWIN.EXE? Yeah, fair change, I wasn't expecting my ISO to be FTP-acceptable due to cracked SUWIN anyway. Creating the ISO with CDIMAGE instead of whichever other tool? OK, but doesn't practically matter in vast majority of cases if it works all the same. Renaming the main folder to RETAIL? Virtually useless, but OK. Changing time stamps? Come on. Now we're reaching level ridiculous of pedantry.

[Kimberly5384]

Honestly, I agree with that. A lot of people used to ask me on discord for original copies since I believe they got replaced with all these fixed iso files.

[Lucas Brooks]

it is safe to conclude

When something is only "safe to conclude" but not really 100% certain and at the same time has no practical effect, does it really matter so much that you must always come up with a "fixed" ISO?

Of course nobody can be 100% certain but it is more likely original because we have something supporting it. I know it serves no purpose to the end user but it is still something worth preserving.

Restoring the original SUWIN.EXE? Yeah, fair change, I wasn't expecting my ISO to be FTP-acceptable due to the cracked one anyway. Renaming the main folder to RETAIL? Virtually useless, but OK. Changing time stamps? Come on.

By comparing the "cracked" SUWIN.EXE to 90c's SUWIN.EXE, the "cracked" one looks more original than the "original" one... All pre-1xx Chicago builds are stored in the RETAIL directory on the CD-ROM so why is it useless? I am 99.99% sure the original 89e was in a folder named RETAIL. I see nothing wrong with correcting timestamps... especially there is a good chance of restoring them to their original state.

[andrian1994]

Hmm interesting, thank you for the leak

Sent from my Redmi 6 using Tapatalk

[Zheng He]

The "cracked" SUWIN.EXE might actually be original, while the "original" one is corrupted.

Compared to the "original" one, only offset 0x6FDC-0x6FFF is different. Decompiled in IDA Pro, I immediately noticed that the "original" one has meaningless ASM codes that cause "General Protection Fault" during installation.

You don't want to access FFFF:0000 under virtual 8086 mode right? Plus, that "call far ptr 2677h:37F8h" looks meaningless, too. The file size is far too small given the reference of code segment 2677h. I don't think Microsoft would, or the compiler/linker would, do things like this!

Therefore, I switched back to Hex view and found something wrong with the "original" one:

At the end of the different area, the "original" one showed that "9A F8 37 77 26" is an instruction, while the "cracked" one indicated that "66 83 7E F8 37" is an instruction. This is the origination of the "call far ptr 2677h:37F8h" error. Since the different area ends with "66 83 7E" (or "16 50 9A" in the "original" one), I don't think the "cracked" one actually contains a crack code here.

Here I made an assumption, that is, the "cracked" one does not contain any crack code. In general, if you want to crack some program like this, you would either return a "valid" value immediately, or insert some JMP instruction to execute crack code elsewhere. The "cracked" one didn't show any sign of this. In order to verify my assumption, I installed the build with "cracked" SUWIN.EXE and invalid Beta ID.

It turned out as expected that the system gave me an error complaining the Beta ID or password is incorrect. At this point it's sure that the "cracked" SUWIN.EXE does not contain any crack code.

Let's see some external evidence.

Code: Select all

CHIC-FIX.ZIP     96392  05-22-94  Replacement for Chicago April Beta.  
                                  If you experience GPF when trying
                                  to install (and you probably will)
                                  replace suwin.exe with this one.

This is the information from the SUWIN.EXE fix originally on scenelist. There is no any indication that this is a "crack". It's just a "fix". ("GPF" stands for "General Protection Fault")

So back to the "original" file itself. The different area seems to contain a repeated pattern: "8D 86 F6 FE 16 50". This hex-string repeated 3 times in the different area!

Given the repeated pattern and distortion in this area, I think the "original" file is actually corrupted, while the "cracked" file is in fact original. This error seemed to occur during the process of data transfer, like from CD drive to hard drive, or from a computer to another via Internet (unlikely, since no one wants to transfer big uncompressed files via Internet). It's unclear what caused the corruption, but it's certain that this area was fed with fake data.

In conclusion, the "original" SUWIN.EXE is corrupted, while the "cracked" one is actually not cracked but original. Therefore, it's safe to just replace the old SUWIN.EXE with the new one.

As for repacking the image to make it more "original", I don't think it's a good idea. As long as it's not original, any modification is totally unnecessary which just makes it further from original. In my opinion, we need to leave it as original as possible, on the premise that it doesn't contain any error which makes it unusable.

[Overdoze]

Thanks for looking into this, I guess that explains it then.

[vlad557776]

Great, a brand new build of pre-1xx Chicago! Not a holy find like Usability Testing builds or builds with Old Setup instead of a new 58s-styled one, but good.

[DiskingRound]

That was mentioned in the 90c leak IIRC...

From what I can tell, 58s was actually not the first Chicago scene leak:

Code: Select all

WIN41.ZIP         272  06-05-93  WINDOWS v4.0 Beta     FAKE  FAKE  !!

Could be build 40e or something like that... who knows...

[Overdoze]

Notice the tiny filesize and that it's been marked as fake. There's probably a reason for that.

[DiskingRound]

Notice the tiny filesize and that it's been marked as fake. There's probably a reason for that.

That doesn't necessarily mean it was fake, the BBS could have thought it was a fake due to being a new version of Windows.

[Overdoze]

No, the BBS probably thought it was fake because the file is only 272 bytes large.

[Lucas Brooks]

If you compare 89e's "fixed" SUWIN.EXE to 90c's, you'll notice that the code at that area is the same. Looks like that entire area got replaced by bytes at offset 5910-5933. It is now safe to say that complic.dll is not the one causing the error.

Now the question is, where did the "fixed" SUWIN.EXE come from? Somebody fixed it by replacing the code at that area with code from another build? Somebody found the original copy? My theory is SUWIN.EXE remained unchanged since build 89c and either build 89c or 89e got leaked at some point so the leaker simply took SUWIN.EXE from those builds to make the fix.

Here is the repacked ISO with fixed SUWIN.EXE: https://mega.nz/file/BMcm1KBS#2erepNPdp ... 67n3AJXx4I

[Battler]

- ComputerHunter: Since the same group had both SUWIN.EXE's, my hypothesis is that the corruption occurred when transferring from one group member to another, the receiving memeber then packed and released it, and then on repacking for corrected release, they realized it's corrupted, and had the sending member then sent them the file again.

[Overdoze]

Code: Select all

SC-CHI01.ZIP  1459128  05-01-94  MICROSOFT CHICAGO APRIL BETA          [01/15]

This is 90c.

Code: Select all

chicaprb.arj  Microsoft Chicago April 1994 release [Disk 1/14]

This is the first release of 89e.

Code: Select all

CAPRB01.ZIP      1,558,760  04-14-1994  VIII/12  MS Chicago [Windows 4.0 /DOS 7.0] Beta [1/13]

This is a repack of CHICAPBR.ARJ with a working SUWIN.EXE included separately (same as the one in CHIC-FIX.ZIP, minus the extra padding bytes at the end).

Code: Select all

CHICBET1 .ZIP 1,450,274  CHICAGO APRIL BETA 1/14

This could be either 89e, 90c or something else. Only listed on Playdoh 2 CD, which isn't available anywhere yet as far as I can tell.

[jagotu]

The "cracked" SUWIN.EXE might actually be original, while the "original" one is corrupted.

Compared to the "original" one, only offset 0x6FDC-0x6FFF is different. Decompiled in IDA Pro, I immediately noticed that the "original" one has meaningless ASM codes that cause "General Protection Fault" during installation.

You don't want to access FFFF:0000 under virtual 8086 mode right? Plus, that "call far ptr 2677h:37F8h" looks meaningless, too. The file size is far too small given the reference of code segment 2677h. I don't think Microsoft would, or the compiler/linker would, do things like this!

This actually looks like what imports look like before they are resolved. If the binary got corrupted in the code section, there's almost no chance of it not destroying the instruction opcodes, and so perfectly hitting the far call arguments.

Corruption could still be at play here, but maybe in the exe header instead? Or it could be a botched crack attempt. I'm just saying that your assumption that the "call far ptr"s are meaningless is incorrect.