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

Re: Regression
by Ivan Leo Murray-Smith April 8, 2004

April 8, 2004

> Tried to install on an updated (like 45 min old) CVS version to test it, > seems to get in an endless loop here. Alexandre committed a fix http://www.winehq.com/hypermail/wine-cvs/2004/04/0095.html Everything seems OK again, and hopefully will stay so. Ivan.

2 1

Re: Regression
by Ivan Leo Murray-Smith April 8, 2004

April 8, 2004

> Tried to install on an updated (like 45 min old) CVS version to test it, > seems to get in an endless loop here. You're wright, it loops :( Ivan.

1 0

Re: Re: inheriting exec-shield avoidance
by chmorgan＠charter.net April 8, 2004

April 8, 2004

Any idea when the kernel and wine changes will be going in? Then we can start asking people with Fedora to disable exec-shield and prelinking OR upgrade to kernel 2.6.X and the latest wine. There are people everyday that come onto #winehq with problems due to prelinking/exec-shield. Thanks, Chris > > From: "Dimitrie O. Paun" <dimi(a)intelliware.ca> > Date: 2004/04/08 Thu PM 03:10:35 EDT > To: Mike McCormack <mike(a)codeweavers.com> > CC: Peter Riocreux <par+wine_devel(a)silistix.com>, <wine-devel(a)winehq.org> > Subject: Re: inheriting exec-shield avoidance > > On Thu, 8 Apr 2004, Mike McCormack wrote: > > > I've attached the source code. The idea is to run it like this: > > > > wld /home/mike/wine/loader/wine-pthread my.exe > > Cool. One small nit: for consistency, can we name it wineld instead? > Or is it winepreld more apropriate? I'm thinking that wineld will > seem to be the counterpart of winegcc... > > -- > Dimi. > > > >

1 0

RE: Status of TAPI
by Robert van Herk April 8, 2004

April 8, 2004

> This (dutch..) site provides some TAPI patches for Wine that are not > in CVS: > http://home.wanadoo.nl/wijn/girotel/ > > Since I'm dutch, I'd thought I'd explain a bit on what this site says. Wijn is dutch for wine by the way . The site explains how to patch wine in order to be able to use girotel software. Girotel is a telebanking system using dail up by modem that was quite popular a few years ago. Anyway, now-a-days most people use Internet for telebanking, not dail up modem. Although the site for that specific bank is not mozilla compatible , it can be used from Konqueror. The patches seems to be specially suited in order to use this Girotel system. Greetings, Robert

1 0

Status of TAPI
by Andreas Rosenberg April 8, 2004

April 8, 2004

