Mundane C tricks ...

[Baker]

[taniwha]

[Baker]

[Spike]

regarding consoles, there's a OutputDebugStringA function available to windows programs that will dump the given string to a debug console within your IDE. There are also a few programs that can scrape these prints systemwide or something, thus avoiding the need to polute your pipes. This is especially important within libraries as you don't know if it already has a console anyway.

Regarding the absurd idea of cramming 64MB of data into an .exe - is it really any different from cramming 64MB of data into a .pak file?
In the unix world, people tend to write some sort of binary-data-file-to-c-byte-array file converter. Can just #include it then in an OS-agnostic way.

I use double pointers with single-linked lists loads. I tend to not use double-linked lists all that much.

Regarding memcmp+structs, better to ensure that your structs are always aligned properly, especially if you're reading/writing them to disk/network too. 32+64bit differences can be a pain though...
memsetting everything to 0 serves to protect against future changes. You can of course also use valgrind to find the issues, but there's always the probability that you'll miss half the occurences. Yay for large chunks of code.
GCC's memset inlining is meant to be able to be able to partially no-op the memset depending on which fields are later overwritten, however I assume this only really works with small structures that don't generate silly amounts of data or variable layouts etc.

[Baker]

[Baker]

[Spike]

exes+binaries are generally memory mapped.
This means that data in your cdata section is only actually loaded when first read. Often this includes your writable data too, assuming it has no relocations inside.
When you run low on memory, these pages will normally be reread from the exe instead of your page file.
Yes, recompiling/relinking a binary can result in already-running instances crashing because the data in newly poked pages isn't what should be there when it was first run - I've seen linux gcc do this a fair bit a while ago. I assume ld unlinks rather than truncates nowadays (orphaning the old file+process images), to avoid this issue.

A windows resource is not mapped by default, but only when you use the builtins to read it.
When running a program from a remote/temporary file system (like a network share or a cd drive), windows will check the linker flags to see whether the entire exe should be read/copied, or if its okay to load on demand.

As you're already aware, you can use FindResource etc to load resources out of arbitary modules, exe files or dll files or whatever.
But you can also use BeginUpdateResource+UpdateResource+EndUpdateResource to edit the resources within an exe/dll/whatever without recompiling it.
You can only really do this because resources are not unlike data files within a pak - they are not memmapped by default, and do not consume address space nor memory until explicitly mapped.

[mh]

[Baker]

[taniwha]

Baker: first, by "meh", all I meant was a lack of interest in windows specific stuff (no offense meant), but in retrospect, I realize it would be useful for improving windows support in QF. So, double sorry.

For the text format, take a look at qfplist (, , ). The C version needs a couple of other modules from QF: dstring and hash. All three modules are reasonably well documented.(, and ). There is also a Ruamoko (Objective-QuakeC) interface, but I suspect you're not as interested in that . The python version is standalone: not even one import, and returns python native types (dictionary, list, string, and whatever binascii returns (hmm, does that make it python 3 dependent?)). It raises PListError exceptions on errors (easily catchable).

Anyway, the C version is a nice code drop-in (3 .c files, 3 .h files) with maybe a little editing (mostly in the #include lines), the python version is standalone (at least for python 3), the code is well tested (QF flat-out relies on it, especially dstring and hash), and the format is .

[Baker]

[Baker]

[taniwha]

[taniwha]

An update for inlined use of alloca: it's possible to force gcc to inline such a function by using __attribute__((always_inline)). I just checked the generated assembly, and gcc resets the stack pointer after the inlined code.

That said, I wouldn't trust Microsoft to get it right .

[taniwha]

Oh, and the trick for tangled #includes: nuke them all . You can then add new ones as necessary. If you get an error in a .h file, add the #include there, otherwise in the .c file.