| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since this codebase is already extremely nonportable, I've decided to
relax the obsessive ifdef-else-error usage around all the extensions.
From now on, if there's no alternative to using an extension, we can
just use that extension. If it's possible to do something in a
relatively portable way, we can still try to do that in order to make
the code somewhat reusable, in contexts where that makes sense.
I also decided to use langext.h for naked functions and tail calls. If
that's used in another codebase build with a different compiler, those
just won't work, but that's fine. The benefit is really just that
there's less ceremony in places where those are used, because it's
likely there'll be a few more such places in the future, and it gets
annoying reading all the double-underscore stuff all over the place.
I still kind of want to do something about all the _WIN32 ifdefs too,
but I've realised that doing so will lead to almost nothing actually
being built on Linux. Then again, none of it currently runs on Linux so
I guess that's a moot point. Will worry about it later, anyway.
|
| |
|
|
|
|
|
| |
Turns out, there's no need for the trailing underscores. Plus, glibc
does some stupid stuff with __attribute__ for non-GCC compilers. Not
that that matters here, but it seems like a good practice just to use
the forms that never have such problems. And it's shorter too.
|
| | |
|
| | |
|
| |
|
|
|
| |
Every. Single. Time. And having screwed up the zip dates was just a
bonus I suppose.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This probably should have been the design from the start.
It's still possible to use void pointers, and this is done in a couple
of places for simplicity, but wherever possible, we have actual structs
for things now.
Additionally, in places where vtables are fiddled with, e.g. vtable
hooks, we have actual struct definitions with vtable pointers so there's
need for pointer-casting horror.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This both simplifies and complicates things, but probably hopefully
maybe simplifies things overall. Certainly in cases like the L4D1 demo
thing where there's 3 inline hooks at once, it seems simpler to be able
to batch the fallible stuff to avoid rollbacks. In cases where you only
need one hook, it's a bit more verbose, but what can you do.
Thanks bill for discussing this with me pretty exhaustively and giving a
lot of good input.
I think both of us still kind of hate it actually.
|
| |
|
|
|
| |
Doesn't matter how many history rewrites I do before pushing my local
branch, there will always be something I still got wrong.
|
| |
|
|
|
|
|
|
| |
They're legally unnecessary as far as I know, and kind of annoying to
maintain on a long-term basis.
This was done with the consent of all 3 other contributors, in case
anyone was wondering.
|
| |
|
Michael Smith
Hayden K