Hi guys! I'd like to run a TAPI based application in Wine (updated from CVS today). I extracted the vendor specific TAPI driver and the registry keys and included both into a Wine setup. Then I tried to do setup the TAPI driver using the telephon.cpl (taken from Win98): wine rundll32.exe shell32.dll,Control_RunDLL telephon.cpl first I had a problem with the Wine implementation of the TAPI32.DLL. err:module:import_dll No implementation for TAPI32.dll.internalConfig imported from L"C:\\windows\\system\\telephon.cpl", setting to 0xdeadbeef ... No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TELEPHON.CPL' (0x75a70000) Unhandled exception: page fault on read access to 0xdeadbeef in 32-bit code (0x404c5b7e). who had dug in that DEAD BEEF? ;-) Then I took the TAPI32.DLL from a Win98 installation. This gave me another error: fixme:ole:RpcServerRegisterAuthInfoA ((null),10,(nil),(nil)): stub fixme:seh:EXC_RtlRaiseException call to unimplemented function rpcrt4.dll.NdrClientCall (last message repeated several times). At last I took the rpcrt4.dll from a Windows98 installation and tried it again. Then it took quite a time (~15 sec) until the Wine debugger came up. wine rundll32.exe shell32.dll,Control_RunDLL telephon.cpl wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 8 Can't find file for ELF 'wine-kthread' ((nil)) Loaded debug information from ELF 'wine-pthread' ((nil)) Breakpoint 1 at 0x4000dd60 (_end+0x3fefb8d0) Loaded debug information from ELF '/usr/local/lib/libwine.so.1' (0x40028000) No debug information in ELF '/lib/i686/libpthread.so.0' (0x40040000) No debug information in ELF '/lib/i686/libc.so.6' (0x40091000) No debug information in ELF '/lib/libdl.so.2' (0x401c4000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' (0x401c8000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' (0x40238000) No debug information in ELF '/lib/i686/libm.so.6' (0x4032b000) Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' (0x40460000) Loaded debug information from ELF '/usr/local/lib/wine/rundll32.exe.so' (0x405a2000) Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' (0x406c0000) Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x407f8000) Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' (0x40878000) No debug information in ELF '/usr/lib/libfreetype.so.6' (0x408b7000) No debug information in ELF '/usr/lib/libfontconfig.so.1' (0x4090d000) No debug information in ELF '/usr/lib/libexpat.so.0' (0x40935000) Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40955000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x4001c000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x409d3000) No debug information in ELF '/usr/X11R6/lib/libXrandr.so.2' (0x405b6000) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x409ea000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x409f2000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40a00000) No debug information in ELF '/usr/lib/tls/libGL.so' (0x40afc000) No debug information in ELF '/usr/lib/tls/libGLcore.so.1' (0x40b67000) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x410e4000) Unsupported debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x40025000) Unsupported debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x41131000) No debug information in ELF '/usr/lib/gconv/ISO8859-1.so' (0x408a9000) Loaded debug information from ELF '/usr/local/lib/wine/imm32.dll.so' (0x41150000) Loaded debug information from ELF '/usr/local/lib/wine/shell32.dll.so' (0x4116e000) Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' (0x411f6000) Loaded debug information from ELF '/usr/local/lib/wine/shlwapi.dll.so' (0x4126a000) Loaded debug information from ELF '/usr/local/lib/wine/comctl32.dll.so' (0x412c1000) No debug information in 32bit DLL 'C:\windows\system\rundll32.exe' (0x405b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x401e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40490000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40890000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40810000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40970000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IMM32.DLL' (0x41160000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x7fb90000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x41210000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x41280000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x412d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x41190000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSVCRT.DLL' (0x78000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TAPI32.DLL' (0x7f960000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TELEPHON.CPL' (0x75a70000) Unhandled exception: page fault on read access to 0xda62061d in 32-bit code (0x401f999a). In 32-bit mode. 0x401f999a (RtlpWaitForCriticalSection+0x6a [critsection.c:204] in NTDLL.DLL): movl 0x1c(%eax),%eax 204 if ((!crit->DebugInfo) || (!crit->DebugInfo->Spare[1])) continue; The wait time could be an indication that a timeout happened. Anybody has a clue what could be the problem? Regards Andy

4 5

Re: MSYS's sh.exe has trouble reading from stdin on Wine?
by Pouech Eric DMI AEI CAEN April 8, 2004

April 8, 2004

> wine --debugmsg +all -- sh.exe - does wineconsole -- sh.exe - work ? I fear it's the same old pb of not mapping win32 console semantics on standard unix files without winconsole (anyway, check for the CreateFile which returns 0xffffffff, likely on $CONIN) A+

1 0

MSYS's sh.exe has trouble reading from stdin on Wine?
by Dan Kegel April 8, 2004

April 8, 2004

Someone's having trouble building my crosstool on msys, so I tried installing msys on my Wine (a home-built 20040213). (This is slightly less crazy than installing Cygwin, I think, but it's still a pretty hard test, I bet.) The installer http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download ran just fine until it tried to run the postinstall shell script. Turns out running msys's sh.exe hangs. Running it with wine --debugmsg +all -- sh.exe - and waiting until the output settles into an infinite repeat, I see the repeating section is 0009:Call kernel32.WaitForSingleObject(00000084,0000000a) ret=7105f927 0009: select( flags=12, cookie=0x4060eea8, timeout=1081401202.858741 (+0.009956), handles={0x84} ) 0009: select() = PENDING 0009: *wakeup* signaled=258 cookie=0x4060eea8 0009:Ret kernel32.WaitForSingleObject() retval=00000102 ret=7105f927 0009:Call ntdll.RtlEnterCriticalSection(710a8b0c) ret=71070c98 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=71070c98 0009:Call ntdll.RtlLeaveCriticalSection(710a8b0c) ret=71070cb0 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=71070cb0 0009:Call kernel32.PeekConsoleInputA(ffffffff,4060f150,00000001,4060f12c) ret=7105687a 0009: read_console_input( handle=0xffffffff, flush=0 ) 0009: read_console_input() = OBJECT_TYPE_MISMATCH { read=-1, rec={} } 0009:Ret kernel32.PeekConsoleInputA() retval=00000000 ret=7105687a 0009:Call ntdll.RtlEnterCriticalSection(710a8b0c) ret=71070c98 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=71070c98 0009:Call ntdll.RtlLeaveCriticalSection(710a8b0c) ret=71070cb0 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=71070cb0 0009:Call kernel32.WaitForSingleObject(00000084,0000000a) ret=7105f927 So it kind of looks like it's having trouble reading from stdin? Can someone have a look? It'd be so awesome to be able to run msys on Wine... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: abnt2 keyboard
by Dmitry Timoshkov April 7, 2004

April 7, 2004

"Rafael аvila de EspМndola" <rafael.espindola(a)ic.unicamp.br> wrote: > The attached patch fixes the problem that wine has with the abnt2 (Brazilian) > keyboard. The problem was recently discussed in wine-devel. If you still can't provide more arguments as on wine-devel I don't see a reason why the patch can be accepted. Especially taking into account that the patch contains magic numbers without a little bit of explanation what they are. > While reading dlls/x11drv/keyboard.c I notice that wine does a linear search > to convert a virtKey to a keycode. Could this be optimized/simplified by > pre-computing a vkey2keyc[(e->state & NumLockMask)!=0] table? Feel free to send a patch. -- Dmitry.

1 0

[Fwd: DSD_CreateSecondaryBuffer]
by Robert Reif April 7, 2004

April 7, 2004

sorry, wrong reply button again.

1 0

DSD_CreateSecondaryBuffer
by Daniel Skorka April 7, 2004

April 7, 2004

Hi, said function is a stub in Wine-20040309. Is anyone working on implementing it? If not, any pointers on doing so, especially on how this fuction differs from DSD_CreatePrimaryBuffer? Thanks, Daniel Skorka

1 0

Regression
by Ivan Leo Murray-Smith April 7, 2004

April 7, 2004

This patch http://www.winehq.com/hypermail/wine-cvs/2004/03/0434.html breaks the decompression system used by lots of microsoft software, a screenshot is attached. This breaks the installer of the word 97 viewer, and probably of all office viewers, and it may affect dcom and the installer of other Windows components or Microsoft software. This should be fixed before the next release. The CVS regression testing was done with the word viewer available at http://www.microsoft.com/downloads/details.aspx?FamilyID=9bbb9e60-e4f3-436d… Ivan.

2 1

Re: Documentation: Clarified need for conformance tests.
by Francois Gouget April 7, 2004

April 7, 2004

On Wed, 7 Apr 2004, Michael Jacobsen wrote: > Hi there. This is my first go at submitting a patch. Let's see if it works. It needs a small s/avalible/available/ and it would be nice to follow the 2-space indentation used in the rest of the doc. Besides that it looks good. Thanks for your contribution. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

article
by Pouech Eric DMI AEI CAEN April 7, 2004

April 7, 2004

read on from lwn.net http://www-106.ibm.com/developerworks/linux/library/l-wine/?ca=dgr-lnxw04Fi…

1 0

Virus on wine-patches@winehq.org
by Rolf Kalbermatter April 7, 2004

April 7, 2004

Could someone please remove the following postings from the archive as they contain viruses? http://www.winehq.org/hypermail/wine-patches/2004/04/0082.html http://www.winehq.org/hypermail/wine-patches/2004/04/0084.html Rolf Kalbermatter

3 2

Re: development speed
by Ivan Leo Murray-Smith April 7, 2004

April 7, 2004

> The website stats are interesting too: Are these available somewhere? Ivan.

2 1

arch tip #1
by Mike Hearn April 7, 2004

April 7, 2004

At Dimis request, I've added a new script to the root of the gateway tree. The genpatch program takes a series of patch ids as parameters and can generate and send an email to wine-patches with the combined diff of all the given commits. For example: let's say you are working on a feature. You do 3 commits, to keep the changes physically separate, however you decide the commits are too fine grained to submit all at once, so you want to submit them together. Genpatch makes that easy. Say you commit patch-4, patch-5 and patch-6: ./genpatch -m 4 5 6 will compute the combined differential of all those commits, take the commit log and summary of the first and generate an email from them. The patch will include and new files that were added. Have fun! thanks -mike

1 0

Re: wine/ include/config.h.in dlls/x11drv/xrandr.c ...
by Mike Hearn April 7, 2004

April 7, 2004

On Tue, 06 Apr 2004 22:57:36 -0500, Alexandre Julliard wrote: > Log message: > Mike McCormack <mike(a)codeweavers.com> > Load the XRandR extension dynamically (with help from Alex Pasadyn). Are we sure this is a good idea? Dynamic version of the X extension libraries are not available on every distro, as traditionally XFree has shipped them statically. I'm not even sure they have stable interfaces. It seems wiser to just statically link libXrandr, seeing that it's only 7.7k

1 0

Window management thoughts
by Mike Hearn April 7, 2004

April 7, 2004

So, me and Mike have been discussing some ideas for window management in Wine. Currently it hasn't turned into code, but I thought I'd write up what our thoughts were so others could comment and maybe be inspired to write patches. The problem: Currently Wine decides whether to make a window managed or not based on a series of heuristics, in is_window_toplevel in dlls/x11drv/window.c Unfortunately these heuristics are frequently wrong, as they have only limited information to work with (window styles, mostly). In CrossOver, is_window_toplevel is easily the most hacked function in the entire codebase. This manifests itself in a variety of ways: * Windows are marked unmanaged when they shouldn't be. For instance, see WinAmp, Trillian, the Counter-Strike CD Key screen etc: there are tons of examples of this problem. This at best means the window is "nailed" to the screen, at worst it makes the program unusable. * The classic "my game starts but I can't type" problem where keyboard input goes to the terminal instead of the window, due to the lack of focus management in unmanaged windows. * Some programs display splash screens and then pop up errors or question dialogs underneath them. Unmanaged windows are always-on-top -> you cannot get to the underlying managed window and the app appears to hang. * Fullscreen windows are really hard to do properly because they must be managed to work correctly in KDE/GNOME. We currently make certain windows unmanaged typically because we need to control their position or rendering with a high degree of accuracy. Unfortunately some X window managers ignore positioning hints, even when we ask them not to. There is no way to make things like menus and tooltips work correctly with these WMs, so we take the window out of the usual window management mechanism entirely. Unfortunately due to the design of the win32 API there is no simple way to tell the difference between a large menu and the Trillian main window. We could mark our own menus specially to make them unmanaged and have everything else be managed, but we then run into problems with programs that draw their own menus and tooltips, of which there are a truly shocking number. So what is a possible solution? Well, one way forward is to implement another mode, in which Wine makes all windows managed and uses a variety of WM hints to get the desired behaviour. For instance, the PPosition flag asks the WM to place the window where the application requests it to. Some WMs respect this, others do not, in yet others it's a toggleable option. For people with WMs that meet the requirements of Wine all windows could be made managed, and for people that don't use such WMs the old way can still be used. IIRC it's possible to ask the WM for identification which means this setting could be largely autodetected by having blacklists of WMs to use the old mode for (or vice-versa). Unfortunately there's no way to know how well this approach would work, or even if it would work at all, short of trying it. thanks -mike

5 6

Re: Re: wineserver: correctly free the debug ctx
by Pouech Eric DMI AEI CAEN April 7, 2004

April 7, 2004

> It seems to me this will cause the context to never be freed. I don't > understand the problem with multiple processes, the context is bound > to the debugger thread so it shouldn't make any difference how many > processes are being debugged. Could you please give more details on > the problem? well, problem (sigsev in wineserver) happened when quitting windbg after debugging several processes. I'll try to reproduce it over this weekend. A+

1 0

Re: Game support
by James Perry April 7, 2004

April 7, 2004

Sorry, meant to send this to the list first time around... >> But I narrowed it down to 3 Wine calls in the >> critical loop: SetEvent, WaitForSingleObject and ResetEvent. >> I tried wrapping each of these functions with >> __asm__("pushfl\n"); at the start and __asm__("popfl\n"); at >> the end to preserve the flags - with this, PECrypt works >> fine and the game gets as far as trying to initialise >> DirectX. Not exactly a neat fix though. > > > Did you have to do all of them, or is it just one function that needs this > treatment? SetEvent definitely needs it. The others possibly don't. But I think it would be more robust to preserve the flag through all of them anyway, in case someone makes a change in future that causes one of the others to clear the direction flag too, which seems quite possible. > Are you sure it's not that we need to set the flag before > jumping to the entrypoint? The flag is normally cleared. PECrypt sets it explicitly, then expects it to remain set across those three API calls. > PECrypt sounds like it should run very early on > in the programs lifetime: how much stuff does it do before hitting this > bug? AFAIK, PECrypt just decrypts and decompresses the executable at startup, then it goes away and the program runs as normal. This bug does happen very early on. > If there is really widespread software that depends on > this behaviour though there is precedent for including a hack for it - see > the DllMain wrapper which preserves %ebx for an example. Certainly anything compressed with PECrypt will depend on the flag being preserved. In general I'd imagine it's quite rare for programs to run with the direction flag set for long periods though. Cheers, James

1 0

ole32.dll_CoRegisterPSClsid
by Paul Ortyl April 6, 2004

April 6, 2004

Hi, If only ole32.dll.CoRegisterPSClsid() is implemented (empty stub returning '1' is enough) then the application "GeoGeogrid® for Windows©" starts and allows at least some basic operations. (tested with "Baden-Würtemberg AMTLICHE TOPOGRAPHISHE KARTEN" Top50, Version 4) For more info on GeoGrid you may look at: http://swpat.ffii.org/patents/effects/geogrid/index.en.html http://www.eads.net/frame/lang/en/xml/content/OF00000000400004/4/20/534204.… Basically all official topographical maps in Germany are available only through this proprietary application. It would be really useful if ole32.dll.CoRegisterPSClsid() could be implemented in (next) release... TIA Paul Ortyl -- Don't take life too seriously; you will never get out of it alive. -- Elbert Hubbard

1 0

AbiWord on ReactOS
by Steven Edwards April 6, 2004

April 6, 2004

Note there are still a few minor bugs but for the most part it seems we have a real application working on ReactOS. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

Re: WININET: move to Windows sockets
by Juan Lang April 6, 2004

April 6, 2004

> Geoff wrote: > > Or we write our own BIO that wraps up whatever > > glue is desirable on the wine-side. Worst-case > > (and it's not that bad an alternative) is that > > you use a memory-base BIO to encapsulate all I/O > > and worry about moving data to and from "sockets", > > whatever they look like, afterwards. > > That's what I've always done. <snip> > So it's not a bad way to go at all. Yep, in fact the "real" way to do this as far as Wine is concerned is to implement SSL in secur32.dll, since this is where Windows does it. It looks about like this, although as Geoff pointed out to me the API is a bit broken. Doing a BIO inside wininet.dll might be more expedient for Hans, who I think is trying to get as much of Wine as possible ported to MinGW. You guys that know SSL better than I do: patches welcome :) --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

Re: Game support
by Ivan Leo Murray-Smith April 6, 2004

April 6, 2004

> btw, are there already any automated tools for parsing Wine logs? There is the examine-relay perl script in the tools directory, but it's only for relay traces. Ivan.

1 0

Re: development speed
by Brian Vincent April 6, 2004

April 6, 2004

> Check that out - 5mb of patches for the last 3 months running. A meg of > patches just 6 days into the new month already! > > It seems Wine is moving faster than ever before. The website stats are interesting too: Daily Avg | Monthly Totals Hits Pages Visits| Sites KBytes Visits Pages Files Hits Mar 2004 267733 75495 16582 |268931 157346721 514060 2340347 7064537 8299737 Feb 2004 278180 79217 17199 |279399 203400907 498774 2297305 6994822 8067232 Jan 2004 135477 44930 8341 |154109 90054340 258586 1392848 3591136 4199791 Dec 2003 213993 71246 14408 |243882 138401056 446653 2208643 5725553 6633804 Nov 2003 244427 85277 15766 |254363 153748583 472983 2558310 6268477 7332826 Oct 2003 275663 111913 17352 |260400 161803798 537913 3469326 7430846 8545582 Sep 2003 156860 50508 10393 |173365 93441224 311790 1515269 4048260 4705814 Aug 2003 209530 69084 12812 |218040 124270932 397177 2141613 5612004 6495449 Jul 2003 243646 105136 12253 |197296 123038700 379853 3259216 6704428 7553047 Jun 2003 253998 109167 12250 |160468 91985851 306270 2729185 5642823 6349961 May 2003 262218 111683 13764 |207954 105320483 399181 3238809 6336486 7604349 Skipping to the KBytes and Hits columns, things are up. Even more interesting is in Feburary we got Slashdotted and in March we didn't. So it appears people are interested. Generally things begin to taper off as we approach summer. Last year we got some good PR by doing an interview series, so I'm planning on doing that again. Anyone know what happened on October 5th and 6th that generated so many hits? -Brian

1 0

Compiling Wine with BiDi support - instructions
by Shachar Shemesh April 6, 2004

April 6, 2004

Hi list, Here are the formal instructions for compiling Wine with bidi support. When doing so, it is recommended that you use a fairly recent version of ICU (2.6 and up), or else there is going to be a runtime soft dependancy on some ICU files in the resulting Wine. No big deal - if these files are not there, Wine will work just fine, only without BiDi support. Still, this is not necessary. Instructions: 1. If you use a precompiled package (relatvely rare for ICU, unfortunatly), make sure it has the static libraries as well. ICU does not have these by default. If they are there, you may skip to step 8. Please note, however, that this will add about 7MB to the size of the resulting gdi.dll.so. 2. Grab ICU from the web http://oss.software.ibm.com/icu. 3. Extract the sources file. 4. CD into the ICU directory, and then into the "source" subdirectory. 5. Delete all files with the "mk" extension under icu/source/data. e.g. run "find data -name \*.mk -exec rm \{\} \;". Please trust me on this one, it's ok to do it. This step saves the aforementioned 7MB. 6. ./runConfigureICU LinuxRedHat --enable-static. If you are only building this for use with Wine, you can also add "--enable-shared=no --enable-64bit-libs=no --prefix=~/icuinstall". If not, you may wish to skip the previous step as well. 7. run "make" and "make install". Grab a lunch. Just one will do. 8. If your ICU library files are installed in /usr/lib and /usr/include, compile wine as usual. If they are installed anywhere else, you will need to set the "ICU_LIB_DIR" environment variable to wherever it was that they are installed. You will also have to add the include path. For example, if you compiled and installed icu according to my example above, you will need to set ICU_LIB_DIR to "~/icuinstall/lib", and also CPPFLAGS to "-I~/icuinstall/include". 9. Make sure that including "ubidi.h" and the following linking step passes in "configure". Also check whether include/config.h has "HAVE_ICU" set. 10. To be really sure that your wine supports BiDi, run the program given in this email. A few things to note: * The above assumes that your Wine already has http://www.winehq.org/hypermail/wine-patches/2004/04/0088.html integrated. * If you are compiling Wine on Debian, and want to use the Debian supplied ICU library for whatever reason (for example - because the packaging system pretty much requires you to), the above procedure needs to be slightly altered. ICU changed their static library naming scheme over some recent version. The Debian packaged ICU (2.1) still uses the old scheme. Either use Wine without the aforementioned patch, or set ICUUC_LIB and ICUDATA_LIB to the full path to libicuuc.a and libicudata.a respectively (they are called "libsicuuc.a" and "libsicudata.a" in newer version of ICU). Please note that this means there is a runtime dependancy on some ICU files for BiDi to work, as explained above. Instead of reposting the program for testing whether Win32 supports reordering, the link to the file in the list's archive is at http://www.winehq.org/hypermail/wine-devel/2003/08/att-0175/01-biditest.c. Enjoy -- Shachar Shemesh Lingnu OpenSource Consulting http://www.lingnu.com/

1 0

Re: Dos INT15
by Dmitry Timoshkov April 6, 2004

April 6, 2004

"Florian Goth" <Captainsifff(a)gmx.de> wrote: > Added some more stubs after examining the dosbox source code Could you please try to stick to the formatting style used in the file in your changes? -- Dmitry.

1 0

development speed
by Mike Hearn April 6, 2004

April 6, 2004

Hey guys, http://www.winehq.org/hypermail/wine-patches/ Check that out - 5mb of patches for the last 3 months running. A meg of patches just 6 days into the new month already! It seems Wine is moving faster than ever before. To put things in perspective, the Wine source tree is 10mb - that means in only 2 months as many lines of patch were generated as exists in Wine itself! thanks -mike

2 2

Re: WININET: move to Windows sockets
by Dan Kegel April 6, 2004

April 6, 2004

Geoff wrote: > Or we write our own BIO that wraps up whatever glue is desirable on the > wine-side. Worst-case (and it's not that bad an alternative) is that you > use a memory-base BIO to encapsulate all I/O and worry about moving data > to and from "sockets", whatever they look like, afterwards. That's what I've always done. And it seems I've managed (via the rant at http://kegel.com/ssl/api.html) to convince Sun to make that the standard way to do ssl with NIO under the next JDK, kinda. So it's not a bad way to go at all. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

DDraw issues, etc.
by Tim Hentenaar April 6, 2004

April 6, 2004

Hi all, I've implemented SetClipList and GetClipList in the DirectDraw Clipper, and I'm wondering how I should go about implementing clipping in DirectDraw's Blt() (if it isn't already done somewhere). M$'s documentation isn't too great, so I figured I should ask around. There's a game one of my relatives wants to run under Linux (it's a children's program), and the major problem is that it dosen't seem to handle clipping properly when blitting. (e.g. every time you move the mouse, it calls SetClipList). FYI, the binkw32.dll that came with the program was originally causing it to hang, but I patched the DLL and it works fine. If anyone else has had such problems, I could provide a patch. Also, I'm going to take a look at some of the DirectSound stuff too. The sound isn't very good quality for some reason, but under the WineX 3.3 CVS, sound works perfectly. Tim

3 11

Re: WININET: move to Windows sockets
by Juan Lang April 5, 2004

April 5, 2004

Hans wrote: > On Monday 05 April 2004 19:24, Alexandre Julliard > wrote: > > There's no real reason that we cannot use Unix > > sockets on Unix and Windows socket on Reactos with > > the same code, it just needs a bit of header magic; > > and this will be useful for Winelib apps too. > > Hmm, I'd like to agree with that. I'd be rather nervous about the mixing of OpenSSL with the use of Winsock, at least as is. OpenSSL is itself using socket read/write calls, and it expects them to be the correct ones: in particular, the UNIX ones. I believe the only way to do this correctly is to write a new OpenSSL BIO that uses the same read/write/open/close calls as the rest of netconnection.c, and this can be combined with the aforementioned header magic to get what you're after. Copying and pasting an existing OpenSSL BIO would probably suffice. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

Re: wineserver: correctly free the debug ctx
by Alexandre Julliard April 5, 2004

April 5, 2004

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > when a debugging thread is attached to several processes, the debug > context (shared across all processes) is destroyed when the first > process terminates. This patch destroys it when the last process > attached terminates. It seems to me this will cause the context to never be freed. I don't understand the problem with multiple processes, the context is bound to the debugger thread so it shouldn't make any difference how many processes are being debugged. Could you please give more details on the problem? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WININET: move to Windows sockets
by Steven Edwards April 5, 2004

April 5, 2004

Hello Hans, --- Hans Leidekker <hans(a)it.vu.nl> wrote: > > This makes wininet build on MinGW. > > Changelog: > Move to Windows sockets. > I asked Alexandre about a patch to move Wininet to Winsock and he said it took to much of a performance hit to merge. Is there a way we can bench mark it to show how much of a hit Winsock vs Unix sockets is going to give us? He suggested that we find a way to make Wininet use Unix sockets on Unix and Winsock on Windows. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

6 7

CryptoAPI
by unknown＠example.com April 5, 2004

April 5, 2004

Has anybody started implementing CryptoApi in WINE?? If no mayby someone can give me some clues how to start... I am not bad i C++ I think, but I have never make thing like that. I don't promise I will do that, but I can try... :)

3 2

Re: CryptoAPI
by Juan Lang April 5, 2004

April 5, 2004

Jacek wrote: > Has anybody started implementing CryptoApi in WINE?? > If no mayby someone can give me some clues how to > start... I am not bad i C++ I think, but I > have never make thing like that. I don't promise I > will do that, but I can try... :) Hi Jacek, take a look at Wine's rsabase.dll, that DLL doesn't do very much yet. All its functions (CPAcquireContext, etc) are described here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/s… If you have access to a Windows box it's easier: you can load the DLL itself and call all the functions and try to reproduce what it's doing. Good luck, --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

Re: Fwd: Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net April 5, 2004

April 5, 2004

Quoting hatky <hatky(a)hatky.myz.info>: >> No, no, no... read the patch again. > Ok, sorry wasn't what I tought you are trying to do, this patch is ok > p.s. I didn't think someone actually changed the urls in bugzilla. sweet :). I have been going through them 100 at a time. I've got 1-400 done at this time. I figure I will be done sometime before Christmas :P. If anyone wants to help with this I would be glad to have the help... Check out http://bugs.winehq.org/show_bug.cgi?id=560 for more more on this. -- Tony Lambregts

1 0

NtPulseEvent
by Robert Lunnon April 5, 2004

April 5, 2004

What is the status of NtPulseEvent it emits a diagnostic messages fixme:ntdll:NtPulseEvent (7c,0) yet it looks to me that NtPulseEvent is implemented but the fixme is bogus Anyone know about this ? BTW Has anyone experience with the Skype application under linux, does it work there ? Bob b

2 1

Should winemaker be able to handle this
by Bill Medland April 5, 2004

April 5, 2004

I haven't been following the winemaker stuff so I don't know whether it is supposed to be able to handle this (and is broken) or not. I am having to play with the "build a builtin dll to wrap a linux so" concept again after a year or so since the last time, as discussed in the Winlib manual, chapter 5. I see that winemaker has changed since then. In particular the bit that is not working for my case is the -D, -I, -L and -l options. What I want is to run winemaker to generate the build environment and then do the build. What I used toi have was: #! /bin/bash # Run this script in order to pass the correct arguments to winemaker so that # it can set up the build environment winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

4 5

RE: Handling dialogs created without using templates
by Santosh Siddheshwar April 5, 2004

April 5, 2004

Hi, Thanks. Would you be able to share details of the changes you did for handling MDI windows? Regards Santosh > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry(a)baikal.ru] > Sent: Tuesday, March 30, 2004 7:40 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialogs created without using templates > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Yes attached is a sample which is pretty similar to what I described > > below. > > Thanks. Now I see where the problem is. We have to hook dialog creation > code into common window creation code, something similar to what I've done > recently for MDI. Alexandre, are my thoughts correct? > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: Re: dbghelp
by Pouech Eric DMI AEI CAEN April 5, 2004

