December 2004 - Wine-Devel - list.winehq.org

Re: Another systray patch

by Mike Hearn

> Mike, > I tried saving the patch in various ways, maybe its me, but it would > appear its corrupted, can u resend as attachment, thanks. That's very strange. That was the first time I have tried sending a patch via the builtin emacs sendmail facility, it would be annoying if that mangles it somehow. I checked the web archive and my own inbox, and the patch *looked* fine. I wonder what is up with it. Still, here it is again as an attachment this time. - Add a new wineshell process, and put system tray handling in there - Rewrite the shell32 systray handling to be out of process - Support the freedesktop.org XEMBED protocol

Dec. 6, 2004

[Regression] "Moved visible region calculation to the server" patch broked apllication

by Paul van Schayck

Hey everyone, Since the 23th of July the main opengl window of this application has been broken. It's not being drawn. You can find the application (MSI installer) here: http://www.meosource.com/firefox/asrc11.zip The patch that broked it can be found here: http://cvs.winehq.org/patch.py?id=12703 The CVS log entry can be found here: http://www.winehq.org/hypermail/wine-cvs/2004/06/0196.html Right after that patch nothing was being drawn. With current cvs checkouts the top menu is vissible again. Kind regards, Paul van Schayck

Dec. 6, 2004

Re: Hang in usr1_handler (ptrace issue?)

by Jesse Allen

On Mon, 06 Dec 2004 18:23:28 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > Hi, > > Lately I've been seeing hangs of this form: > > Backtrace: > =>1 0x4df8e7a2 (0x659ffb54) > 2 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x0, handles=0x0, flags=0x8, timeout=0x659ffd10) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x659ffcf8) > 3 0x5246da88 usr1_handler+0x38(__signal=0xa, __context=0x33) [/source/wine/dlls/ntdll/signal_i386.c:1159] in ntdll (0x659ffd1c) > 4 0x100238a8 (0x65bfc6cc) > 5 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x1, handles=0x65bfc8bc, flags=0x4, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x65bfc870) > 6 0x5246f5df NtWaitForMultipleObjects+0x4b(count=0x1, handles=0x65bfc8bc, wait_all=0x0, alertable=0x0, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:713] in ntdll (0x65bfc898) > 7 0x1894e4b3 WaitForMultipleObjectsEx+0xa3(count=0x1, handles=0x65bfc9f0, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [/source/wine/dlls/kernel/sync.c:180] in kernel32 (0x65bfc9c8) > > in other words, whilst waiting on some server object it was suspended. I > am running the FC3 kernel "2.6.9-1.681_FC3". Is this what the > previously discussed ptrace change would look like? If so I may need to > ask Red Hat to do an errata or something. I saw that in 2.6.10-rc3 > another ptrace change went in, so it may be that it's now fixed. > > thanks -mike > > This may very well be the remaining problem for Warcraft 3. I'll check my log again to see if there is a similarity. If anyone wants this log, I can send it to you -- It's 500 KB.

Dec. 6, 2004

RE: [dx9-16] Basetexture support

by Ann and Jason Edmeades

>The ref-counting in this patch looks a bit suspicious. Does >This->resource.parent point to an object that holds a ref-count on the >IWineD3DBaseTextureImpl object? If so, then that would lead to a >circular ref-count where neither object would be freed. Yes, but I think its ok (there is a minor problem with that patch and the GetParent call, which I'll fix in the next patch if I confirm it). I have had huge problems with the double ref counting (see discussions around earlier patch 12!) but I think I have got it about right now. Basically there is a d3d9 basetexture which contains a ref to the wined3d basetexture (same as index and vertex buffer). When d3d9 is released and reaches 0, it releases the wined3d object. Its set up initially with a ref count of 1 for both COM objects. I cant set the ref count of the d3d9 one up by one for the pointer held in the parent location specifically because of the circular reference issue. If the wined3d specific one is addref'd, then it addref's the parent, and vica versa for release. So to sum up, I believe the current ref counting and this patch to be correct - let me know if there's a problem with it Jason

Dec. 6, 2004

Re: Another systray patch

by Grant Williamson

Mike, I tried saving the patch in various ways, maybe its me, but it would appear its corrupted, can u resend as attachment, thanks. [root(a)trax wine-20041201]# patch -p0 -i /usr/src/redhat/SOURCES/systray-20041206.patch patching file dlls/x11drv/event.c patching file dlls/x11drv/window.c patching file dlls/x11drv/x11drv.h patching file programs/wineshell/Makefile.in patching file programs/wineshell/wineshell.c patching file programs/wineshell/wineshell.h patching file programs/wineshell/systray.c patch: **** malformed patch at line 485:

Dec. 6, 2004

Re: wine/dlls/ntdll directory.c

by Alexandre Julliard

Mike Hearn <mh(a)codeweavers.com> writes: > On Mon, 06 Dec 2004 10:48:16 -0600, Alexandre Julliard wrote: > > Log message: > > Use a direct getdents syscall on Linux to avoid relying on > > implementation details of seekdir/telldir. > > > > Patch: http://cvs.winehq.org/patch.py?id=14699 > > Does this fix the hang on Reiser4 by any chance? Hopefully yes, we'll see... -- Alexandre Julliard julliard(a)winehq.org

Dec. 6, 2004

Re: Turn off Antialiasing for Rendering with Palette - Take 2

by Glenn Wurster

> I think that it should be the ExtTextOut's backend responsibility whether > to use antialiasing or not, taking into account ANTIALIASED_QUALITY and > CLEARTYPE_QUALITY value of the LOGFONT.lfQuality field. Actually, we can not just look at the font for this. The issue is that even though the font may support antialiasing, the display we are writing to may not. The first copy of the patch I had sent put the decision making in X11DRV_ExtTextOut, but Alexandre did not like that. He said "You have to add checks for a palette directly at the places that handle the anti-aliasing (and your palette check is wrong too, you shouldn't peek into the internals of the DC bitmap)." Now, at the lower levels, we don't know what sort of BITMAP we are writing into. Here's the situation in which the problem appears: 1) We have a paletted bit map (offscreen), let's say 8 bits. If X is running in 24 bit colour, then the corresponding bitmap in X is going to be 24 bits. 2) The application writes text to the offscreen bitmap. 3) The application takes the data in the offscreen bitmap and extracts it/copies it to the screen. The problem is step #2. We have font's capable of antialaising, and we have a 24 bit pixmap allocated in X, but the application expects it to be 8 bit. Therefore, there is already code in there to shrink it back down to a paletted pixmap so that the application can deal with it. If the only colour values in the bitmap are colours that the application wrote there directly, then we don't have a problem, since the only colours in the pixmap will be colours already in the palette. If, however, we have used antialiasing, then the story is different. Let's say one pixel line of our font character is ...$*****$... (where the $ pixels are antialaised, * are full on, . are full off). When we write the text to the pixmap, then we are going to get colour values at $ which are not in the palette of the application (they'll be a mixture of the value for . and *). * and . will be, but $ will not. Then, we go back and try and convert it back to a paletted image... The pixels at $ are not in the palette, and so in mapping the algorithm maps them to black... That means if we were doing a character like an I which has a ...$$... along the vertical line, then we just lost that vertical line. Mapping to the closest colour increases the running time of the mapping algorithm past acceptable limits. Therefore, we need to make sure that $ never gets into the pixmap in the first place. How do we do this? Disable antialaising. It's not dependant on the font, it's dependant on what colour depth the application thinks the pixmap is (which is different from the colour depth the pixmap is in X). That's why the patch passes the antialias flag in. Alexandre did not like the checking of the DC BITMAP internals in the X11DRV_ExtTextOut, but it needs to be done somewhere (since even apps that run in 24 bit may allocate a 8 bit BITMAP). I moved the checking of DC into the gdc code, since it fits there, but it results in me having to notify the lower levels of the result (the rest of the patch splits up the cache for the antialiased and non-antialiased glyphs so we don't clobber anything bad in X11DRV). I can send pictures if requested, but I'm not at the computer with my source right now. Again, this check for antialiasing is independant of the font's capabilities (and indeed the font capabilities are checked elsewhere). Further comments, suggestions? I hope I explained the problem clearly enough. Glenn.

