aboutsummaryrefslogtreecommitdiff
path: root/src/wincrt.c
Commit message (Collapse)AuthorAgeFilesLines
* Tidy up some extensions and remove some ifdefsGravatar Michael Smith 2025-08-031-0/+4
| | | | | | | | | | | | | | | | | | | | | 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.
* Use shorter spellings of __asm and __attributeGravatar Michael Smith 2025-08-031-4/+4
| | | | | | | 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.
* Switch to Intel assembly syntaxGravatar Michael Smith 2025-08-031-1/+1
|
* Add memset to wincrt.cGravatar Michael Smith 2025-06-271-0/+17
| | | | | The code I'm about to commit appears to generate a call to this. Funny we never needed it until now...
* Improve the memcpy/memcmp functions a bitGravatar Michael Smith 2025-05-051-8/+21
| | | | | | I think memcpy might have been returning the wrong thing before, actually, but I guess it didn't matter in practice. Who the hell uses the return value from memcpy?
* Remove some unnecessary and/or confusing stuffGravatar Michael Smith 2024-02-261-2/+2
|
* Remove vcruntime140.dll dependencyGravatar Michael Smith 2023-08-271-0/+48
This will save users having to install the VS runtime in order to load the plugin. Turns out there was very little to implement to make this work. Turning off stack probing might cause spooky outcomes further down the line but we'll burn that bridge when we get there.