Remove dependency on MSVC CRT about libmdbx HOT 8 CLOSED

@georgehazan, у меня нет XP чтобы по-завершении проверить совместимость. Поможете?

В идеале это-бы прикрутить к текущему CI на AppVeyor, но у меня не получилось добиться сборки со старым SDK (всё равно были доступны определения из последующих версий).

Кроме этого, нужно синхронизировать все (даже минимальные) ваши правки с mainstream.

from libmdbx.

@leo-yuriev да, конечно помогу. у меня есть XP, можно пробовать в любой момент

Кроме этого, нужно синхронизировать все (даже минимальные) ваши правки с mainstream.

Правок две, одна чисто косметическая для сборки со старым SDK, вторая - для пробрасывания флага MDBX_EXCLUSIVE внутрь открытия файла.

from libmdbx.

@georgehazan, а можете выслать мне почтой таблицу экспорта из 32-битной версии ntdll.dll от Windows XP или Windows 2000?

dumpbin.exe /exports C:\Windows\System32\ntdll.dll > ntdll.exp

from libmdbx.

@wangjia184, please check currnt master branch.

from libmdbx.

Thanks @leo-yuriev
I am implementing a .NET standard assembly wrapping libmdbx v1.6.

Will this change merged to v0.1?
Is there any breaking changes in the exposed methods between v2.0(master) and v1.6(0.1 branch)

from libmdbx.

@leo-yuriev these changes might cause serious performance degradation, because memory management inside Universal CRT is much faster & safer than one in kernel32.dll (Local*). my advice is to keep both variants, i.e. libmdbx should call usual CRT functions, if macro MDBX_BUILD_DLL is not defined

from libmdbx.

Thanks @leo-yuriev
I am implementing a .NET standard assembly wrapping libmdbx v1.6.

Will this change merged to v0.1?

No, since it is not a bugfux, but enhancement.

Is there any breaking changes in the exposed methods between v2.0(master) and v1.6(0.1 branch)

Do you tried git diff v0.1.6 v0.2.0 -- mdbx.h?

from libmdbx.

@leo-yuriev these changes might cause serious performance degradation, because memory management inside Universal CRT is much faster & safer than one in kernel32.dll (Local*). my advice is to keep both variants, i.e. libmdbx should call usual CRT functions, if macro MDBX_BUILD_DLL is not defined.

In 30 years, Windows has not introduced acceptable dynamic memory management API?
Seems this is not an libmdbx issue ;)

Nevertheless, libmdbx calls memory-management functions relatively rare.
Most often such calls occurs for page allocation, but only when DB was opened without MDBX_WRITEMAP.
So, the overhead from Windows I/O will be 100-1000 times large than the memory management.

On the other hand, the switching to CRT functions should be available at least to measure an actual difference. So, d2bfb2e.

from libmdbx.