On 11/04/15 20:12, Martin Storsjo wrote:
The built DLL links to (and loads function pointers at runtime from) msvcr120, instead of ucrtbase (which would be more correct).
We really need to e.g. share file handles between ucrtbase and msvcp140. We will need to find a way of linking against ucrtbase.
It will probably need to be done by defining wrappers around some functions. For example missing _invalid_parameter should be probably worked around by defining following function in msvcp140: void __cdecl _invalid_parameter(const wchar_t *expr, const wchar_t *func, const wchar_t *file, unsigned int line, uintptr_t arg) { return _invalid_parameter_noinfo(); }
Something similar needs to be done with __p__iob (use __acrt_iob_func function).
If you have any problems with other function please let me know. Probably some more testing/work will be needed to deal with missing new/delete functions.
Thanks, Piotr
On Fri, 6 Nov 2015, Piotr Caban wrote:
On 11/04/15 20:12, Martin Storsjo wrote:
The built DLL links to (and loads function pointers at runtime from) msvcr120, instead of ucrtbase (which would be more correct).
We really need to e.g. share file handles between ucrtbase and msvcp140. We will need to find a way of linking against ucrtbase.
It will probably need to be done by defining wrappers around some functions. For example missing _invalid_parameter should be probably worked around by defining following function in msvcp140: void __cdecl _invalid_parameter(const wchar_t *expr, const wchar_t *func, const wchar_t *file, unsigned int line, uintptr_t arg) { return _invalid_parameter_noinfo(); }
Something similar needs to be done with __p__iob (use __acrt_iob_func function).
If you have any problems with other function please let me know. Probably some more testing/work will be needed to deal with missing new/delete functions.
Thanks, this does indeed seem to be implementable without too much effort in the end. The new/delete functions also seem to be pretty simple to reimplement based on malloc (which does the same msvcrt_heap_alloc(0, size) as MSVCRT_operator_new), _callnewh and free.
I'll send an updated patchset for this now, which still is kinda RFC but much better than the previous one.
// Martin
On 11/06/15 11:25, Martin Storsjö wrote:
Thanks, this does indeed seem to be implementable without too much effort in the end. The new/delete functions also seem to be pretty simple to reimplement based on malloc (which does the same msvcrt_heap_alloc(0, size) as MSVCRT_operator_new), _callnewh and free.
The hard part may be related to exception throwing in case of failure (I was not looking on it - it may be easy).
Piotr
On Fri, 6 Nov 2015, Piotr Caban wrote:
On 11/06/15 11:25, Martin Storsjö wrote:
Thanks, this does indeed seem to be implementable without too much effort in the end. The new/delete functions also seem to be pretty simple to reimplement based on malloc (which does the same msvcrt_heap_alloc(0, size) as MSVCRT_operator_new), _callnewh and free.
The hard part may be related to exception throwing in case of failure (I was not looking on it - it may be easy).
msvcp also seems to have a bad_alloc exception (the one in msvcrt isn't exposed in ucrtbase, where they seem to have removed most of all the C++ stuff that used to be in msvcrt), so it turned out to be as simple as throw_exception(EXCEPTION_BAD_ALLOC, "bad allocation"); instead of throw_bad_alloc("bad allocation");.
// Martin
-
Martin Storsjö -
Piotr Caban