Dec. 6, 2004

Re: Providing success stories

by M-Halo

It was in my que to do this type of project awhile back, but I'll gladly hand the reponsibility over to you if it means it will get done faster. Stefan, I have a story or two I will email over to you! :) Thanks! Hiji --- Stefan Munz <stefan.munz(a)itomig.de> wrote: > Am Freitag, 3. Dezember 2004 13:43 schrieben Sie: > > Stefan Munz wrote: > > > In order to push the use of Open Source Software > we plan a project with > > > the "Wirtschaftsf�rderung Region Stuttgart GmbH" > ... to > > > find software producers who pay us for a wine > compatibility test of their > > > software. ... > > > > What's the URL, by the way? Is it > > http://opensource.region-stuttgart.de/ ? > > yes. but you won't find any information on this > project as it is planned but > not really started. > > > > > This project is starting at the moment. I > thought a good idea to give > > > something back to the community is to provide > some success stories i.e. > > > for use on winehq.com. Is this interesting? > > > > Yes. I don't see anything on winehq.com like > that, but > > > http://www.codeweavers.com/site/products/case_studies > > seems to be along the lines you're thinking of, > maybe? > > yes, iI thought of something like those pdfs. > > > > > Try just writing up a first draft of a success > story on > > a web page somewhere, and post a link to > wine-devel > > so we can see what you're thinking of. Then I'm > sure > > getting it onto winehq.org will be easy. > > I can start writing as soon as we start the project > and have first customers. > I just wanted to check out wether this would be > interersting for the wine > project. > > Anyway, thanks for the information Dan. > > Regards, > > Stefan > > > - Dan > > > > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

Dec. 6, 2004

Hang in usr1_handler (ptrace issue?)

by Mike Hearn

Hi, Lately I've been seeing hangs of this form: Backtrace: =>1 0x4df8e7a2 (0x659ffb54) 2 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x0, handles=0x0, flags=0x8, timeout=0x659ffd10) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x659ffcf8) 3 0x5246da88 usr1_handler+0x38(__signal=0xa, __context=0x33) [/source/wine/dlls/ntdll/signal_i386.c:1159] in ntdll (0x659ffd1c) 4 0x100238a8 (0x65bfc6cc) 5 0x5246f507 NTDLL_wait_for_multiple_objects+0x387(count=0x1, handles=0x65bfc8bc, flags=0x4, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:683] in ntdll (0x65bfc870) 6 0x5246f5df NtWaitForMultipleObjects+0x4b(count=0x1, handles=0x65bfc8bc, wait_all=0x0, alertable=0x0, timeout=0x0) [/source/wine/dlls/ntdll/sync.c:713] in ntdll (0x65bfc898) 7 0x1894e4b3 WaitForMultipleObjectsEx+0xa3(count=0x1, handles=0x65bfc9f0, wait_all=0x0, timeout=0xffffffff, alertable=0x0) [/source/wine/dlls/kernel/sync.c:180] in kernel32 (0x65bfc9c8) in other words, whilst waiting on some server object it was suspended. I am running the FC3 kernel "2.6.9-1.681_FC3". Is this what the previously discussed ptrace change would look like? If so I may need to ask Red Hat to do an errata or something. I saw that in 2.6.10-rc3 another ptrace change went in, so it may be that it's now fixed. thanks -mike

