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

extracting window icons
by Brian Vincent 10 Jun '05

10 Jun '05

Is there a way to extract an icon from a DLL? Wine seems to do this automatically when programs are installed, I just can't figure out how. Is there a way to do it from the commandline? -Brian

3 3

Wine 20050310 redraw problems (specifically with Paint Shop Pro 7)
by Jules Richardson 09 Jun '05

09 Jun '05

I remember posting about this quite a while ago but decided to revisit it, and it seems like it's still an issue in the 20050310 build of wine. Wine has real trouble with refreshing drawing surface windows in Paint Shop Pro 7: - the background in a new image window isn't cleared - tools that display tooltips (such as the colour selector control) leave tooltip debris all over the drawing surface when they're moved around. - drawing surface isn't refreshed if partially / totally obscured by other windows and then made visible again. Normal windows, dialogs etc. are working fine (and tooltips work fine too above normal controls) - it would seem that the drawing surfaces in PSP7 are handled differently (presumably for speed reasons) and wine is having some serious problems handling them. Any ideas for a workaround / patch, or is this bug known about and in the pipeline to be sorted out? I've exhausted various options in the Wine config file to do with display output; the problem seems to be in core code somewhere. I get the following error message at startup as follows: fixme:ole:CoRegisterMessageFilter stub followed by several: err:region:CombineRgn Invalid rgn=(nil) ... the latter used to happen an awful lot in earlier wine builds whilst the app was being used, but note that it's *not* happening with the 20050310 build whilst I try and use the app; only at startup time. (In other words, it's quite possibly not related to the redraw issues at all) Any ideas? PSP7 is so "almost there" that it'd be a shame if it wasn't 100%... Happy to provide further details if someone gives me instructions as to what to look at! cheers Jules

5 20

Work being done at the File Creation Interface of Cabinet.DLL
by Gerold J. Wucherpfennig 08 Jun '05

08 Jun '05

I just want to let you know that I'm working at the FCI functions of CABINET.DLL. I had a look at this a few years ago, but gave up soon. Two weeks ago I made a new attempt and next weekend I should be able I post a patch which implements all FCI functions and will work with spanning cabinets. Real file compression will not be implemented at that point of time as I still have to write missing parts and complete error handling first. This work took me longer than expected so let's see if I can adhere to my schedule. Regards, Gerold

2 2

Re: Wine on Sparc
by Chuck Hall 06 Jun '05

06 Jun '05

> Chuck Hall wrote: >> Well it looks good. I did get a few failures on the patching, but it >> wnet >> through 'make depend' without a problem. >> >> Now I run into the problem in kthread.c: >> sed -e 's,@bindir\@,/usr/local/bin,g' -e >> 's,@dlldir\@,/usr/local/lib/wine,g' -e 's,@PACKAGE_STRING\@,Wine >> 20050524,g' ./wine.man.in >wine.man || (rm -f wine.man && false) >> gcc -c -I. -I. -I../include -I../include -Wall -pipe >> -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o kthread.o >> kthread.c >> kthread.c:322:3: #error You must implement wine_pthread_init_current_teb >> for your platform >> kthread.c:361:3: #error wine_pthread_get_current_teb not defined for >> this >> architecture >> kthread.c: In function `wine_pthread_get_current_teb': >> kthread.c:340: warning: 'ret' might be used uninitialized in this >> function >> *** Error code 1 >> make: Fatal error: Command failed for target `kthread.o' >> Current working directory /tmp/wine-20050524/loader >> *** Error code 1 >> The following command caused the error: >> cd loader && make >> make: Fatal error: Command failed for target `loader' >> >> Guess this is the next problem to work on :) > > Sounds like configure isn't detecting things properly. It should be > detecting '_lwp_create' and '_lwp_self', thus defining HAVE__LWP_CREATE > and HAVE__LWP_SELF (in addition to HAVE_SYS_LWP_H). Check your > config.log to see what's going on. > > I did have problems with this stuff in older versions of wine, and I > actually hacked the configure scripts to use wine-pthread instead of > wine-kthread. I don't recall the exact reasons, but it wine-kthread > seems to be working fine for me now. Started to go through this and found something intresting. lwp.h does exist and is found, so HAVE_SYS_LWP_H is defined. The test for _lwp_create fails. Looking a bit deeper I found that the lwp.h for Solaris 9 is different from the one in Solaris 10 (which is what I am using). Based on this and something I read awhile ago, I belive that Sun is attempting to phase out the lwp stuff on Solaris. It looks like a workaround will need to be created for _lwp_create. I will look into this and see what is the "official" way to write the code now, if any. Also a workaround will need to be made for all other _lwp_* calls that no longer exist. Have Fun! Chuck Hall

3 3

Half Life 2 error -- err:mmio:MMIO_ParseExtA
by J. Grant 06 Jun '05

06 Jun '05

Hello, I am getting this error when trying to run Half Life2 in err:mmio:MMIO_ParseExtA. Could someone tell me if this is a problem in in WINE, or a problem in my setup? Or not an error at all..? Also if there is already a document on setting up Half Life2 could someone direct me to it please, I could not find one already. $ wcmd Invoking /usr/lib/wine/wine.bin wcmd.exe ... WCMD Version 0.17 Z:\home\now3d>cd C:\opt\games\steam\ C:\opt\games\steam>C:\opt\games\steam\Steam.exe -applaunch 220 C:\opt\games\steam>err:dc:CreateDCW no driver found for L"WINEPS" fixme:winspool:AddPrinterW DocumentPropertiesW on printer 'L"deskjet930c"' fails err:dc:CreateDCW no driver found for L"WINEPS" err:dc:CreateDCW no driver found for L"WINEPS" fixme:winspool:AddPrinterW DocumentPropertiesW on printer 'L"hp930c"' fails err:dc:CreateDCW no driver found for L"WINEPS" err:mmio:MMIO_ParseExtA No . in szFileName: "" err:mmio:MMIO_ParseExtA No . in szFileName: "C:\\opt\\games\\steam\\" You need to install the Mozilla ActiveX control to use Wine's builtin CLSID_WebBrowser from SHDOCVW.DLL fixme:ole:CoCreateInstance no instance created for interface {00000000-0000-0000-c000-000000000046} of class {8856f961-340a-11d0-a96b-00c04fd705a2},hres is 0x80040111 fixme:debug_buffer:RtlCreateQueryDebugBuffer (0, 0): stub fixme:debug_buffer:RtlCreateQueryDebugBuffer (96, 0): returning 0x40473b08 fixme:debug_buffer:RtlQueryProcessDebugInformation (11, 80000001, 0x40473b08): stub fixme:debug_buffer:RtlDestroyQueryDebugBuffer (0x40473b08): stub C:\opt\games\steam> C:\opt\games\steam> C:\opt\games\steam>Shutting down. . . 30client callback thread error C:\opt\games\steam>STEAM.exe "steam://open/registerproduct/220" C:\opt\games\steam>err:mmio:MMIO_ParseExtA No . in szFileName: "" err:mmio:MMIO_ParseExtA No . in szFileName: "C:\\opt\\games\\steam\\" fixme:sync:CreateIoCompletionPort (0xffffffff, (nil), 00000000, 00000000): stub. fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x4046b9a0): not verifying image Shutting down. . . 1completionportmanager.cpp (28) : Assertion Failed: m_hIOCP C:\opt\games\steam>exit -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

4 7

Re: ntdll.dll: mark dirlink as REPARSE_POINT
by Dimi Paun 03 Jun '05

03 Jun '05

On Tue, 2005-05-31 at 00:00 +0200, Detlef Riekenberg wrote: > - if (S_ISDIR( st.st_mode ) && !show_dir_symlinks) return NULL; > + if (S_ISDIR( st.st_mode )) > + { > + if (!show_dir_symlinks) > + { > + return NULL; > + }else > + { > + name_is_link = FILE_ATTRIBUTE_REPARSE_POINT; > + } > + } Minor point, but it would be more in the Wine style to code above as: + if (S_ISDIR( st.st_mode )) + { + if (!show_dir_symlinks) return NULL; + name_is_link = FILE_ATTRIBUTE_REPARSE_POINT; + } -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

3 5

Print unicode strings in tests
by Paul Vriens 01 Jun '05

01 Jun '05

Hi, I'd like to print unicode-strings in some tests (for debugging purposes). The following however does not show nice output on wine (it does on windows): static const WCHAR dataW[] = {'S','o','m','e',' ','d','a','t','a',0}; UNICODE_STRING usdata = { sizeof(dataW)-sizeof(WCHAR), sizeof(dataW), (LPWSTR)dataW }; trace("Length is %d\n", usdata.Length); trace("Maximum Length is %d\n", usdata.MaximumLength); trace("The strings is %ls\n", usdata.Buffer); Our trace doesn't seem to be able to cope with %ls (or %S). Any ideas ? Cheers, Paul.

3 2

Re: Optionally map the unix filesystem instead of drive letters into the shell namespace
by Michael Jung 31 May '05

31 May '05

Hi Michael, On Friday 27 May 2005 03:03, Michael Lin wrote: > Just a few things with this approach. > As I mentioned before .. with a global flag in the registry. > User can't run a winelib application with unix path and a Windows > application on Wine with dos path at the same time. Please consider the configure based global flag only an option. That's actually what I said several times. It could be a per application option as well. And there is no problem in activating it via a wine-specific API, which would override the config on a per process basis. > Ok ... I know your approach is base everything on dos path and the > global flag is simply a display mode. > But what about the parsing of the file name editbox in the file dialog? > The user is browsing unix file system, but does the user enter unix or > dos path? > I believe I can modify your solution to accept unix file path, but it > have to accept dos path as well. Modifying shfldr_unixfs to parse unix path in addition to dos paths is trivial: Just remove the (pUnixFolder->m_dwPathMode == PATHMODE_UNIX) test in line 339. The real problem is the test for invalid chars in the filedialog, which '/' is one of. The solution is obvious: If wine is configured to display unix paths, then accept '/' as a valid char in paths in comdlg32. You will have to do this for your solution as well, don't you? > Then there is also the issue of having to have the unix root mapped to a > dos drive. That's true. Actually, we are tackling two slightly different problems here: I would like to have existend applications, for which I don't have the source, to display unix paths instead of dos paths in their file dialogs. So I want MS Office to display unix paths in it's file dialogs. IMHO there is not way to achieve this without the requirement to map one of the dos drives to '/'. At least not if the user should be able to access every file on his filesystem. This solution can also be applied to winelib applications. If you want to use the native posix file functions (which, frankly, I don't see a reason to do, because the user doesn't care how filenames look in the core dump, but only how they look on the screen) then just map the paths coming out of the file dialog to unix with the wine_nt_to_unix_path function. I do understand that there are some shortcomings of this approach for winelib applications, which can not possibly be addressed this way. But it seems equaly obvious to me that your approach can never achieve the goal I laid out above (To make native apps display the unix paths in file dialogs). So perhaps there might be demand for both solutions. Or perhaps I'm totaly off the point and the only person on the planet who likes to see unix paths in his native windows applications on wine. Which would mean your solution might be the only one people are interested in. What I meant to say is, please fell free to implement your solution the way you like it and let the wine community decide on it. But please don't modify shfldr_unixfs in a way that breaks my solution (Conceptually, that is. Bugs, of course, are unavoidable.) > Troy, Alexandre and I have been discussing other possible solutions to > this problem offline. I don't want to offend, but I think this just isn't fair. I have contributed a lot of my free time working on this stuff, and I think I would have deserved to be informed on discussions and decisions in this matter. Above that, this kind of discussion should take place on wine-devel, so that the community at large can take part in it. To me this gives the impression that you avoided discussing it on wine-devel, because you didn't want to be convinced. Sorry. Ok, nuff said, going back to the technological stuff. > One solution I have implemented and waiting on Alexandre's verdict is > the following. > > Create a new library called wineunixfs. All additional entry point > should be in that library. > All exported function call should be of the same signiture as one in the > core library such as GetOpenFileNameA(), GetOpenFileNameW() etc. > To use the library, simply let winelib application link it before all > the other core libraries. > > My Changes to the core libraries are contained within shell32. There is > only one extra exported functions SHUnixFSGetDesktopFolder() being > added. This function return the desktop folder in unix mode. > > Currenlt wineunixfs duplicates filedlg.c, filedlgbrowser.* and their > dependent files from commdlg. > I have attached the diff file for the rest of the changes that's on the > core libraries. I'm not the one to judge, but in my opinion this is pretty heavy weight. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 3

Re: Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs
by Robert Shearman 31 May '05

31 May '05

Evan Deaubl wrote: >ChangeLog: > * Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs > > I cleaned up the patch a little. Does this still work for you? Changelog: Evan Deaubl <wine(a)warpedview.com> Robert Shearman <rob(a)codeweavers.com> - Implement RtlGetControlSecurityDescriptor - Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs -- Rob Shearman

2 1

Borland C++ 4.5
by Andrew Neil Ramage 31 May '05

31 May '05

When I tried to install BC++ 4.5, the installation proceeded normally. However, when I clicked "Finish", it trashed my X server, causing the system to stop responding to key presses and the mouse. I could not even kill the X server, and so had to pull the power cord out. Is this a known problem, and will I still be able to use my Development identity ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

7 9