Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-10-31 03:48:17 +00:00
Code Issues Packages Projects Releases Wiki Activity
reactos/dll/win32/framedyn/framedyn_msvc.spec

77 lines
3.5 KiB
RPMSpec
Raw Normal View History

[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?AllocBeforeWrite@CHString@@IAEXH@Z(long)
[FRAMEDYN] Fix typo svn path=/trunk/; revision=59942
2013-09-01 15:04:21 +00:00
@ thiscall ?AllocBuffer@CHString@@IAEXH@Z(long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?AllocCopy@CHString@@IBEXAAV1@HHH@Z(ptr long long long)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?AllocSysString@CHString@@QBEPAGXZ()
@ thiscall ?AssignCopy@CHString@@IAEXHPBG@Z(long wstr)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ??0CHString@@QAE@ABV0@@Z(ptr)
@ thiscall ??0CHString@@QAE@PBD@Z(str)
@ thiscall ??0CHString@@QAE@PBE@Z(str)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ??0CHString@@QAE@PBG@Z(wstr)
@ thiscall ??0CHString@@QAE@PBGH@Z(wstr long)
@ thiscall ??0CHString@@QAE@GH@Z(long long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ??0CHString@@QAE@XZ()
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?Collate@CHString@@QBEHPBG@Z(wstr)
@ thiscall ?Compare@CHString@@QBEHPBG@Z(wstr)
@ thiscall ?CompareNoCase@CHString@@QBEHPBG@Z(wstr)
@ thiscall ?ConcatCopy@CHString@@IAEXHPBGH0@Z(long wstr long wstr)
@ thiscall ?ConcatInPlace@CHString@@IAEXHPBG@Z(long wstr)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?CopyBeforeWrite@CHString@@IAEXXZ()
@ thiscall ?Empty@CHString@@QAEXXZ()
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?Find@CHString@@QBEHPBG@Z(wstr)
@ thiscall ?Find@CHString@@QBEHG@Z(long)
@ thiscall ?FindOneOf@CHString@@QBEHPBG@Z(wstr)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?Format@CHString@@QAAXIZZ(long long long)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?Format@CHString@@QAAXPBGZZ(long wstr long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?FormatMessageW@CHString@@QAAXIZZ(long long long)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?FormatMessageW@CHString@@QAAXPBGZZ(long ptr long)
@ thiscall ?FormatV@CHString@@QAEXPBGPAD@Z(wstr long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?FreeExtra@CHString@@QAEXXZ()
@ thiscall ?GetAllocLength@CHString@@QBEHXZ()
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?GetAt@CHString@@QBEGH@Z(long)
@ thiscall ?GetBuffer@CHString@@QAEPAGH@Z(long)
@ thiscall ?GetBufferSetLength@CHString@@QAEPAGH@Z(long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?GetData@CHString@@IBEPAUCHStringData@@XZ()
@ thiscall ?GetLength@CHString@@QBEHXZ()
@ thiscall ?Init@CHString@@IAEXXZ()
@ thiscall ?IsEmpty@CHString@@QBEHXZ()
@ thiscall ?Left@CHString@@QBE?AV1@H@Z(long)
[FRAMEDYN] - Fix MSVC build - Fix some name mangling issues - Add stub libraries to make the dll actually usable. The GCC alias library is still broken though. svn path=/trunk/; revision=60037
2013-09-11 18:36:27 +00:00
@ thiscall ?LoadStringW@CHString@@QAEHI@Z(long)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?LoadStringW@CHString@@IAEHIPAGI@Z(long wstr long)
@ thiscall ?LockBuffer@CHString@@QAEPAGXZ()
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?MakeLower@CHString@@QAEXXZ()
@ thiscall ?MakeReverse@CHString@@QAEXXZ()
@ thiscall ?MakeUpper@CHString@@QAEXXZ()
@ thiscall ?Mid@CHString@@QBE?AV1@H@Z(long)
@ thiscall ?Mid@CHString@@QBE?AV1@HH@Z(long long)
@ thiscall ?Release@CHString@@KGXPAUCHStringData@@@Z(ptr)
[FRAMEDYN] - Fix MSVC build - Fix some name mangling issues - Add stub libraries to make the dll actually usable. The GCC alias library is still broken though. svn path=/trunk/; revision=60037
2013-09-11 18:36:27 +00:00
@ thiscall ?Release@CHString@@IAEXXZ()
@ thiscall ?ReleaseBuffer@CHString@@QAEXH@Z(long)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ?ReverseFind@CHString@@QBEHG@Z(long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?Right@CHString@@QBE?AV1@H@Z(long)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ stdcall ?SafeStrlen@CHString@@KGHPBG@Z(wstr)
@ thiscall ?SetAt@CHString@@QAEXHG@Z(long long)
@ thiscall ?SpanExcluding@CHString@@QBE?AV1@PBG@Z(long wstr)
@ thiscall ?SpanIncluding@CHString@@QBE?AV1@PBG@Z(long wstr)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ?TrimLeft@CHString@@QAEXXZ()
@ thiscall ?TrimRight@CHString@@QAEXXZ()
@ thiscall ?UnlockBuffer@CHString@@QAEXXZ()
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ??BCHString@@QBEPBGXZ(ptr)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ??YCHString@@QAEABV0@ABV0@@Z(ptr)
@ thiscall ??YCHString@@QAEABV0@D@Z(long)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ??YCHString@@QAEABV0@PBG@Z(wstr)
@ thiscall ??YCHString@@QAEABV0@G@Z(long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ??4CHString@@QAEABV0@PAV0@@Z(ptr)
@ thiscall ??4CHString@@QAEABV0@ABV0@@Z(ptr)
@ thiscall ??4CHString@@QAEABV0@PBD@Z(str)
@ thiscall ??4CHString@@QAEABV0@D@Z(long)
@ thiscall ??4CHString@@QAEABV0@PBE@Z(str)
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ thiscall ??4CHString@@QAEABV0@PBG@Z(wstr)
@ thiscall ??4CHString@@QAEABV0@G@Z(long)
@ thiscall ??ACHString@@QBEGH@Z(long)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ thiscall ??1CHString@@QAE@XZ()
[SPEC2DEF] - Ignore C++ redirects again because they breaks msvcrt CORE-7465 #resolve [FRAMEDYN] - Work around the lack of C++ redirects svn path=/trunk/; revision=60135
2013-09-15 14:33:33 +00:00
@ stdcall ??H@YG?AVCHString@@GABV0@@Z(long ptr)
@ stdcall ??H@YG?AVCHString@@ABV0@G@Z(ptr long)
@ stdcall ??H@YG?AVCHString@@ABV0@PBG@Z(ptr wstr)
@ stdcall ??H@YG?AVCHString@@PBGABV0@@Z(wstr ptr)
[FRAMEDYN] Partplement framedyn.dll So far, only CHString class is implemented in it Regarding CHString class implementation: It has been implemented matching Windows behavior and bugs It might not be really nice at some points but this ensures compatibility with applications relying on it. As a side note: this might explain why this API was abandonned after w2k3... Regarding the DLL itself: Its implementation into ReactOS allows systeminfo.exe application from w2k3 to load and start initialization into ReactOS. It stops working later on with some IDispatch error. The DLL cannot be used to build any application against framedyn.dll with our "default" BE (read with G++). Only MSVC mangled name are exported so far (as on Windows ;-)) thanks to aliasing. This is why there are two spec files. This makes G++ unable to link with it though. This is the reason why there are no framedyn_apitests so far. Furthermore, the DLL only have exports for x86 and none for x64 for the moment. Any help is welcome for having exports for x64 target and to be able to have aliasing for G++ (from its mangled names to MSVC ones). svn path=/trunk/; revision=59940
2013-09-01 14:48:09 +00:00
@ stdcall ??H@YG?AVCHString@@ABV0@0@Z(ptr ptr)
Reference in a new issue Copy permalink