Dec. 6, 2004

Re: wine/dlls/ntdll directory.c

by Mike Hearn

On Mon, 06 Dec 2004 10:48:16 -0600, Alexandre Julliard wrote: > Log message: > Use a direct getdents syscall on Linux to avoid relying on > implementation details of seekdir/telldir. > > Patch: http://cvs.winehq.org/patch.py?id=14699 Does this fix the hang on Reiser4 by any chance? thanks -mike

Dec. 6, 2004

Re: Wine failed during HEAP_CreateSystemHeap

by Mike Hearn

On Mon, 06 Dec 2004 17:33:41 +0100, Tobias Grosser wrote: > I tried to change SYSTEM_HEAP_BASE to 0xC0000000 for testing, but this > shows an equal output. You can't change this value, it's a Windows constant. You need to investigate why this address isn't available, the -preloader program should have protected it, and also look in libs/wine/mmap.c for the code which blocks off the upper two gigs. thanks -mike

Dec. 6, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Mike Hearn

On Mon, 2004-12-06 at 17:07 +0100, Alexandre Julliard wrote: > Native file pickers are a completely different issue. What I'm talking > about is the standard shell browser thing, except showing Unix paths > instead of Windows drives, so that it's as transparent as possible to > the app. If the app wants a GTK file picker it has to be changed to > make GTK calls itself. Hmm. For the winecfg use case though we have to pass back a Unix path, as by definition it might not be mapped to a Windows path. I suspect most code that uses the browse folder API converts the PIDL straight into a path that it can use with CreateFileEx and so on so it might break stuff if we invented a new PIDL extension that contained a raw Unix path. > Yes of course, we need to fix more than just the shell file > picker. Some changes to the application code are probably unavoidable > too, but this should be kept to a minimum. But we need something like > that if we want to present Winelib as a credible environment for doing > Linux ports. OK, I agree with that. Still there are stages of porting - simply having it run like it would on regular Wine+EXE is the first stage, then dressing it up to integrate better with Unix is the next, then porting to native (well, free) APIs where possible would be the final stage. > As you noted, the app can modify the dialog with additional controls > etc. which is why we have to use the same API. If you have to change > the whole file selection logic in the app code you might just as well > convert it to GTK or whatever. OK. I'm still not sure exactly what type of API extension is wanted though. From looking at the relevant page on MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/shellcc/platform/shell/reference/structures/browseinfo.asp there could be a new Unix FS shell namespace plugin that is normally hidden (how? i'm not sure the API lets you do that) which you can set as the root and select from there, and then some way to convert a PIDL back into a Unix path. Still, there is the problem that PIDLs are not usable with the file APIs, so the sort of thing winecfg does will be rare. And if you let the user pick any directory it may not be mapped. So maybe when the user selects a path under the root, a drive could be automatically mapped temporarily and the PIDL would be convertible to the newly mapped drive using SHGetPathFromIDList. Still, given that it'd normally be hidden (otherwise you get both the windows and unix view of the FS at once in the file|open dialog box...) this seems like an awful lot of work for the case of specifically written apps like winecfg. I'm not sure it's worth trying to hide the user from the fact that the program uses drive letters under the hood.

Dec. 6, 2004

Wine failed during HEAP_CreateSystemHeap

by Tobias Grosser

Hi, i tried to use the new FreeBSD Wine port und FreeBSD 5.3. And I am able to start wine, but while executing "wine ie6setup.exe" an error during CreateSystemHeap shows up. Unfortunately I am not able to solve this problem by myself, and need some advice how to debug this correct. Here the output, after which wine exits: fixme:file:get_default_drive_device auto detection of DOS devices not supported on this platform fixme:ntdll:NtQueryVolumeInformationFile device info not properly supported on this platform err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not availablefixme:ntdll:NtQueryVolumeInformationFile device info not properly supported on this platform err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not availableerr:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not availableerr:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! I tried to change SYSTEM_HEAP_BASE to 0xC0000000 for testing, but this shows an equal output. If I open wine in gdb I am not able to set a breakpoint at line 96 "if(!(base = MapViewOfFileEx( map, FILE_MAP_ALL_ACCESS, 0, 0, 0, SYSTEM_HEAP_BASE )))" to start debugging. Starting at the beginning of the function throws me into inline assambler and some "valgrind" code, but nothing i can deal with. It would be great to give me some debugging advice. Thanks in advance Tobias

Dec. 6, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Alexandre Julliard

Mike Hearn <mh(a)codeweavers.com> writes: > I don't see how to make this work. Silently replacing the win32 file > pickers with native file pickers (or custom built-for-Unix Wine > pickers) is possible in a few cases but when the app modifies the > dialog with additional controls, we have to use the same UI design as > native. Native file pickers are a completely different issue. What I'm talking about is the standard shell browser thing, except showing Unix paths instead of Windows drives, so that it's as transparent as possible to the app. If the app wants a GTK file picker it has to be changed to make GTK calls itself. > If we don't show Windows paths in the file pickers, I think this could > be even more confusing that currently: programs will display eg > Y:\MyDocument.doc in the titlebar but you will have chosen something > under /home/xyz in the file picker. Yes of course, we need to fix more than just the shell file picker. Some changes to the application code are probably unavoidable too, but this should be kept to a minimum. But we need something like that if we want to present Winelib as a credible environment for doing Linux ports. > Could you describe in more detail how you want this to work please? > Having a new API that reuses as much code as possible while still > presenting a sensible UI seems like the most direct way forward. As you noted, the app can modify the dialog with additional controls etc. which is why we have to use the same API. If you have to change the whole file selection logic in the app code you might just as well convert it to GTK or whatever. -- Alexandre Julliard julliard(a)winehq.org

