June 2005 - Wine-devel - list.winehq.org

WileLib: Retrurning function pointers
by Giuseppe AMATO 27 Jun '05

27 Jun '05

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.

2 1

Multi-User Software Installs
by Joe Baker 27 Jun '05

27 Jun '05

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

2 1

CrossOver licensing behaviour?
by Andreas Mohr 27 Jun '05

27 Jun '05

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

3 3

FW: Version Info on user.exe
by Rolf Kalbermatter 27 Jun '05

27 Jun '05

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

1 0

Re: ntdll / kernel32: #58
by Paul Vriens 27 Jun '05

27 Jun '05

> 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.

1 0

Freetype compatibility issue?
by Vikram Kumar 26 Jun '05

26 Jun '05

Hi, I've been trying to get cvs-head to work for the last few days, but freetype is giving me problems. I try to run anything and I get the same libfreetype problem. I've attached the output when I try to run notepad. I've been away from wine for a bit so if anybody can fill me in on this one... I'm running on gentoo, freetype 2.1.9 Cheers Vik $ wine notepad wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7ffad12a). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7ffad12a ESP:7ba3f368 EBP:7f6fc008 EFLAGS:00210202( - 00 - -RI1) EAX:00000000 EBX:7ffeab94 ECX:00000000 EDX:7ffe9ac0 ESI:00000000 EDI:7c0b34dc Stack dump: 0x7ba3f368: 7c00f368 00024cf0 7c01a8bc 7ffeab94 0x7ba3f378: 00000018 7ba3f3d0 00000000 7ba3f3a0 0x7ba3f388: 7c01a8bc 7ffe9ac0 7c0b3918 7c00f368 0x7ba3f398: 0000499e 00000000 7ffad08a 7ffeab94 0x7ba3f3a8: 7c08f490 7ba3f478 00000000 7ff97393 0x7ba3f3b8: 7c01a8a8 00000000 7ba3f3d0 7ff91fd3 Backtrace: =>1 0x7ffad12a in libfreetype.so.6 (+0x2a12a) (0x7f6fc008) 2 0x00000000 (0x00000000) 0x7ffad12a: movzwl 0x0(%eax,%esi,2),%eax Modules: Module Address Debug info Name (44 modules) ELF 0x7b3a1000-7b3c9000 Deferred winspool.drv<elf> \-PE 0x7b3b0000-7b3c9000 \ winspool.drv ELF 0x7b3c9000-7b48a000 Deferred comctl32<elf> \-PE 0x7b3e0000-7b48a000 \ comctl32 ELF 0x7b48a000-7b4aa000 Deferred iphlpapi<elf> \-PE 0x7b490000-7b4aa000 \ iphlpapi ELF 0x7b4aa000-7b4f4000 Deferred rpcrt4<elf> \-PE 0x7b4c0000-7b4f4000 \ rpcrt4 ELF 0x7b4f4000-7b583000 Deferred gdi32<elf> \-PE 0x7b510000-7b583000 \ gdi32 ELF 0x7b583000-7b6b6000 Deferred user32<elf> \-PE 0x7b5a0000-7b6b6000 \ user32 ELF 0x7b6b6000-7b6f8000 Deferred advapi32<elf> \-PE 0x7b6d0000-7b6f8000 \ advapi32 ELF 0x7b6f8000-7b789000 Deferred ole32<elf> \-PE 0x7b710000-7b789000 \ ole32 ELF 0x7b789000-7b7e7000 Deferred shlwapi<elf> \-PE 0x7b7a0000-7b7e7000 \ shlwapi ELF 0x7b7e7000-7b8af000 Deferred shell32<elf> \-PE 0x7b800000-7b8af000 \ shell32 ELF 0x7b8af000-7b940000 Deferred comdlg32<elf> \-PE 0x7b8c0000-7b940000 \ comdlg32 ELF 0x7ba48000-7ba70000 Deferred notepad<elf> \-PE 0x7ba50000-7ba70000 \ notepad ELF 0x7baef000-7bc00000 Deferred kernel32<elf> \-PE 0x7bb20000-7bc00000 \ kernel32 ELF 0x7bd12000-7bd1c000 Deferred libnss_files.so.2 ELF 0x7bd1c000-7bd26000 Deferred libnss_nis.so.2 ELF 0x7bd26000-7bd3b000 Deferred libnsl.so.1 ELF 0x7bd3b000-7bd44000 Deferred libnss_compat.so.2 ELF 0x7bd59000-7bd7b000 Deferred libm.so.6 ELF 0x7bd7b000-7be70000 Deferred libwine_unicode.so.1 ELF 0x7be85000-7bf00000 Deferred ntdll<elf> \-PE 0x7bea0000-7bf00000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7ff18000-7ff38000 Deferred libexpat.so.0 ELF 0x7ff38000-7ff5e000 Deferred libfontconfig.so.1 ELF 0x7ff73000-7ff83000 Deferred libz.so.1 ELF 0x7ff83000-7ffeb000 Export libfreetype.so.6 ELF 0xb7e92000-b7e96000 Deferred libdl.so.2 ELF 0xb7e96000-b7fa8000 Deferred libc.so.6 ELF 0xb7fa8000-b7fba000 Deferred libpthread.so.0 ELF 0xb7fba000-b7fd3000 Deferred libwine.so.1 ELF 0xb7fe9000-b8000000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\windows\system\notepad.exe 00000009 0 <== WineDbg terminated on pid 0x8

1 1

Re: ntdll / kernel32: #57
by Dmitry Timoshkov 26 Jun '05

26 Jun '05

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > --- dlls/ntdll/thread.c 21 Jun 2005 09:57:53 -0000 1.31 > +++ dlls/ntdll/thread.c 26 Jun 2005 08:41:07 -0000 > @@ -593,6 +641,19 @@ > case ThreadTimes: > case ThreadPriority: > case ThreadBasePriority: > + { > + const DWORD *pprio = data; > + if (length != sizeof(DWORD)) return STATUS_INVALID_PARAMETER; > + SERVER_START_REQ( set_thread_info ) > + { > + req->handle = handle; > + req->priority = *pprio; > + req->mask = SET_THREAD_INFO_PRIORITY; > + status = wine_server_call( req ); > + } > + SERVER_END_REQ; > + return status; > + } ThreadTimes case should be moved to the stubbed cases below. -- Dmitry.

1 0

Re: ADVPACK: Remove DllMain from the spec file
by Dmitry Timoshkov 26 Jun '05

26 Jun '05

"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.

1 0

Re: add GetGlobalFontLinkObject in mlang
by Dmitry Timoshkov 26 Jun '05

26 Jun '05

"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.

1 0

Re: lostwages: fix link to ICM documentation
by Tom Wickline 26 Jun '05

26 Jun '05

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

1 0