3 ms·

"2. Hello Microsoft programmers, a memory dump is not a file format" This is exactly how Office file formats worked in the good old times. Made things faster (

"2. Hello Microsoft programmers, a memory dump is not a file format" This is exactly how Office file formats worked in the good old times. Made things faster (no parsing).

jug 4y ago
I also honestly doesn't mind this relic of the "old days", and other issues like it brought up in the article. The Registry is still very frequently accessed by Windows, often several times per second. I don't mind that the code to support that is making a ton of assumptions about the details that should never change anyway as it's hidden behind the Registry API. For all I care, keep that code simple and as performant as possible.
_gabe_ 4y ago
> Made things faster (no parsing). And simple. I parsed a wav file for the first time awhile ago and it was surprisingly refreshing how easy it was to parse. I just made some C structures in the format of the specification, and I could just read the file incrementally into different structs. This is way simpler than writing a parser and then marshalling data back and forth between an internal format and the configuration format.
- meepmorp 4y ago
  Wav files aren't a memory dump, unless you consider any file output to be a memory dump; certainly, not in the sense that old OLE (ha) files were.
xorcist 4y ago
For this particular version of software, compiler, and computer architecture, yes. After the first major upgrade, there's likely to be a whole lot of parsing involved.
int_19h 4y ago
This is often misunderstood. Unless you're talking about very early (pre-COM/OLE) versions of Office, the binary Office file format is https://en.wikipedia.org/wiki/COM_Structured_Storage https://en.wikipedia.org/wiki/COM_Structured_Storage - which is basically FAT-in-a-file, with individual files meant to correspond to COM objects. So it's a memory dump in a very broad sense of a serialized object graph, not in a sense of actual bytes of RAM directly copied to disk.

"2. Hello Microsoft programmers, a memory dump is not a file format" This is exactly how Office file formats worked in the good old times. Made things faster (no parsing).

jug 4y ago

I also honestly doesn't mind this relic of the "old days", and other issues like it brought up in the article. The Registry is still very frequently accessed by Windows, often several times per second. I don't mind that the code to support that is making a ton of assumptions about the details that should never change anyway as it's hidden behind the Registry API. For all I care, keep that code simple and as performant as possible.

_gabe_ 4y ago

> Made things faster (no parsing). And simple. I parsed a wav file for the first time awhile ago and it was surprisingly refreshing how easy it was to parse. I just made some C structures in the format of the specification, and I could just read the file incrementally into different structs. This is way simpler than writing a parser and then marshalling data back and forth between an internal format and the configuration format.

meepmorp 4y ago
Wav files aren't a memory dump, unless you consider any file output to be a memory dump; certainly, not in the sense that old OLE (ha) files were.

xorcist 4y ago

For this particular version of software, compiler, and computer architecture, yes. After the first major upgrade, there's likely to be a whole lot of parsing involved.

int_19h 4y ago

This is often misunderstood. Unless you're talking about very early (pre-COM/OLE) versions of Office, the binary Office file format is https://en.wikipedia.org/wiki/COM_Structured_Storage https://en.wikipedia.org/wiki/COM_Structured_Storage - which is basically FAT-in-a-file, with individual files meant to correspond to COM objects. So it's a memory dump in a very broad sense of a serialized object graph, not in a sense of actual bytes of RAM directly copied to disk.