Dec. 6, 2004

Re: Allow output in winedbg to be redirected to a file

by Jeremy White

Eric Pouech wrote: > Jeremy White a écrit : > >> Changelog: >> Allow > and >> output redirection on winedbg commands to capture >> output to a file. > > again (it's my bad day for Jer), I think we should stick to gdb > commands: see 'set logging' and friends. Hmm. I've never liked the gdb 'set logging' interface, but I see your point. I guess the question for winedbg is whether our goal is pure gdb only, or if we want to be able to add things to the interface. Consider the gdb way: (gdb) set logging overwrite off (gdb) set logging file /tmp/foo (gdb) set logging redirect on (gdb) set logging on Redirecting output to /tmp/foo. (gdb) bt (gdb) set logging off Done logging to /tmp/foo. vs what I proposed: Wine-dbg> bt >>/tmp/foo Further, I feel that the gdb set logging facility is not well conceived; I can get most of that functionality by doing a gdb 2>&1 | tee session.txt and modern xterm scroll back windows give me most of what else I need. Now, I know very little about gdb, so there is quite a good chance that I've missed the obvious and good shortcuts to doing this; if so, I'm nearly recovered from my previous encounters with the clue bat, so wack away. But I would argue that my proposed interface can be seen as a nice, and therefore desirable, extension to normal gdb behavior. I do recognize that my patch is probably fatally flawed; something like that should really be built into the parser, and not hacked into the input code. Thoughts? Jer

Dec. 6, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Mike Hearn

Alexandre Julliard wrote: > I'm afraid so yes. We really don't want to define new APIs for that, > it needs to be integrated properly with the existing code. Ideally a > Winelib app should be able to start using Unix dialogs without code > changes at all. I don't see how to make this work. Silently replacing the win32 file pickers with native file pickers (or custom built-for-Unix Wine pickers) is possible in a few cases but when the app modifies the dialog with additional controls, we have to use the same UI design as native. If we don't show Windows paths in the file pickers, I think this could be even more confusing that currently: programs will display eg Y:\MyDocument.doc in the titlebar but you will have chosen something under /home/xyz in the file picker. If we did a shell extension to simply reflect the Unix heirarchy into the shell namespace, then the map drive dialog that motivated all this would display both currently mapped drives *and* the custom namespace extension, which would allow invalid selections (or at the very least, be quite confusing). It would also imply a large amount of code (IShellFolder implementations etc) to achieve the same effect that introducing a new function has. We could reuse the rather nice GTK+ file pickers, which were recently redesigned and support things like bookmarks and pluggable devices, however that'd make winecfg (and therefore Wine) depend on GTK+ which in the past you objected to. Could you describe in more detail how you want this to work please? Having a new API that reuses as much code as possible while still presenting a sensible UI seems like the most direct way forward. thanks -mike

Dec. 6, 2004

Re: [dx9-16] Basetexture support

by Robert Shearman

Ann and Jason Edmeades wrote: >This patch adds a parent class to the various types of textures > >Changelog > >Add BaseTexture class support, call from d3d9. > >Jason > >Note: This adds a new file, basetexture.c which is also part of the patch > > The ref-counting in this patch looks a bit suspicious. Does This->resource.parent point to an object that holds a ref-count on the IWineD3DBaseTextureImpl object? If so, then that would lead to a circular ref-count where neither object would be freed. Rob

Dec. 6, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Alexandre Julliard

Robert van Herk <robert(a)robertvanherk.nl> writes: > Do you want me to continue on my patch, or are you saying that you > feel that this is not the way to go, so that I would be wasting time > with further polishing it anyway? I'm afraid so yes. We really don't want to define new APIs for that, it needs to be integrated properly with the existing code. Ideally a Winelib app should be able to start using Unix dialogs without code changes at all. -- Alexandre Julliard julliard(a)winehq.org

Dec. 6, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Robert van Herk

Mike Hearn wrote: > Alexandre Julliard wrote: > >> Well, there's an IShellFolder interface, and it should probably be >> doing something with that. In any case it should definitely be more >> integrated into the shell way of doing things, there shouldn't be a >> need for a whole new set of APIs. This needs more thought IMO... > > > I have to disagree. I did try and write a shell extension once - even > with the Delphi wizards helping with the boilerplate it was still some > kind of Buddhist patience-enhancing mental excercise. In the end I > trashed Explorer and had to reinstall Windows. There's a *lot* of work > involved in writing one. Alexandre, Do you want me to continue on my patch, or are you saying that you feel that this is not the way to go, so that I would be wasting time with further polishing it anyway? Robert

Dec. 6, 2004

Re: Turn off Antialiasing for Rendering with Palette - Take 2

by Dmitry Timoshkov

"Glenn Wurster" <glenn(a)electric.ath.cx> wrote: > ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags|ETO_IGNORELANGUAGE, > - lprect,lpReorderedString,count,lpDx,dc->breakExtra); > + lprect,lpReorderedString,count,lpDx,dc->breakExtra,antialias); I think that it should be the ExtTextOut's backend responsibility whether to use antialiasing or not, taking into account ANTIALIASED_QUALITY and CLEARTYPE_QUALITY value of the LOGFONT.lfQuality field. -- Dmitry.

Dec. 6, 2004

needing some help...

by MyComputer Store

Hey... I am just getting into this whole wine thing and I have already run into a problem. I am working on switching my Media Matrix servers over to linux, but the software that I need to run is still windows based. Here is the link to the software. http://mm.peavey.com/downloads/mware335.exe when I try to run this file with wine (20041201) it locks up before the installer has finished loading... any advise?? Caleb Miller

Dec. 6, 2004

