msvcrt | 易学教程

MinGW MSYS, MSVCRT, and the TZ environment variable

阅读更多关于 MinGW MSYS, MSVCRT, and the TZ environment variable

问题 In short, how to make both MSVCRT and MinGW MSYS share the TZ environment variable without conflicts? Or, how to make both support timezones without conflicts? Further information In order to have date command of MSYS displaying correct local time, and because MSYS itself uses its own C runtime instead of MSVCRT, I have set TZ environment variable according to GNU C library documentation: export TZ="BRT+3BRST,M10.3.0/0,M2.3.0/0" Unfortunately, this conflicts with Microsoft C runtime specs,

vs2012 toolset compatibility

阅读更多关于 vs2012 toolset compatibility

问题 In my VS2012 I have 4 toolsets available: v90, v100, v110 and v110_xp. I did a simple test with two projects testlib (a static library) and testexe (console application). The interface was just one function with signature void test() . The results: testlib(v90), testexe(anything other than v90) -> does not link testlib(v100), testexe(v110 or v110_xp) -> does link However, it seemed somewhat weird to me that v100 and v110 would link so I tried to complicate the scenario a little bit. Now my

Writing a DLL that loads msvcr80.dll and exposes the free()-function

阅读更多关于 Writing a DLL that loads msvcr80.dll and exposes the free()-function

问题 I have a third-party DLL that depends on MSVCR80 and allocates resources that I need to cleanup. The library does not expose a free -function for doing this. Instead, I need to load the same runtime library and manually call the free function. As a workaround I'm trying to write a "wrapper" DLL that loads the correct runtime and exposes the free function. This DLL is created using Visual Studio 2010 and is dependent on a separate runtime library. Doing LoadLibrary("msvcr80.dll") fails with

Common runtime for different DLLs

阅读更多关于 Common runtime for different DLLs

问题 I need to build a DLL capable to load other DLLs at runtime; these other DLLs have a rather intimate relationship with the main DLL (this is Python and extensions), so they must have a common runtime. The main DLL must be a single file that can be simply copied on the target machine. The auxiliary DLLs will be placed in a different directory. So: "common runtime" means no static linking; "single file + simple copy" rules out the shared MS redistributables, especially when coupled with

Why is msvcrt (very very) slow?

阅读更多关于 Why is msvcrt (very very) slow?

问题 I'm specifically asking about the old msvcrt.dll . Hasn't Microsoft updated that library in newer versions of windows? or is that exactly the same library that one can find in Windows 98 distros? I tested msvcrt against Cygwin with a test program that calls malloc a lot of times by a singly linked list blocking queue with mutexes and semaphores. By ifdef s, the program can be compiled to use Posix functions or else use Windows API calls. When compiled by MinGW with WinAPI calls the only

Why does windows side by side (winSxS) install policy for auto upgrade when there are known issues between versions?

阅读更多关于 Why does windows side by side (winSxS) install policy for auto upgrade when there are known issues between versions?

We have an app compiled using MSVC 2K5, SP1 (version 762 msvcrt80) All is well, right up until somebody installs on the same machine .Net3.0SP1, and along with it msvcrt80 version 1433 is installed and a policy to automatically upgrade. Now we have random crashes all over the place and unhappy customers. I understand we can adjust our manifest files to force the usage of a specific version, but I've only found the really ugly way of copying detail that is auto generated and modifying it by hand. This is especially unpleasant with a large number of apps to fix Can we instead get rid of the

How do I find the cause of this linker error?

阅读更多关于 How do I find the cause of this linker error?

After going through a lengthy process to rename a project, my DLL project will not build in Debug mode (Release builds work): MSVCRTD.lib(msvcr90d.dll) : error LNK2005: _CrtDbgReportW already defined in LIBCMTD.lib(dbgrpt.obj) This project, and the five static libraries it depends on, are set to use "Multi-threaded Debug (/MTd)" (under C/C++|Code Generation|Runtime Library). I believe LIBCMTD.lib is the one for multi-threaded debug, but what is MSVCRTD.lib, and what could be causing this error? If it makes a difference, this DLL is for Windows CE. LIBCMT is what you need for /MT, MSVCRT is

Working around fls limitations with too many statically linked CRTs?

阅读更多关于 Working around fls limitations with too many statically linked CRTs?

问题 When loading external DLLs (not under our control) via LoadLibrary, we're hitting a problem where the statically linked CRT in those DLLs are failing to allocate fiber-local storage. This is similar to mskb 193462, except that this is FLS and there's only 128 of them. Are there any useful ways to work around the problem? The CRT is using GetProcAddress to find FlsAlloc anyway (since that apparently never existed in XP), so does it even really need it? (This is on Vista, where FlsAlloc

Assertion error in CRT calling _osfile() in VS 2008?

阅读更多关于 Assertion error in CRT calling _osfile() in VS 2008?

问题 I have a C++ code base that has been working for a long time. The code base was a legacy VS 2003 set of projects that I recently migrated to VS 2008. The migration seemed to be successful in that the resulting program built, and run. I reinstalled my OS and all applications on a fresh drive, and now when I attempt to debug the program within the debugger, I receive an assertion error inside the CRT's chsize (really, _chsize_s ). Specifically (cropped to essentials, ignoring safety checks):

mixing code compiled with /MT and /MD

阅读更多关于 mixing code compiled with /MT and /MD

问题 I have a large body of code, compiled with /MT (i.e. expecting to statically link against the CRT). I need to combine this with a static third-party library, which has been built with /MD (i.e. expecting to link the CRT dynamically). Is it theoretically possible to link the two into one executable without recompiling either? If I link with /nodefaultlib:msvcrt, I end up with a small number of undefined references to things like __imp__wgetenv . I'm tempted to try implementing those functions