Bytepointer

Jokes aside, I can think of a couple of differences: - For the longest time, languages with typed (“checked”) exceptions lacked any parametric polymorphism worth a damn. That made the typing... less than optimally useful, especially with fallible callbacks. Sum types can borrow all that from the existing language, and you’d feel intensely awkward if you tried to go with untyped errors there (it’s of course still possible, through Dynamic or interface {} or whatever Rust’s thing is). Though looking at the boilerplate fest that is the latest Rust (sum-types-based) error handling article posted here[1], I’m not entirely convinced the situation has improved. Perhaps open union types of some sort really are needed? That’s where the algebraic-effects languages seem to be going, anyway. - Exceptions are more strict about what you can do with them: you can return or you can bind, monadically speaking. If an exception was raised, everything stops until it’s caught. With sum types (concrete ones, not an abstract error monad you can’t run), you are allowed to have several propagation chains at once and manipulate them as data. The lack of that additional flexibility is what makes exceptions (more cheaply?) implementable in terms of stack unwinding. (Traditionally, stack unwinding is thought of as expensive, but I don’t really see why. Sure SJLJ-induced register spills are bad, and sure table-based unwinding is slow as hell, but a linked list of frames as in Win32 SEH[2] has to be…

Lost? Past? The Windows world still runs on this stuff, and there are still plenty of people who know how it works and make money from knowing. That said, MS have unintentionally (I think) done a pretty good job of scrubbing the internet clean of useful information about it by breaking all their links multiple times. I keep a personal copy of some things, such as Matt Pietrek's classic two-parter "An In-Depth Look into the Win32 Portable Executable File Format", lest they disappear completely while the technologies they describe continue to run the world. Edit: MS only appear to have part 2 of that article in their archive, and it contains broken links (of course). Both parts can still be read at [1] and [2] and remain as relevant as they were the day they were written [1] https://bytepointer.com/resources/pietrek_in_depth_look_into_pe_format… [2] https://bytepointer.com/resources/pietrek_in_depth_look_into_pe_format…

I suggest using this archive: http://bytepointer.com/resources/old_new_thing/20050607_141_what_if_tw… because devblogs.microsoft.com has repeatedly deleted all the comments and broken links and will do so again.

In my obviously biased opinion, very specialised, but sometimes exactly what you needed (I have used this in anger maybe 2-3 times in my career since then, which is why I wrote the C version): https://github.com/tialaramex/leakdice (or https://github.com/tialaramex/leakdice-rust) Leakdice implements some of Raymond Chen's "The poor man’s way of identifying memory leaks" for you. On Linux at least. https://bytepointer.com/resources/old_new_thing/20050815_224_the_poor_… All leakdice does is: You pick a running process which you own, leakdice picks a random heap page belonging to that process and shows you that page as hex + ASCII. The Raymond Chen article explains why you might ever want to do this.

On Windows, the Microsoft compilers and linkers have inserted such toolchain/library version metadata into PE executables for decades now (the "RICH" header — https://bytepointer.com/articles/the_microsoft_rich_header.htm). At the time that Microsoft started doing it, paranoiacs thought it was some kind of anti-piracy software fingerprinting mechanism, embedding the compiling computer's MAC address or something. But really, it serves exactly the same purpose that Golang's effort does here: to let you map compiled-artifact back to inputs.

http://bytepointer.com/resources/old_new_thing/20050815_224_the_poor_m… (a site that tries to keep a proper backup of the ever moving writings of Chen)

I meant that skinning has already been cool before XP, with various degrees of attention to detail and various amounts of system hacks. WindowBlinds for the whole system, application-level reskins. Even Java applets were once considered cool simply because they used their own UI toolkit! Moreover, Microsoft had essentially sold wallpapers and cursors as Plus packs. However, after the release of XP developers did not stick to using correct native components that would automatically look like Windows 98 on Windows 98, and like Windows XP on Windows XP. They continued to reinvent everything via third-party skinning libraries, but now with kind-of-hip kind-of-XP styles. Random example: http://web.archive.org/web/20041213230620/http://www.helium2.com/eng/i… Native menus don't work like that. The gradient between “Standard theme” and “Silver theme” background colors is someone's invention. Scrollbars should reach the top of the table views, and their native headers look different. Extra shadows here and there. etc., etc. Everything is improperly remade. I suppose it was an important topic if they specifically introduced visual style signing at the time when system files and drivers were not even required to be signed. Maybe the perspective of new antitrust trials botched another EEE campaign, maybe the peasants just refused to bow to the king that time. As for undocumented framework, look up "Windows DirectUser Engine" and "DirectUIHWND". Here's someone…

>So why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Since Windows 10 it ships with Universal C Runtime, which is used by VS2015+. System software uses these runtimes too. For Win7+ it was added as system update, though MS later relented and said it was fine to copy-paste all the api-ms* libraries from the SDK into your application directory so it also works on outdated installations. In the past it was different though, as system software was compiled against MSVCRT.DLL, but you wasn't supposed to use it and instead use version specific DLLs shipped in "Visual C++ Redistributables". Though going back to Windows 9x there was a time when MSVCRT.DLL was the library that was supposed to be used by applications. See http://bytepointer.com/resources/old_new_thing/20140411_092_windows_is…

To give further background, the Devilution team has primarily relied on these resources: 1. The Japanese Playstation port with debug symbols contained in `DIABPSX.SYM`. (see [1]). Example debug info of the Cathedral dungeon generation algorithm: // address: 0x801259D0 // line start: 612 // line end: 624 void DRLG_L1Floor__Fv() { // register: 19 register int i; // register: 20 register int j; // register: 3 register long rv; } 2. The debug release of the PE executable, which contained assert strings (see [2]). Example assert string: "plr[myplr].InvGrid[i] <= plr[myplr]._pNumInv" 3. The Rich header of the PE executable, which details the exact version of the original compilers and linkers used to build `Diablo.exe` (see [3,4]). Example information recovered from the Rich header of `Diablo.exe`: Id Build Count Name Description 0 0 155 Unknown [---] Number of imported functions (old) 1 0 229 Import0 [---] Number of imported functions 6 1668 1 Cvtres500 [RES] VS97 (5.0) SP3 cvtres 5.00.1668 2 7303 29 Linker510 [IMP] VS97 (5.0) SP3 link 5.10.7303 3 7303 1 Cvtomf510 VS97 (5.0) SP3 cvtomf 5.10.7303 4 8447 2 Linker600 [LNK] VC++ 6.0 SP3,SP4,SP5,SP6 link 6.00.8447 48 9044 72 Utc12_2_C [---] VC++ 6.0 SP5 Processor Pack 19 9049 12 Linker512 Microsoft LINK 5.12.9049 4. Discovery of the original set of compiler flags used to…

Assuming you are interested in learning not just Assembly but how to use it in conjunction with a high-level language (almost always C/C++); Background: --- Matt Pietrek's "Just Enough Assembly Language to Get By" - http://bytepointer.com/resources/pietrek_asm_pt1.htm --- Hongjiu Lu "ELF: From The Programmer's Perspective" - http://beefchunk.com/documentation/sys-programming/binary_formats/elf/… Books: --- Computer Systems: A Programmer's Perspective (3rd Edition) by Bryant & O'Hallaron - https://www.amazon.com/Computer-Systems-Programmers-Perspective-3rd/dp… --- Modern X86 Assembly Language Programming by Daniel Kusswurm - https://www.amazon.com/Modern-X86-Assembly-Language-Programming/dp/148… --- Low-Level Programming by Igor Zhirkov - https://www.amazon.com/Low-Level-Programming-Assembly-Execution-Archit…