- Wine-Devel - list.winehq.org

Re: msi: prevent locking the cd
by Alexandre Julliard June 27, 2005

June 27, 2005

Aric Stewart <aric(a)codeweavers.com> writes: > Copy the msi file to a temp file to prevent locking a CD during an > install. This allows multi disc installs to eject the first volume. This fails make test: fixme:msi:MSI_OpenDatabaseW open failed r = 80030050! format.c:84: Test failed: Failed to open package format.c:102: Test failed: Failed to close package fixme:msi:MSI_OpenDatabaseW open failed r = 80030050! format.c:84: Test failed: Failed to open package format.c:668: Test failed: size wrong(16) etc... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-03.diff]
by Alexandre Julliard June 27, 2005

June 27, 2005

"Gerold J. Wucherpfennig" <gjwucherpfennig(a)gmx.net> writes: > +static cab_ULONG fci_set_little_endian_ulong( cab_ULONG i ) { > + unsigned char v[4]; > + v[0]=i; > + v[1]=i>>8; > + v[2]=i>>16; > + v[3]=i>>24; > + return *((cab_ULONG*)(v)); > +} > + > +static cab_ULONG fci_get_little_endian_ulong( cab_ULONG i ) { > + unsigned char v[4]; > + cab_ULONG r=0; > + memcpy(v,&i,4); > + r|=v[3]; > + r<<=8; > + r|=v[2]; > + r<<=8; > + r|=v[1]; > + r<<=8; > + r|=v[0]; > + return r; > +} You should use the Rtl*ByteSwap functions with the appropriate #ifdef WORDS_BIGENDIAN, it would be a lot more efficient, particularly on little endian platforms that represent 99.9% of the real world cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Battlefield 1942 Regression
by Stefan Dösinger June 27, 2005

June 27, 2005

Hello, The patch http://cvs.winehq.org/patch.py?id=18375 from 2005/06/22 13:30:30 breaks Battlefield to a certain extend. Battlefield used to have major texture problems(Units partially not visible, wrong colors sometimes) which went away approximately 2 Weeks ago. Now they came back with this patch. It seems to me that this patch fixes some functionality which was broken 2 weeks ago and which causes the problems and the root cause is somewhere else. Can someone give me a hint/documentation links what might be wrong here? Is it worth trying Oliviers DirectX patches? It looks to me that he's just committing them to CVS. Stefan Dösinger

2 2

Where to map the unixfs extension
by Michael Jung June 27, 2005

June 27, 2005

Hi, What if we map the unixfs extension on the desktop instead of on mycomputer? So if HKCR\Software\Microsoft\Windows\Current Version\Explorer\Desktop\Namespace\{UnixDosFolderCLSID} is present, the desktop folder would forward ParseDisplayName calls to UnixDosFolder instead of MyComputer. We could de-activate the special case of enumerating all child's of MyComputer in the file dialogs iff unixfs is rooted at the desktop. This way we wouldn't have to introduce a second "MyUnixComputer" and the user could expand MyComputer, if he forgot where there C: drive is mapped. But he would'nt see the drives until he does so. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: dlls/commdlg/printdlg.c : Now works PageSetupDlgA function
by Michael Stefaniuc June 27, 2005

June 27, 2005

Hi, you may want to recheck your patch as it contains lots of cvs update conflicts. tft(a)office.etersoft.ru wrote: > It's too big patch, but break it to many parts very hard. > > ChangeLog: > Complex PageSetupDlg patch > [Snip] > +<<<<<<< printdlg.c ^^^^^^^^^^^^^^^^^^^^^ cvs update conflict > +/*********************************************************************** > + * DefaultPaintHook > + Default hook paint procedure that receives WM_PSD_* messages from the dialog box > + whenever the sample page is redrawn. > +*/ > + [Snip] bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Move Notification Window (aka systray) To A Separate Process
by Robert Shearman June 27, 2005

June 27, 2005

Robert Shearman wrote: > Changelog: > Move notification window (aka systray) to a separate process. Sorry, this changelog should be as follows instead: Mike Hearn <mh(a)codeweavers.com> Robert Shearman <rob(a)codeweavers.com> Move notification window (aka systray) to a separate process. -- Rob Shearman

1 0

WileLib: Retrurning function pointers
by Giuseppe AMATO June 27, 2005

June 27, 2005

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 June 27, 2005

June 27, 2005

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 June 27, 2005

June 27, 2005

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 June 27, 2005

June 27, 2005

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