Re: mdi.c/MDI_ChildActivate query

by Jeremy White

Works nicely; thank you (and my schools chess club, soon to have a tourney, thanks you <grin>). Cheers, Jeremy Dmitry Timoshkov wrote: > "Jeremy White" <jwhite(a)codeweavers.com> wrote: > > >>When trying to run 'Swiss Perfect' (www.swissperfect.com, >>free download available), the app crashes and burns while >>processing a WM_MDIACTIVATE message when the prevWnd is 0. > > > This is due to a long standing hack in X11DRV_ShowWindow which > forces MDI child activation. > > Attached patch adds a couple of new MDI message tests using existing > message sequences for ordinary child windows and confirms that > ShowWindow does the same job for MDI children in respect to activation. > > This fixes a crash in Swiss Perfect. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > ShowWindow activates only a being maximized child window, > add a couple of message tests for MDI child activation. >

Dec. 6, 2004

Re: Wine Bug Busters @ 7pm GMT

by Diego 'Flameeyes' Pettenò

On Monday 06 December 2004 12:56, Shachar Shemesh wrote: > Damn, had to miss it. Any impressions from the event? IRC logs? I was there mainly to log the discussion :) [I've no time to put on wine at the moment, but I hope to have more in the future] http://flameeyes.web.ctonet.it/WineBugBusters.log Here there's the log, until uhm now :) sorry if it's a little bit overflowed. Regards, -- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/

Dec. 6, 2004

Re: Genrate stdole32.tlb file, and install generated files

by Huw D M Davies

On Sat, Dec 04, 2004 at 01:38:59PM -0500, Vincent Béron wrote: > stdole32-generator.c file from Huw. > Invocation from wineprefixcreate from me. > > Changelog: > Automatically create c:\windows\system\stdole32.tlb. > > Vincent The native version of stdole32.tlb is actually a resource only dll that contains the typelib itself as TYPELIB resource #1. I think we probably want to do likewise. Huw. -- Huw Davies huw(a)codeweavers.com

Dec. 6, 2004

Re: Wine Bug Busters @ 7pm GMT

by Shachar Shemesh

Mike Hearn wrote: >Likewise, if you're wanting to get into Wine hacking but aren't sure where >to start, or started but got stuck, or just have questions to ask those >who already climbed the learning curve then this is a great chance. > >You don't have to be a developer, feel free to come and watch even if >you're just interested in seeing how it's done. > > > Damn, had to miss it. Any impressions from the event? IRC logs? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 6, 2004

Re: Kernel 2.6.10... and amd64

by Jose Alberto Reguero

The log is: wine: Unhandled exception (thread 0009), starting debugger... wine: Unhandled exception (thread 000b), starting debugger... wine: Unhandled exception (thread 000d), starting debugger... wine: Unhandled exception (thread 000f), starting debugger... ........ El Viernes, 3 de Diciembre de 2004 09:35, Jose Alberto Reguero escribió: > I read in the list that ptrace break wine in this kernels, and find a patch > for this, but the patch is only for i386 kernels. > There is a patch for amd64 kernels? > Thanks. > > El Jueves, 2 de Diciembre de 2004 18:50, Jose Alberto Reguero escribió: > > I can't use wine with kernels 2.6.10-rc2.... > > With kernel 2.6.9 it works. > > My system is an amd64 linux. > > Thanks. > > Jose Alberto

Dec. 6, 2004

IME question

by Ivan Leo Puoti

According to MSDN, windows creates an IME window and an input context for every thread, should wine do the same? Ivan. ____________________________________________________________ Libero ADSL: 3 mesi gratis e navighi a 1.2 Mega, senza costi di attivazione. Abbonati subito su http://www.libero.it

Dec. 5, 2004

Re: Implemented CreateAsyncBindCtx

by Jacek Caban

Mike Hearn wrote: >On Fri, 03 Dec 2004 23:01:36 -0500, Jacek Caban wrote: > > >>+ hres = IBindCtx_RegisterObjectParam(bctx, (LPOLESTR)BSCBHolder, (IUnknown*)callback); >>+ >>+ *pbind = bctx; >>+ >>+ return S_OK; >> } >> >> > >You don't do anything with hres here, is that intentional? Can >RegisterObjectParam fail? > >thanks -mike > > > It's my tiny bug. RegsterObjectParam can fail only with E_OUTOFMEMORY here, so checking it's return is really not important, but to be correct at all, hres should be just returned. Thanks, Jacek

Dec. 5, 2004

mdi.c/MDI_ChildActivate query

by Jeremy White

Hi, When trying to run 'Swiss Perfect' (www.swissperfect.com, free download available), the app crashes and burns while processing a WM_MDIACTIVATE message when the prevWnd is 0. If I modify the code as in the attached patch, everything works. I can't determine if the app is flawed or if this is a good change to Wine; I'm hoping an MDI expert can kibitz. Cheers, Jeremy

Dec. 5, 2004

Re: Wine Bug Busters @ 7pm GMT

by Mike Hearn

Likewise, if you're wanting to get into Wine hacking but aren't sure where to start, or started but got stuck, or just have questions to ask those who already climbed the learning curve then this is a great chance. You don't have to be a developer, feel free to come and watch even if you're just interested in seeing how it's done. On Sun, 05 Dec 2004 11:09:07 -0700, Brian Vincent wrote: > The first ever Wine Bug Busters hacking session is coming up in an > hour - 7pm GMT or 2pm EST for you North American folks. A few people > are already sitting in irc. If you want to join, fire up your > favorite IRC and log into irc.freenode.net, channel #winehackers. > > -Brian

Dec. 5, 2004

Re: Providing success stories

by Stefan Munz

