__acrt_initialize is here as a stub to later support linking ucrt statically. When it is statically linked the real function should be called, but when the executable links to ucrtdll, the initialization happens when the DLL is loaded, so we call a stub here.
vcruntime contains the code that is linked into ucrtbase (in VS it is also provided as vcruntime140.dll)
vcstartup contains the code that is statically linked into executables that link to ucrtbase.dll. In Visual Studio this is part of msvcrt.lib (the import library for msvcrt), similar to our current msvcrtex, and it gets linked when you link to ucrtbase as well. The name is based on the folder name in the library.
Both libraries share some code, but each file is only compiled once.
Check if the stack pointer is out of bounds, before trying to unwind a frame. This will not fix any crashes, but it prevents simple crashes from going into a recursive exception.
URLs are getting old. We have to
update URLs for documentation
purpose.
JIRA issue: CORE-19963
- Refresh old URLs.
- Add " (DEAD_LINK)" labels
to dead links.
- Use MS Learn links rather
than MSDN ones.
- Some dead links revived by
Web Archive.
- Don't change Wine Tests
and Wine Sync.
- Don't change 3rd party libraries.
- Don't append "redirected" labels.
Use #pragma section only for MSVC (and Clang-cl), because Clang doesn't like allocating non-const variables in a read-only section, while GCC doesn't understand these pragmas and ignores them.
Our FT_Bitmap_Convert function had a hack to make the
bitmap image compatible to ReactOS. I think the hack on
FT_Bitmap_Convert should be separated from our font
engine.
JIRA issue: CORE-16047
- Add FT_Bitmap_Convert_ReactOS_Hack function, that is
based on FT_Bitmap_Convert, and split the hack of
FT_Bitmap_Convert.
- Use FT_Bitmap_Convert_ReactOS_Hack in
IntGetBitmapGlyphWithCache function instead of
FT_Bitmap_Convert.
- Modify ftfd.spec to add
FT_Bitmap_Convert_ReactOS_Hack.
Useful for debugging.
Motivation: With SMP on x64 I found a number of instances where critical sections would be left abandoned, causing lockups. From what I can tell it was exceptions inside rpcrt4, which leave the process in a blocked state. Might or might not be related to x64 / SMP.
For real value, you still need to put checks at certain places manually, but this is not super straight forward, because there can be false positives, e.g. when a process is terminated due to an exception, where the abandoned lock is acceptable, and we have this during testing. It's difficult to 100% distinguish this from silent and very bad lock leaks.
Problematic code:
__try
{
SomeFunction(); // throws an exception with a CS held, e.g. heap code
}
__except(1)
{
DPRINT1("Oops. let's just pretend it's all ok!\n");
}
