Microsoft open-sources original File Manager from the ‘90s
Microsoft is releasing the source code for its original Windows File Manager from nearly 28 years ago. Originally released for Windows 3.0, the File Manager was a replacement for managing files through MS-DOS, and allowed Windows users to copy, move, delete, and search for files. While it’s a relic from the past, you can still compile the source code Microsoft has released and run the app on Windows 10 today.
https://www.theverge.com/2018/4/9/17214586/microsoft-windows-file-manager-windows-10-app-download
https://www.theverge.com/2018/4/9/17214586/microsoft-windows-file-manager-windows-10-app-download
closed account (E0p9LyTq)
Heh, the file manager program is only 309KB in size.
Granted, it is hooking into a lot of Windows DLLs. So is Windows Explorer.
Windows 10 explorer.exe (Windows Explorer) is 3,813KB as reported by Windows.
Shows how each new version of Windows bloated bigger and bigger as they refined and improved the core of Windows.
Granted, it is hooking into a lot of Windows DLLs. So is Windows Explorer.
Windows 10 explorer.exe (Windows Explorer) is 3,813KB as reported by Windows.
Shows how each new version of Windows bloated bigger and bigger as they refined and improved the core of Windows.
I feel like nowadays it's a) difficult to control the ever-expanding executable sizes, and b) not even worth anyone's time.
Just to give an example, right now I'm working on a native port of gen. 1 Pokemon, a game that weights in at 1 MiB, and I'm already at nearly 2 MiB, even though there's still like 95% of the scripts and lost of mechanics to implement. Now, granted, this does include pretty much all the assets (graphics, sounds, maps, objects) and data and I'm not using any compression at all, but still. It's crazy how you can directly see the executable grow as you continue to implement more things.
But still, 2 MiB is nothing. It compresses down to ~650 KiB, which even on dialup would take ~10 seconds to transfer. It doesn't even register in current storage devices.
The real current problem with bloat is on the web, not on native platforms.
PS: LZMA compresses the Pokemon ROM down to ~350 KiB.
Just to give an example, right now I'm working on a native port of gen. 1 Pokemon, a game that weights in at 1 MiB, and I'm already at nearly 2 MiB, even though there's still like 95% of the scripts and lost of mechanics to implement. Now, granted, this does include pretty much all the assets (graphics, sounds, maps, objects) and data and I'm not using any compression at all, but still. It's crazy how you can directly see the executable grow as you continue to implement more things.
But still, 2 MiB is nothing. It compresses down to ~650 KiB, which even on dialup would take ~10 seconds to transfer. It doesn't even register in current storage devices.
The real current problem with bloat is on the web, not on native platforms.
PS: LZMA compresses the Pokemon ROM down to ~350 KiB.
Last edited on
bloat is intentional. its used to sell new processors, memory, bandwidth etc etc...
its pretty disgusting that gcc is producing minimum 150kbyte binaries even with all optimizations turned on, using the same #include statements that would have been in a program in the 1990s! Cygwin ain't what it used to be.
The mandelbrot set code I posted compiles to a 157001 byte program even with -Os specified.
cat mandelbrot.exe | less reveals garbage like this in supposedly "optimized" exe files
Disgusting. Why is there XML in my EXE? :-(
its pretty disgusting that gcc is producing minimum 150kbyte binaries even with all optimizations turned on, using the same #include statements that would have been in a program in the 1990s! Cygwin ain't what it used to be.
The mandelbrot set code I posted compiles to a 157001 byte program even with -Os specified.
cat mandelbrot.exe | less reveals garbage like this in supposedly "optimized" exe files
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--The ID below indicates application support for Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!--The ID below indicates application support for Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!--The ID below indicates application support for Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
</assembly> |
Disgusting. Why is there XML in my EXE? :-(
There's also labels for stuff like GUID_BATTERY_DISCHARGE_FLAGS - things that a program including stdio and stdlib and using vt100 escape sequences never would have had 25 years ago...
When the bloat is in gcc, its the end of the game. There's nowhere left to turn except raw assembly language.
When the bloat is in gcc, its the end of the game. There's nowhere left to turn except raw assembly language.
Topic archived. No new replies allowed.