Am Freitag, 3. Dezember 2004 13:43 schrieben Sie: > Stefan Munz wrote: > > In order to push the use of Open Source Software we plan a project with > > the "Wirtschaftsförderung Region Stuttgart GmbH" ... to > > find software producers who pay us for a wine compatibility test of their > > software. ... > > What's the URL, by the way? Is it > http://opensource.region-stuttgart.de/ ? yes. but you won't find any information on this project as it is planned but not really started. > > > This project is starting at the moment. I thought a good idea to give > > something back to the community is to provide some success stories i.e. > > for use on winehq.com. Is this interesting? > > Yes. I don't see anything on winehq.com like that, but > http://www.codeweavers.com/site/products/case_studies > seems to be along the lines you're thinking of, maybe? yes, iI thought of something like those pdfs. > > Try just writing up a first draft of a success story on > a web page somewhere, and post a link to wine-devel > so we can see what you're thinking of. Then I'm sure > getting it onto winehq.org will be easy. I can start writing as soon as we start the project and have first customers. I just wanted to check out wether this would be interersting for the wine project. Anyway, thanks for the information Dan. Regards, Stefan > - Dan

Dec. 5, 2004

Re: Wrapper for Winelib

by Mike Hearn

It's not that easy, that approach doesn't take C++ static constructors into account, nor the address space manipulation that takes effect. It is possible to allow people to start winelib apps like "./foo" but hardly a big deal. You need to have a program which does: (pseudocode) int main(int argc, char *argv[]) { self = readlink("/proc/self/exe"); exec("wine " + self, argc, argv); } "main()" may already be taken, so you might need to intercept stuff at the ELF bootstrap level. thanks -mike

Dec. 5, 2004

Wine Bug Busters @ 7pm GMT

by Brian Vincent

The first ever Wine Bug Busters hacking session is coming up in an hour - 7pm GMT or 2pm EST for you North American folks. A few people are already sitting in irc. If you want to join, fire up your favorite IRC and log into irc.freenode.net, channel #winehackers. -Brian

Dec. 5, 2004

Re: msvcrt: set mode bits in _fstati64

by Juan Lang

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Looks better, except that according to MSDN "_S_IFREG bit is set if path > specifies > an ordinary file or a device", so you need to add a check for > FILE_TYPE_DISK. Interestingly, you can't _open the root directory of a drive in Windows; it fails with ENOENT. You also can't _open a directory; it fails with ENOACCES. The _S_IFDIR flag never appears to be set, even if you get a handle to a directory. The attached test program shows the following output under WinXP: file c: flags: couldn't open, errno is 14 file c:\ flags: couldn't open, errno is 2 file c:\boot.ini flags: _S_IFREG file c:\windows flags: couldn't open, errno is 13 directory c: flags: _S_IFREG directory c:\ flags: _S_IFREG directory c:\windows flags: _S_IFREG read pipe flags: _S_IFIFO write pipe flags: _S_IFIFO I wasn't really interested in getting this 100% correct; the st_mode set before was always 0, so it can't be that critical. Mostly I was tired of fixme's when running MinGW's gcc.exe under wine. So, I'll resubmit a modified patch that isn't entirely correct but is a little closer, anyway :) --Juan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo #include <errno.h> #include <fcntl.h> #include <stdint.h> #include <stdio.h> #include <sys/stat.h> #include <windows.h> static int firstFlag = 1; static printFlag(const char *flag) { if (!firstFlag) printf("| "); printf(flag); firstFlag = 0; } static void getFDMode(int fd) { struct _stat st; firstFlag = 1; if (_fstat(fd, &st) == 0) { if (st.st_mode & _S_IFCHR) printFlag("_S_IFCHR"); if (st.st_mode & _S_IFREG) printFlag("_S_IFREG"); if (st.st_mode & _S_IFDIR) printFlag("_S_IFDIR"); if (st.st_mode & _S_IFIFO) printFlag("_S_IFIFO"); } putchar('\n'); } static void getFileMode(const char *file) { int fd = _open(file, _O_RDWR, _S_IREAD | _S_IWRITE); printf("file %s flags: ", file); if (fd == -1) fd = _open(file, _O_RDONLY, _S_IREAD); if (fd != -1) { getFDMode(fd); _close(fd); } else printf("couldn't open, errno is %d\n", errno); } static void getPipeMode(void) { int fds[2]; if (_pipe(fds, 256, O_BINARY) == 0) { printf("read pipe flags: "); getFDMode(fds[0]); printf("write pipe flags: "); getFDMode(fds[1]); _close(fds[0]); _close(fds[1]); } } static void getDirectoryMode(const char *directory) { HANDLE h = CreateFileA(directory, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL); printf("directory %s flags: ", directory); if (h != INVALID_HANDLE_VALUE) { int fd = _open_osfhandle((intptr_t)h, _O_RDONLY); if (fd != -1) { getFDMode(fd); _close(fd); } CloseHandle(h); } else printf("failed with GetLastError() = %ld\n", GetLastError()); } int main(void) { /* expect errno is 13 (EACCES), can't open a device */ getFileMode("c:"); /* expect errno is 2 (ENOENT), can't open a drive */ getFileMode("c:\\"); getFileMode("c:\\boot.ini"); /* expect errno is 13 (EACCES), can't open a directory */ getFileMode("c:\\windows"); getDirectoryMode("c:"); getDirectoryMode("c:\\"); getDirectoryMode("c:\\windows"); getPipeMode(); }

Dec. 5, 2004

Re: questions dlls/d3d8/shader.c

by Christian Costa