April 5, 2004

> UnDecorateName is still a stub, while our winedump has some a good > framework for UnDecorateName, also translating into a GCC way and not in a > VC++ way. How should these things go together? See the comment in dbghelp.c !! My first thouhgt would be to make a .a lib out of winedump code, and use it in winedump and msvcrt and / or dbghelp. I haven't studied yet the best way to share the code between msvcrt and dbghelp A+

1 0

Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net April 4, 2004

April 4, 2004

Quoting hatky <hatky(a)hatky.myz.info>: > > On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#" > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts

2 1

Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net April 4, 2004

April 4, 2004

Quoting hatky <hatky(a)hatky.myz.info>: > > On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#" > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts

1 0

Re: dbghelp
by Uwe Bonnes April 4, 2004

April 4, 2004

>>>>> "Eric" == Eric Pouech <pouech-eric(a)wanadoo.fr> writes: Eric> Eric Pouech a écrit : >> This is a first (and incomplete) shot at implementing the dbghelp >> DLL. Eric> forgot to say that: - this patch must be applied before the ones Eric> on imagehlp & taskmgr - code is highly derivated from winedbg Eric> current code Eric> I'm also working on a winedbg version based on this DLL, but it Eric> isn't ready yet (as dbghelp seems to get a bit more mature, I Eric> thought some people might be interested in testing it) UnDecorateName is still a stub, while our winedump has some a good framework for UnDecorateName, also translating into a GCC way and not in a VC++ way. How should these things go together? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Personal tree with interesting patches
by Mike Hearn April 4, 2004

