Hi,
I'm having big troubles using function pointers.
Shortly:
I'm trying to build a Winelib compatible DLL that returns function
pointers; that pointers must be used by a WIN32 app that runs under Wine.
The problem is that the returned function pointers, when directly used
by the WIN32 code, crash the application:
"wine: Unhandled exception (thread 0009), starting debugger..."
In details:
For instance the DLL is a PKCS#11 library.
The PKCS#11 function C_GetFunctionList() returns a structure that
contains pointers to all PKCS#11 functions (so you need to export/use
just the C_GetFunctionList symbol)
struct CK_FUNCTION_LIST
{
CK_C_Initialize C_Initialize;
CK_C_Finalize C_Finalize;
CK_C_GetInfo C_GetInfo;
...
};
CK_RV C_GetFunctionList(CK_FUNCTION_LIST_PTR_PTR ppFunctionList);
...
All function have cdecl calling convention.
The problem is:
I need to use a linux-native BINARY PKCS#11 library under a WIN32
program should run with Wine.
As specified in the Winelib docs I've created a Winelib wrapper DLL.
Firts try:
I've wrapped just C_GetFunctionList() and I've exported it using a .spec
file.
The wrapped C_GetFunctionList() loads the native-linux lib and calls the
native C_GetFunctionList(). It just returns function pointers structure
to the calling application without doing any fix-up.
But when the WIN32 program calls any function using a function pointer
contained in CK_FUNCTION_LIST, i.e. C_GetInfo(), the function get called
but the WIN32 program crash just after the function returns:
"wine: Unhandled exception (thread 0009), starting debugger..."
Second try:
Looking at winebuild/winemaker/winegcc I've noticed that a PE-like
export table is automatically created using the .spec file as input. I
can't really understand all implementation details, but looks like that
there is also some code that performs calling convetion
conversion/fix-up (of course from c to stdcall, but there is also some
code for win32-cdecl to gcc-cdecl... ?).
So i've tried to use the winelib's LoadLibrary() and GetProcAddress(),
to "load self" and to get function pointers exactly as a Win32
application would do... hoping that this way I would get pointers to
functions "fixed" for "externa-win32" usage...
But I noticed that fucntion pointers returned by GetProcAddress() are
exactly equal to "internal" fucntion pointers.
I suppose that the GetProcAddress() called from within a Winelib DLL is
"smart" enough to return internal pointers isntead of unusable
"win32-external" pointers...
Third try: not yet done
This is a very complicated way; I think that it should works, but I
wondering if ther isn't a simpler way...
Writing a pure-WIN32 library that exports just C_GetFunctionList and
does the CK_FUNCTION_LIST fix-up (lets call this DLL w32-stub)
the Winelib DLL should stub and export ALL PKCS#11 functions, and not
just C_GetFunctionList() (lets call this DLL winelib-wrapper).
So...
The WIN32 app loads the w32-stub.
The w32-stub loads winelib-wrapper (using LoadLibrary) and load all
PKCS#11 function pointers using GetProcAddress(); this should return
WIN32 usable function pointers.
The winelib-wrapper load the linux-native PKCS#11 library (using
dlopen); all exported functions just wrap native functions of the
linux-native library.
I'm looking for ways to install wine on a multi-user box so that
hundreds of users can share the same base registry.
Username substitution would help in the registry processing.
So when a flag is set for installing a global setting, registry keys
written which include the username would instead put something like
$username into the key.
Having an include directory could also be useful so that all the
individual files inside the directory would be included. It would be
usefull to disqualify files ending with a ~ character such as the Emacs
program creates when creating temporary backups of the file you are editing.
So I'm looking to eliminate having seperate (full) fake windows
directories for every user.
Are these concerns already addressed or dealt with in some other way?
-Joe Baker
Hi and greetings from LinuxTag in Karlsruhe!
At our booth we had a visitor who told me that the version of
CrossOver Office that he had been using issued a timely warning
about license expiration few months before finally actually ceasing
to provide service exactly after one year.
This report is rather astonishing to me since I'm not too happy
about software which actually ceases to work after some time,
and I also wouldn't have expected Codeweavers to employ such
questionable policies.
On
http://www.codeweavers.com/products/upgrade_policy/
there is no mention of actually disabling the software after a year,
though. The only thing mentioned here is loss of support after a
year, which is perfectly fine with me. That way you're left with an
unsupported piece of ju^H^Hsoftware, yet may keep running it for centuries.
Given that a denial of service (pun intentional ;) after a year is
not mentioned on this web page, I have some reasons to suspect that this visitor
had some random issue making his installation fail to keep working.
The visitor told me that it may have been a special SuSE CrossOver version
(Wine Rack?). Does that one have specially restrictive terms, maybe?
Thanks for listening, now continuing to provide free quality advertisement for CXO
on LinuxTag ;-),
Andreas Mohr
Uwe Bonnes wrote:
> The real problem however is that the final installer asked
> for the Country version of user.exe. The installer expects 0407
> for Germany. Wine doesn't supply that information, so the installer
> aborts.
There sure enough must be a workaround for this in the T-Online suite. Otherwise
this would mean that you can't run it on a non-German Windows installation and I
would certainly guess that there are several people who run for instance the US
or UK English Windows version for one reason or the other. So what would they
have to do?
Rolf Kalbermatter
> CLSIA
> --
> Eric Pouech
>
Hi Eric,
is there a way you could change the name for your KERNEL_USER_TIMES
variable (kut). I suspect that some proxy-scannners (DansGuardian f.e.)
will trip over this as this a Dutch word for some part of the female body.
I don't know if there's some general 'rule' about these kind of
things/wordings ?
Cheers,
Paul.
"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote:
> Changelog:
> Remove DllMain from the spec file
We need to match native exports, and native advpack.dll really
exports DllMain.
--
Dmitry.
"Felix Nawothnig" <felix.nawothnig(a)t-online.de> wrote:
> --- include/mlang.idl 19 Nov 2004 17:59:41 -0000 1.5
> +++ include/mlang.idl 9 Dec 2004 16:08:02 -0000
> @@ -545,6 +545,8 @@ cpp_quote("STDAPI Rfc1766ToLcidA(LCID *,
> cpp_quote("STDAPI Rfc1766ToLcidW(LCID *, LPCWSTR);")
> cpp_quote("#define Rfc1766ToLcid WINELIB_NAME_AW(Rfc1766ToLcid)")
>
> +cpp_quote("STDAPI GetGlobalFontLinkObject();")
This is not a prototype, you need to list the types of arguments, in this
case (void).
--
Dmitry.
On 6/26/05, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
> ChangeLog:
> Saulius Krasuckas <saulius.krasuckas(a)ieee.org>
> Link to Image Color Management (ICM) Reference instead of
> irrelevant MSCMS Publishing API docs.
>
Hello Saulius,
After status6 is committed you can look over all the MSN/Other doc
links and suggest better linkage if you wish. :-)
I got a little lazy while doing them.. well more like bored out of my
head and did a hurry up job on a couple of them.
Cheers,
Tom