Eric Pouech wrote: > while toying with Intel compiler on Wine source, I came across a > couple of interesting stuff. > > To whom it may concern. > > in dlls/d3d8/shader.c: > vshader_m4x3 (and vsharer_m3x4) don't use correctly row & columns > with respect to the matrice definition. I let the D3D folks decide > whether the matrix definition, or the implementation is to blame The definition seems wrong indeed. > > IDirect3DVertexShaderImpl_ExecuteSW: you miss one in size of > p_send (and likely p) You're right. I will send a patch for that... A+ Christian

Dec. 5, 2004

Re: Mirroring support take 1

by Juan Lang

This doesn't look right: @@ -2071,6 +2077,7 @@ WIN_ReleasePtr( wndPtr ); return retval; } + break; /* fall through */ If the break is missing, why does the comment say fall through? I think it was intentional. If the break should be there, please remove the comment as well. --Juan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

Dec. 5, 2004

Wrapper for Winelib

by Sam Lauber

I *think* I've figured out a way to make regular Unix programs with winelib. My idea is, make winemaker generate a C file called "winelib-wrap.c" that contains: #include <stddef.h> int main(void) { return (int) WinMain(NULL, NULL, NULL, NULL); } Then link it with the EXE encapusulated in a .so, and it SHOULD work. I'll try it on the 01-stdole32.c. It gave me a SIGSEGV, but maybe someone would fix it. Samuel Lauber -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

Dec. 5, 2004

Re: Janitorial: WinMM conversion of 32 bit low level drivers to Unicode interface

by Eric Pouech

Eric Pouech a écrit : > This patch is based on work by Filip Navara from ReactOS. > He did the Winmm part (+wave & midi mapper), I did the rest (+ 16 > message mapping) > A+ well, another take (I forgot a couple of places...) I also removed the SB related code. What's missing it's the proper registry settings when a device is chosen, and we'd better do it either in winecfg or wine.inf, but not in the drivers themselves A+

Dec. 5, 2004

questions dlls/d3d8/shader.c

by Eric Pouech

while toying with Intel compiler on Wine source, I came across a couple of interesting stuff. To whom it may concern. in dlls/d3d8/shader.c: vshader_m4x3 (and vsharer_m3x4) don't use correctly row & columns with respect to the matrice definition. I let the D3D folks decide whether the matrix definition, or the implementation is to blame IDirect3DVertexShaderImpl_ExecuteSW: you miss one in size of p_send (and likely p) in windows/sys_params.c SystemParametersInfoW, for the case SPI_GETLOWPOWERACTIVE, this index is out of the bounds of spi_loaded in dlls/shell32/shlview.c ShellView_OnNotify, case LVN_BEGINDRAG and LVN_BEGINRDRAG, the dwEffect value is not initialized before calling DoDragDrop !!! A+

Dec. 5, 2004

Re: Problem to draw a bitmap

by Rémi Assailly

Dmitry Timoshkov wrote : >>>/* Make the window visible on the screen */ >>> ShowWindow (hwnd, nFunsterStil); >>> >>> > >Insert UpdateWindow(hwnd); here. > > > >>>PrintBmp(hwnd, "BOARD.bmp"); >>> Thanks, it works. Now I can work ! Rémi

Dec. 5, 2004

Re: msvcrt: set mode bits in _fstati64

by Dmitry Timoshkov

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > Got it. How's this? > + dw = GetFileType(hand); > + buf->st_mode = S_IREAD; > + if (!(hfi.dwFileAttributes & FILE_ATTRIBUTE_READONLY)) > + buf->st_mode |= S_IWRITE; > + if (hfi.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) > + buf->st_mode |= S_IFDIR; > + else if (dw == FILE_TYPE_CHAR) > + buf->st_mode |= S_IFCHR; > + else > + buf->st_mode |= S_IFREG; > + TRACE(":dwFileAttributes = 0x%lx, mode set to 0x%x\n",hfi.dwFileAttributes, > + buf->st_mode); Looks better, except that according to MSDN "_S_IFREG bit is set if path specifies an ordinary file or a device", so you need to add a check for FILE_TYPE_DISK. And FILE_TYPE_PIPE perhaps should have _S_IFIFO set. Not sure if it's worth to write a test case for it. -- Dmitry.

Dec. 5, 2004

Re: Allow output in winedbg to be redirected to a file

by Eric Pouech