April 4, 2004

Hi, As I'm pretty busy right now and won't have time to work on the various misc projects I've been working on up until recently for the foreseeable future, I'm checking them into my personal arch archive for people to play with and maybe work on themselves. My archive co-ordinates: http://navi.cx/~mike/archive/2004 mike(a)navi.cx--2004 so, you'd use: $ tla register-archive http://navi.cx/~mike/archive/2004 There are currently only two interesting branches: wine--mainline--0.9: misc patches that were never applied for whatever reason, debug delay, lockwindowupdate (disabled), that sort of thing as i find more patches around my system i'll check them in for safekeeping wine--loadarea-reserve--0.9 execshield/prelink work, see the log message in patch-1 for details on what remains to be done Have fun! thanks -mike

2 2

installation program
by Brian Vincent (C) April 4, 2004

April 4, 2004

On the To Do List (c.4) is an item for having a new graphical Wine install program. Anyone ever looked at Frank Hendrickson's WineTools program? http://franksworld.net/winetools.html It used to be written in some funky language, now it's all shell script. Anyway, if you look at the script (wt210) you'll notice he uses xdialog ( http://thgodef.nerim.net/xdialog/ ) for the GUI. So here's what I'm wondering.. How feasible would it be for Wine to create a new Winelib program (say, wdialog) and use a similar concept as Frank? wdialog would simply replicate the functionality of xdialog. We could potentially fail gracefully into shell mode if Wine can't start. It might be a cheap and simple way to get a GUI front-end. Of course, all this requires sane defaults so Wine can actually run wdialog. Any thoughts? --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Re: appdb - improvement in serching out bugs
by hatky April 4, 2004