Jeremy White a écrit : > Changelog: > Allow > and >> output redirection on winedbg commands to capture > output to a file. again (it's my bad day for Jer), I think we should stick to gdb commands: see 'set logging' and friends. A+

Dec. 5, 2004

Re: RFC: Use editline in winedbg

by Eric Pouech

Jeremy White a écrit : > Hi folks, > > The attached patch dynamically detects and uses the BSD licensed editline > library (a pretty close replacement for readline), if it's available. > This gives winedbg command line recall. > > This gets around readline's license requirements. > > I'm nervous because I wasn't sure if that was the only issue with readline, > or if there were further issues. Wack me with a clue bat > if this is wrong, otw, I'll submit it. there's a full readline support in dlls/kernel32, and there's no reason, I repeat NO REASON, to put dedicated readline support in winedbg. dlls/kernel32 is the only place for readline/editline however you call it. regarding consoles, there are two things you can do: 1/ run winedbg in a powerful wine console: wineconsole winedbg <bla bla> 2/ add, in dlls/kernel32, support for editline/readline when std in/out are not attached to a wine console (which is was 1/ does), but to regular files (you have to detect when those files are tty:s and react accordingly to ReadFile/WriteFile calls) A+

Dec. 5, 2004

Re: msvcrt: set mode bits in _fstati64

by Juan Lang

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Apparently a returned info should be based on whether a file handle > resembles an ordinary disk based file, or pipe, or device, or something > else. But that's a target for a separate patch. Got it. How's this? --Juan __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

Dec. 5, 2004

Re: msvcrt: set mode bits in _fstati64

by Dmitry Timoshkov

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > > What you probably need to consider is a type of a file passed in. > > Hm? Not sure what you mean here. Apparently a returned info should be based on whether a file handle resembles an ordinary disk based file, or pipe, or device, or something else. But that's a target for a separate patch. -- Dmitry.

Dec. 5, 2004

Re: msvcrt: set mode bits in _fstati64

by Juan Lang

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Why do you take into account (FILE_ATTRIBUTE_HIDDEN | > FILE_ATTRIBUTE_SYSTEM) > at all? They have nothing to do with an ability to read/write files. You're right. I didn't do any tests, it was just my poor memory. > What you probably need to consider is a type of a file passed in. Hm? Not sure what you mean here. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

Dec. 5, 2004

Re: Janitorial: WinMM conversion of 32 bit low level drivers to Unicode interface

by Steven Edwards

--- Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: > This patch is based on work by Filip Navara from ReactOS. > He did the Winmm part (+wave & midi mapper), I did the rest (+ 16 message mapping) > A+ Eric I just want you to know you are my personal hero. Someday they will write songs about you that I will listen to under ReactOS <g>. Thanks Steven __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

Dec. 5, 2004

Re: Fix for winedbg; disassemble range was flawed

by Jeremy White

This updated version prevents an infinite loop in the (currently impossible) case of a poorly specified disassembly range. Truth is, this functions interface is a bit awkward. Jeremy White wrote: > Changelog: > Properly respect a disassemble x,y command > (prior behavior would do y-x instructions, no matter > how wide each instruction was) > > > ------------------------------------------------------------------------ > > Index: programs/winedbg/debugger.h > =================================================================== > RCS file: /cvstrees/crossover/office/wine/programs/winedbg/debugger.h,v > retrieving revision 1.17 > diff -u -r1.17 debugger.h > --- programs/winedbg/debugger.h 28 Nov 2004 16:23:50 -0000 1.17 > +++ programs/winedbg/debugger.h 5 Dec 2004 04:30:24 -0000 > @@ -317,7 +317,7 @@ > extern BOOL memory_get_current_frame(ADDRESS* address); > extern BOOL memory_get_string(HANDLE hp, void* addr, BOOL in_debuggee, BOOL unicode, char* buffer, int size); > extern BOOL memory_get_string_indirect(HANDLE hp, void* addr, BOOL unicode, char* buffer, int size); > -extern void memory_disassemble(const struct dbg_lvalue*, const struct dbg_lvalue*, int offset); > +extern void memory_disassemble(const struct dbg_lvalue*, const struct dbg_lvalue*, int instruction_count); > extern BOOL memory_disasm_one_insn(ADDRESS* addr); > extern void print_bare_address(const ADDRESS* addr); > extern void print_address(const ADDRESS* addr, BOOLEAN with_line); > Index: programs/winedbg/memory.c > =================================================================== > RCS file: /cvstrees/crossover/office/wine/programs/winedbg/memory.c,v > retrieving revision 1.1.1.13 > diff -u -r1.1.1.13 memory.c > --- programs/winedbg/memory.c 28 Nov 2004 15:36:39 -0000 1.1.1.13 > +++ programs/winedbg/memory.c 5 Dec 2004 04:30:24 -0000 > @@ -598,9 +598,11 @@ > } > > void memory_disassemble(const struct dbg_lvalue* xstart, > - const struct dbg_lvalue* xend, int offset) > + const struct dbg_lvalue* xend, int instruction_count) > { > static ADDRESS last = {0,0,0}; > + int stop = 0; > + int i; > > if (!xstart && !xend) > { > @@ -613,7 +615,10 @@ > last.Mode = AddrModeFlat; > last.Offset = types_extract_as_integer(xstart); > } > - if (xend) offset = types_extract_as_integer(xend) - last.Offset + 1; > + if (xend) > + stop = types_extract_as_integer(xend); > } > - while (offset-- > 0 && memory_disasm_one_insn(&last)); > + for (i = 0; (instruction_count == 0 || i < instruction_count) && > + (stop == 0 || last.Offset <= stop); i++) > + memory_disasm_one_insn(&last); > }

Dec. 4, 2004

Re: RFC: Use editline in winedbg

by Jeremy White

Robert Shearman wrote: > Jeremy White wrote: > >> Hi folks, >> >> The attached patch dynamically detects and uses the BSD licensed editline >> library (a pretty close replacement for readline), if it's available. >> This gives winedbg command line recall. > > > > I think this should be available via Win32 calls without the licensing > issues. See dlls/kernel/editline.c > I'm not sure if winedbg is currently supposed to support it and there is > a bug, or if it just hasn't enabled the feature, or if it is even able > to use it. Ouch. Clue bats hurt; I think I've just walked into a tar pit, haven't I? Now I seem to recall battles over winedbg and how consoles work. Sadly, I can't remember all of the gory details (hence, the need for the clue bat). With the attached patch, winedbg --console starts a Win32 style console for it's session, and indeed, the Win32 console editing stuff works out just fine. But I can't resize the window and don't have a scroll bar. But there is an alternate and/or better way to do this, isn't there? I set WINECONSOLE or something, right? More clues would be welcome. Cheers, Jeremy

Dec. 4, 2004

Re: msvcrt: set mode bits in _fstati64

by Dmitry Timoshkov

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > + buf->st_mode = S_IFREG; > + if (!(hfi.dwFileAttributes & (FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM))) > + { > + buf->st_mode |= S_IREAD; > + if (!(hfi.dwFileAttributes & FILE_ATTRIBUTE_READONLY)) > + buf->st_mode |= S_IWRITE; > + } Why do you take into account (FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM) at all? They have nothing to do with an ability to read/write files. What you probably need to consider is a type of a file passed in. -- Dmitry.

Dec. 4, 2004