April 4, 2004

On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > The current code can get bugs that have nothing to do with the AppDB. This > should fix it. > > -- > > Tony Lambregts I think this is wrong, you are saying the url in bugzilla should be exactly "appdb #" where it should realy be "http://bugs.winehq,org/show_bug.cgi?id=#" -- Hatky, Worshiper of wine (http://www.winehq.org/) Impossible is only an opinion.

1 0

Microsoft SDK samples
by Jonathan Wilson April 3, 2004

April 3, 2004

Has anyone given thought to using the Microsoft SDK samples (e.g. DirectX samples) to improve WINE? i.e. take a particular sample and work away at it untill what you get in WINE matches what you get in Windows. Although I suspect that there are things that the MS samples dont cover :)

2 1

Re: Documentation for GDI Region Functions
by Alexandre Julliard April 3, 2004

April 3, 2004

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > and renamed the variables to Microsoft conventions. Please don't do that. The variable names don't matter at all for compatibility, so we don't have to follow the brain-damaged Microsoft conventions for them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Developer's path to Windows/*NIX multi-platform?
by Dimitrie O. Paun April 3, 2004

April 3, 2004

You ask: > I am willing to re-write my best Windows software from scratch, but I > insist that the result is native or almost on Linux so there are not any > weird GUI glitches. Do you think Wine is the way to go for me, or am I > better off writing individual versions and keeping the Windows software > native and then producing QT or GTK versions for *NIX? I'm at a cross-roads > here, since I'll be dedicating years of work in whatever direction I take. IMO Wine is the perfect tool for you. We know, it's not perfect. But the best use of your time (and the most efficient) would be to: 1. Fix any problems in your apps (like reliance on strange Windows corner cases, use of very obscure features) 2. Help out fix Wine so that your apps run properly. This will not only help us a lot, but it will help you make good use of your time, and it will allow you to do cross platform development (even for Windows) from your Linux box. Please direct questions to wine-devel(a)winehq.org, where people can help you out. -- Dimi.

7 9

W95INF32 implementation, incase it's useful to anybody
by Mike McCormack April 2, 2004

April 2, 2004

Hi All, In the process of understanding another bug, I did a little work to implement w95inf32, which appears to be a small IE/win9x only DLL and which is probably of not much use to Wine. It appears to be a think wrapper 32bit around 4 functions in SETUPX. So this is just for documentation purposes, and incase anybody is curious or finds a real need for this DLL. Mike --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/Makefile.in 2004-03-30 12:03:27.000000000 +0900 @@ -0,0 +1,20 @@ +#MKDLL_SKIP +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = w95inf32.dll +IMPORTS = setupapi kernel32 +ALTNAMES = w95inf16.dll + +SPEC_SRCS16 = $(ALTNAMES:.dll=.spec) + +C_SRCS = \ + w95inf32.c + +(a)MAKE_DLL_RULES@ + +w95inf16.spec.c: w95inf16.spec + $(WINEBUILD) $(DEFS) $(DLLFLAGS) -o $@ --main-module $(MODULE) --spec $(SRCDIR)/w95inf16.spec + +### Dependencies: --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.c 2004-03-29 17:07:20.000000000 +0900 @@ -0,0 +1,91 @@ +/* + * W95INF32 - This is a small 32bit interface to SETUPX + * + * Copyright 2004 Mike McCormack for CodeWeavers + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" +#include "winuser.h" + +#include "setupapi.h" + +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(w95inf32); + +BOOL WINAPI CtlSetLddPath32( LPSTR x, LPSTR y ) +{ + FIXME("%s %s\n", debugstr_a(x), debugstr_a(y) ); + return FALSE; +} + +BOOL WINAPI GenFormStrWithoutPlaceHolders32( LPSTR dst, LPCSTR src, LPCSTR filename ) +{ + HINF hinf; + DWORD ret = 0; + + FIXME("%p %s %s\n", dst, debugstr_a(src), debugstr_a(filename) ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + /* FIXME: call LookupStringInTable? */ + strncpy(dst, src, MAX_INF_STRING_LENGTH ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +DWORD WINAPI GenInstall32(LPCSTR filename, LPCSTR section, LPCSTR directory, DWORD flags) +{ + HINF hinf; + void *context; + DWORD ret = 0; + + ERR("%s, %s, %s, %08lx\n", filename, section, directory, flags ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + context = SetupInitDefaultQueueCallback( 0 ); + if (!SetupInstallFromInfSectionA( 0, hinf, section, flags, 0, NULL, + SP_COPY_NEWER_OR_SAME, SetupDefaultQueueCallbackA, + context, 0, 0 )) + { + ret = GetLastError(); + ERR("Failed %08lx\n",ret); + } + + SetupTermDefaultQueueCallback( context ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +BOOL WINAPI GetSETUPXErrorText32(long a, long b, long c) +{ + FIXME("\n"); + return FALSE; +} + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.spec 2004-03-29 17:04:15.000000000 +0900 @@ -0,0 +1,9 @@ +# w95inf32 functions have @nn in their names... +# winebuild removes the last @xx in a function name. + +1 stdcall CtlSetLddPath32(a)8@8(str str) CtlSetLddPath32 +2 stdcall GenFormStrWithoutPlaceHolders32(a)12@12(ptr str str) GenFormStrWithoutPlaceHolders32 +3 stdcall GenInstall32(a)20@20(str str str long) GenInstall32 +4 stdcall GetSETUPXErrorText32(a)12@12(long long long) GetSETUPXErrorText32 +5 stub w95thk_ThunkData32 +

1 0