- wine-devel - winehq.org

Re: dlls/dinput/mouse.c - GetDeviceState
by Lionel Ulmer 17 Jun '04

17 Jun '04

> this patch adds a missing errorcode in GetDeviceState in > dlls/dinput/mouse.c which prevented the mouse to work in some game. Which games did require this error to be set ? I seem to remember some hacks around this but I do not remember if it was an error added in the GetDeviceData function or an error removed somewhere because it relied on getting something even if not acquired... I will try a test application when I have access to my Windows development machine to get the error code :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 1

Re: dlls/dinput/mouse.c warp handling
by Lionel Ulmer 17 Jun '04

17 Jun '04

> this is a more complete version of my mouse patch in which I tried to > remove this funny mouse-warping-stuff. > > the mouse feels much better this way, but I am new to wine and maybe I > missed something important and/or did not remove the mousewarping cleanly. Errrm, do you understand exactly what you remove and why it was in the code ? Basically, if you remove mouse warping, when you play games like Quake, you will only be able to turn to your right (or left :-) ) for a fixed amount... I.e. up until the point where the mouse will hit the right border of the window. I agree though that 2D games (like StarCraft or others) will feel a LOT better with a patch like that, but it's plainly wrong. The only way to fix this is to sometimes warp the mouse back in the middle of the window (or to use DGAMouse (or to write a new X11 extension :-) )). Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 5

Re: [KERNEL] add CmdBatNotification stub
by Dmitry Timoshkov 17 Jun '04

17 Jun '04

<markus.amsler(a)oribi.org> wrote: > CmdBatNotification is used by cmd.exe when executing a bat file. > Found no documentation about this function, so I dissassembled it: Please do not send disassembled Windows code to these lists. To find number of arguments for an API call there is no need to disassemble anything, just run an app with +snoop and it will do the job for you. -- Dmitry.

3 2

D3D9 - Anyone working on that
by Andrei Barbu 16 Jun '04

16 Jun '04

Hey, Is anyone working on DX9? It's all implemented by stubs right now, and I was thinking of lending a hand. If anyone's doing that, do you have a place where I can see how far you've gotten. No point in reinventing the wheel. I probably won't be able to do very advanced work with it because I've barely touched DX under Windows, I can find a few books on it though. Also I've never used DX shaders, only CG so unless it's very close to that I can't much help there, I am willing to try though. If noone's in the middle of doing that, I guess I can start on my own. Thanks, Andrei

2 1

[PHOTOSHOP7] not installable, OS not supported, for NT4 service pack >= 6a
by Luca Capello 16 Jun '04

16 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is the second test with no config file as Mike Hearn suggested [1]. 'Adobe Photoshop 7.0' can't be installed: the problem is grave, as the installation process doesn't start at all. The steps: ===== luca@gismo:~/cvs/wine-20040615$ rm -rf /home/luca/.wine/ luca@gismo:~/cvs/wine-20040615$ wine /home/luca/win32_install/Adobe/Adobe.Photoshop.7/Photoshop/Setup.exe wine: creating configuration directory '/home/luca/.wine'... wine: '/home/luca/.wine' created successfully. fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. luca@gismo:~/cvs/wine-20040615$ ===== I can see the 'Photoshop 7' logo window, but then another window appears with this message: "This operating system is not supported by this installation. For Windows NT 4, you must have service pack 6a or greater to install. Setup will now quit." And pressing OK causes nothing, I mean, I don't need to press OK to have 'wine' quitting: I can leave the message window open and continue to use the 'gnome-terminal' with no problem. Again, with the 'fake_windows' provided by the 'WineTools' [2], I can install 'Photoshop 7.0' with all the options (included 'ImageReady'). The only problem I get is an error creating the icon set, but pressing 'OK' lets the installation process to finish cleanly. Solutions? Thx, bye, Gismo / Luca [1] http://www.winehq.org/hypermail/wine-devel/2004/06/0242.html [2] http://franksworld.net/winetools.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0CH4VAp7Xm10JmkRAmufAJ9yKlSlSJhV6Wt0C1RIYGdoacLsxgCfUi1B /bN09F/mXRzMmG5lKTqDQss= =ARER -----END PGP SIGNATURE-----

2 2

Re: WineHQ-hosted projects?pecific app. (e.g. The WINE-Star Wars Galaxies Project, or The
by Brian Vincent 16 Jun '04

16 Jun '04

> I'd like to start up a WINE-based project to further development for a > specific app. (e.g. The WINE-Star Wars Galaxies Project, or The > WINE-Internet Explorer Project). Does WineHQ have a place to host such > things (with their own sites, etc.), or should I turn to SourceForge? Another resource is the AppDB: http://appdb.winehq.org I'd think all the details could go in there. Ideally it would all work out of the box and there would be no reason for special instructions. -Brian

1 0

Re: PATCH: fix dlls/ntdll/cdrom.c breakage
by Uwe Bonnes 16 Jun '04

16 Jun '04

>>>>> "Gerald" == Gerald Pfeifer <gerald(a)pfeifer.com> writes: Gerald> The following patch to dlls/ntdll/cdrom.c revision 1.46 date: Gerald> 2004/06/15 00:45:01; author: julliard; state: Exp; lines: +421 Gerald> -1 Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> Support Gerald> for reading encrypted DVDs. Gerald> causes a build failure on all FreeBSD (and it seems also NetBSD) Gerald> platforms: Gerald> cdrom.c: In function `DVD_EndSession': cdrom.c:1739: error: Gerald> `dev' undeclared (first use in this function) cdrom.c:1739: Gerald> error: (Each undeclared identifier is reported only once Gerald> cdrom.c:1739: error: for each function it appears in.) Gerald> cdrom.c:1739: error: `rmv' undeclared (first use in this Gerald> function) gmake[2]: *** [cdrom.o] Error 1 gmake[2]: Leaving Gerald> directory `/.amd_mnt/nashira/files5/test/wine/dlls/ntdll' Gerald> gmake[1]: *** [ntdll] Error 2 Gerald> There is BSD-specific code in this function, but both dev and Gerald> rmv do not appear anywhere, so I guess this was copied from Gerald> somewhere else and then not adjusted? The Non-Linux side of the patch was never tested. Appended patch return STATUS_NOT_SUPPORTED for that code clause and should make the code compile again. Gerald, can you perhaps have a look at the implementation of the BSD parts? libdvdcss should have all the needed calls somewhere. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/ntdll/cdrom.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/cdrom.c,v retrieving revision 1.46 diff -u -w -r1.46 cdrom.c --- wine/dlls/ntdll/cdrom.c 15 Jun 2004 00:45:01 -0000 1.46 +++ wine/dlls/ntdll/cdrom.c 16 Jun 2004 15:11:00 -0000 @@ -1736,7 +1736,8 @@ TRACE("\n"); return CDROM_GetStatusCode(ioctl(fd, DVD_AUTH, &auth_info)); #elif defined(__FreeBSD__) || defined(__NetBSD__) - return CDROM_GetStatusCode(ioctl(cdrom_cache[dev].fd, (rmv->PreventMediaRemoval) ? CDIOCPREVENT : CDIOCALLOW, NULL)); + TRACE("bsd\n"); + return STATUS_NOT_SUPPORTED; #else return STATUS_NOT_SUPPORTED; #endif

1 0

Re: WineHQ-hosted projects?
by chmorgan＠charter.net 16 Jun '04

16 Jun '04

No need to fork winehq to support such things. Imaging having to keep up with all of the patches applied to the mainline code? It's probably better just to fix things that break those apps in the winehq tree so every other app gets the benifit. Chris > > From: Joel Konkle-Parker <jjk3(a)msstate.edu> > Date: 2004/06/16 Wed AM 07:09:28 EDT > To: wine-devel(a)winehq.com > Subject: WineHQ-hosted projects? > > I'd like to start up a WINE-based project to further development for a > specific app. (e.g. The WINE-Star Wars Galaxies Project, or The > WINE-Internet Explorer Project). Does WineHQ have a place to host such > things (with their own sites, etc.), or should I turn to SourceForge? > > > -- > Joel Konkle-Parker > Webmaster [Ballsome.com] > > E-mail [jjk3(a)msstate.edu] > > >

1 0

Notification
by Twickline 16 Jun '04

16 Jun '04

1 0

Fax Message Received
by Twickline 16 Jun '04

16 Jun '04

1 0

Debugger spews elf_new_wine_thunks fixmes
by Mike Hearn 16 Jun '04

16 Jun '04

Hi Eric, I get a lot of messages like this since the new debugger shuffle patch landed: fixme:dbghelp:elf_new_wine_thunks Duplicate in kernel32<elf>: audiocdW.6<40515de8-00000012> audiocdW<40515de8-00000000> For now I just changed the fixme to a warn in my local tree - what does this message mean though? It makes it much harder to use the debugger currently. thanks -mike

4 4

WineHQ-hosted projects?
by Joel Konkle-Parker 16 Jun '04

16 Jun '04

I'd like to start up a WINE-based project to further development for a specific app. (e.g. The WINE-Star Wars Galaxies Project, or The WINE-Internet Explorer Project). Does WineHQ have a place to host such things (with their own sites, etc.), or should I turn to SourceForge? -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jjk3(a)msstate.edu]

1 0

assertion "view->next->flags & VFLAG_SYSTEM" failed: file "virtual.c", line 330
by jordan lougheed 16 Jun '04

16 Jun '04

WINE BUILD: /wine-20040505 I need Internet Explorer on my workstation (openbsd 3.4) at work, so I decided to see if I could get the lastest wine to compile/run. I'll list the steps required to get it to build and install. `sh configure` complained about 'libGL.a' so i renamed it and the configure completed successfully. `make` ./loader/kthread.c: line 276 complained about an unknown flag `RFTHREAD` so i erased that flag from the code, and the build continued. (openbsd's rfork doesn't support that flag, side effects are unknown) `make install` wouldn't complete. I had to `gmake install`. worked fine. everything is built and installed, now here is my problem. $ wine notepad.exe wine:/usr/local/lib/wine/ntdll.dll.so: undefined symbol 'DllMain' wine: /usr/local/lib/wine/ntdll.dll.so: can't resolve reference 'DllMain' fixme:ntdll:NtQueryVolumeInformationFile device info not properly supported on this platform fixme:file:get_default_drive_device auto detection of DOS devices not supported on this platform assertion "view->next->flags & VFLAG_SYSTEM" failed: file "virtual.c", line 330 the "fixme:" problems seem to be common with FreeBSD, so i figure i can ignore them. I always seems to hit that assertion on no matter what i run. The first time i ran this "PokerStarsInstall.exe" it ran fine and gave me the install menu after configuring the "font cache". The second time it gave me this usual assertion. If someone can confirm/deny that this is related the that FLAG i erased from kthread.c (i don't think these are related). Or is there something else going on here? If anyone can offer any help it would be appreciated. I'm going to compile with -DNDEBUG tommorow and see what happends, until then i'll let you guys stew on this. Thank you in advance, JordanL

1 0

3GB address space
by Shachar Shemesh 15 Jun '04

15 Jun '04

Hi all, Is there a way to run processes intended for a 3GB user addressable memory to work under Wine? I'm talking here, of course, assuming that the Linux kernel is compiled with the relevant big memory support. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

4 11

Re: GetAcceptLanguages A->W [2nd][resend]
by Alexandre Julliard 15 Jun '04

15 Jun '04

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > Hello, > > anything wrong with this patch? The last error handling is very suspicious, I doubt the function sets ERROR_FILE_NOT_FOUND on a null buffer. I think it's because your test is broken, you need to clear last error before every call if you want to be able to test it afterwards otherwise you just get leftovers from a previous call. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winetest: move to resources (take n+1)
by Alexandre Julliard 15 Jun '04

15 Jun '04

Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > Alexandre Julliard <julliard(a)winehq.org> writes: > >> Also I think it would be cleaner to use a different rc >> file for the dist case instead of using #ifdefs. > > I agree. The problem is the single-rc-file limitation, > which would require some code duplication. That's why I > went for the #ifdefs. Please come back at me if you still > have strong feelings about this. What you can do is have a dist.rc file that defines the extra values and then #includes the normal .rc file. This way there is no duplication and no problems with multiple rc files. The only thing is that the code should behave gracefully when the extra resources are missing, but that would be a good thing to do anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [WineHQ] service.cgi fixes
by Paul Millar 15 Jun '04

15 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dimi, Why remove the verification of the code's gpg signature? It seems to break a basic security maxim: don't trust the network. On Thursday 10 June 2004 22:48, Dimitrie O. Paun wrote: > ChangeLog > Do not include irrelevant stuff in the _history. > Do not instruct the client to verify the .sig, > it's a b0rken idea anyway. - -- Paul Millar -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAybhq/9JwS78PA+kRAuv/AJ9Ulntb1MLGn+2gp8r/qpy6VqJDVACePwVB VXxAHr9gaBuMhIJ7P81ahMA= =0tkh -----END PGP SIGNATURE-----

3 5

Latest iteration of the systray patch
by Mike Hearn 15 Jun '04

15 Jun '04

This version is resynced against CVS HEAD, and now does a ShowWindow in the right place (just after the embed notification not in some random WM message). This won't be merged so I'm sending it to wine-devel not wine-patches. Getting it merged is blocking on either somebody giving me example code for [un]marshaling an HICON into a block of memory or (best fix) images being moved into the wineserver. This is on Ulrichs todo list but if anybody wants to beat him to it, go ahead, it's still some time off yet. thanks -mike

1 0

Re: Incoming Message
by Twickline 15 Jun '04

15 Jun '04

1 0

(no subject)
by Gerald Pfeifer 15 Jun '04

15 Jun '04

The following patch to dlls/shell32/shlexec.c revision 1.50 date: 2004/06/15 00:44:14; author: julliard; state: Exp; lines: +11 -3 Dmitry Timoshkov <dmitry(a)codeweavers.com> Restore default "open" functionality of ShellExecute. introduced the following warning regressions: shlexec.c:722: warning: format argument is not a pointer (arg 11) shlexec.c:722: warning: format argument is not a pointer (arg 12) Would you mind fixing this? Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: Incoming Message
by Twickline 15 Jun '04

15 Jun '04

1 0

Re: Yahoo!
by Johane 15 Jun '04

15 Jun '04

1 0

Do we still need wineinstall?
by Mike Hearn 15 Jun '04

15 Jun '04

Hi, I've been running without a config file for a while now, and have fixed various misc bugs related to that as I go - I'm sure there are some more in there, but as the config file is destined for eventual doom anyway I am wondering if we still need wineinstall at all? Currently, it's possible to use Wine quite succesfully just by doing a standard ./configure, make, make install. When you run wine for the first time wineprefixcreate will be used to setup ~/.wine, merge the registry, create the fake windows drive and so on. The only piece you don't get is the default config file, but that doesn't seem to make much difference any more. At least, the defaults should be in the code not the config file as people never upgrade that bit anyway :) So - do we still need it?

2 1

Re: winetest: move to resources (take n) (resend)
by Alexandre Julliard 14 Jun '04

14 Jun '04

Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > This is a resend to elicit some feedback on your objections > against this patch. What did I miss again? It's much better this time. The only thing I would suggest changing is that the build info text formatting should be done in the code, not in the makefile. Also I think it would be cleaner to use a different rc file for the dist case instead of using #ifdefs. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Create DIALOGINFO On Demand When Calling DIALOG_get_info
by Alexandre Julliard 14 Jun '04

14 Jun '04

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > This patch fixes bug 2210: > http://bugs.winehq.org/show_bug.cgi?id=2210 > This patch differs slightly from the one posted to wine-devel, as it > includes some checks for NULL return from DIALOG_get_info. I don't think you want to create the dialog info in all cases, this should only be done where we are sure we have a dialog window. For instance you don't want MapDialogRect to add dialog info to arbitrary windows just because it got passed a wrong handle. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wine/include ddeml.h
by andrejoh＠c2i.net 14 Jun '04

14 Jun '04

* Alexandre Julliard (Mon, 14 Jun 2004 11:58:02 -0500) wrote: | Dmitry Timoshkov <dmitry(a)codeweavers.com> | Fix CBR_BLOCK definition. | | Patch: http://cvs.winehq.org/patch.py?id=12591 | | Old revision New revision Changes Path | 1.29 1.30 +1 -1 wine/include/ddeml.h This one causes a compile failure: dde/server.c: In function `WDML_ServerHandleRequest': dde/server.c:580: error: pointers are not permitted as case values switch ((ULONG_PTR)hDdeData) [...] case CBR_BLOCK: The patch below fixes it by casting to an ULONG_PTR, which is what the switch variable is casted to. Index: dlls/user/dde/server.c =================================================================== RCS file: /home/wine/wine/dlls/user/dde/server.c,v retrieving revision 1.16 diff -u -w -p -r1.16 server.c --- dlls/user/dde/server.c 26 Apr 2004 23:29:44 -0000 1.16 +++ dlls/user/dde/server.c 14 Jun 2004 19:18:52 -0000 @@ -577,7 +577,7 @@ static WDML_QUEUE_STATE WDML_ServerHandl WDML_PostAck(pConv, WDML_SERVER_SIDE, 0, FALSE, FALSE, pXAct->atom, pXAct->lParam, WM_DDE_REQUEST); break; - case CBR_BLOCK: + case (ULONG_PTR)CBR_BLOCK: ret = WDML_QS_BLOCK; break; default: -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

1 0

Re: wine/dlls/user/dde client.c
by Ivan 14 Jun '04

14 Jun '04

This patch http://www.winehq.com/hypermail/wine-cvs/2004/06/0085.html breaks the build on Mandrake 10.0 using gcc 3.3.2 and make 3.8, with the following error: dde/server.c: In function `WDML_ServerHandleRequest': dde/server.c:580: error: pointers are not permitted as case values make[2]: *** [dde/server.o] Error 1 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls' make: *** [dlls] Error 2 Ivan.

1 0

Re: revised winmm GetDevCaps better pointer check patch
by Alexandre Julliard 14 Jun '04

14 Jun '04

Robert Reif <reif(a)earthlink.net> writes: > +/* Use the first version for strict compatibility with Microsoft */ > +/* #define WINMM_IsBadWritePtr(x,y) IsBadWritePtr((x), (y)) */ > +#define WINMM_IsBadWritePtr(x,y) ((x)==NULL) This is very confusing, if we don't check the pointer we shouldn't have a macro that looks like we do. The proper way is to add exception handlers in functions where an app explicitly relies on the pointer check, and not add checks otherwise; using the IsBad*Ptr functions is always wrong since they are not thread-safe. -- Alexandre Julliard julliard(a)winehq.org

1 0

General serial communications issues
by David Purucker 14 Jun '04

14 Jun '04

Hello, I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem. They all exhibit the same situation, DATA seems to go OUT, but never seems to come IN. Several other people have experienced the same thing, as seen in this bug report: http://bugs.winehq.org/show_bug.cgi?id=2115 By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a serial problem. It's freeware available here: http://hp.vector.co.jp/authors/VA002416/teraterm.html It appears to be a fundamental problem in the serial/file code, which I understand is now under the ntdll tree. Obviously, I don't know much about it, but there is definitely something wrong. I was wondering if any developers were aware of this problem, as the decreased general usage of serial communications may have caused this to slip under the carpet, so to speak. I look forward to hearing any ideas, work-arounds, or patches. Thanks _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/

7 20

Re: Fix 3 bugs in locale handling
by Alexandre Julliard 14 Jun '04

14 Jun '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > 1. If the locale has changed current code never refreshes win.ini > and registry values due to the following test done in GetLocaleInfoW: > > /* first check for overrides in the registry */ > > if (!(lcflags & LOCALE_NOUSEROVERRIDE) && lcid == GetUserDefaultLCID()) > { > > lcid is always pointing to current user locale returned by GetUserDefaultLCID() > and therefore cached (old) values get returned. > > I modified code to get data directly from kernel resources in that case. It seems to me that this is what we are doing already since we pass LOCALE_NOUSEROVERRIDE in that case, I don't see how your patch would make any difference (and win.ini definitely gets refreshed with the current code). Could you please give more details on the problem you are seeing? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: SHELL32:RunFileDlg
by Alexandre Julliard 14 Jun '04

14 Jun '04

Filip Navara <xnavara(a)volny.cz> writes: > + if (!(hRes = FindResourceW(shell32_hInstance, L"SHELL_RUN_DLG", (LPWSTR)RT_DIALOG))) You cannot use wide char string constants in Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Fix Private Profile Functions for .INI in Current Directory
by Alexandre Julliard 14 Jun '04

14 Jun '04

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > As per MSDN (1), if a relative path to a file is passed in to the > {Get,Write}PrivateProfile* functions then the current directory is tried > first, and then if that fails the Windows directory is used (for both > the opening and creating cases). I don't see any evidence that this is true, and MSDN says "If the lpFileName parameter does not contain a full path and file name for the file, WritePrivateProfileString searches the Windows directory for the file". Do you have a test case showing that the current behavior is wrong? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Do we still need wineinstall?
by Ivan 14 Jun '04

14 Jun '04

> So - do we still need it? Can we use the registry (BTW then will winecfg be working?) to set up all the stuff we can do in the config file? Stuff such as winver, UseDGA, UseXVidMode, Managed or desktop more, and DllOverrides? If we can, IMHO wineinstall can go. Ivan.

1 0

text input focus problem
by Richard Gobeille 14 Jun '04

14 Jun '04

Recently I upgraded a piece of software on my system called Synergy. This software allows one keyboard and mouse to control input on two or more machines via a network connection -- not dissimilar to VNC, except that only the keyboard and mouse input is forwarded, nothing with video, et cetera, and that it lets you mouse back and forth as if you were using a dualhead configuration on one box. Anyhow, the problem is as follows: when using Synergy, I'm no longer able to use text input in wine at all. This applies to both winehq and crossover, winex appears to be unaffected. Originally, I thought this was a problem with Synergy itself, but upon asking the developer about it, I received notification that it was an X11 bug that wine wasn't working around. The technical details are as follows: "the X11 bug is subtle: if client A creates two windows X and Y where Y is a child of X and selects for key events on window X, it expects to receive key events that occur in either X or Y (the events in Y propagate up to the nearest ancestor that has selected for the event). if another client B (synergy) comes along and selects for key events in Y then not only will B receive key events from Y (as expected) but key events in A will no longer propagate from Y to X and A won't see the events. that is, when B selects for events on window Y it changes the behavior of client A. this is just wrong." One of the guys in #winehq on freenode (TD) said to send this to wine-devel, so here it is. I'm not sure if any more information is required. The site for Synergy is http://synergy2.sourceforge.net. Any 1.1.x release should demonstrate the problem for you. I'm hopeful that this will be an easy problem to work around as winex is working around it, but I'm not sure how similar or dissimilar the trees are in this area. -- *Richard Gobeille* Chief Technical Officer Envision7, LLC Internet Services http://www.envision7.com rich(a)envision7.com

1 0

Re: Yahoo!
by Johane 14 Jun '04

14 Jun '04

1 0

Forum notify
by Johane 14 Jun '04

14 Jun '04

1 0

Re: Yahoo!
by Twickline 14 Jun '04

14 Jun '04

1 0

Versioning and internal APIs
by Mike Hearn 13 Jun '04

13 Jun '04

Hi Alexandre, Paul Davis of Ardour has raised a good point: currently despite the fact that the symbols in libwine are versioned, we change them at will and don't change the symbol version, for instance in the patch that made environ passed through to wine_init from main to hack around the general suckage of MacOS X. Unless this versioning system is meant to be dormant until Wine 1.0 is out (and we should definitely document this if so), perhaps we should be changing the symbol versions? Also, there is no easy way to find out the version of Wine you got from dlopen at runtime. Should we export a wine_version symbol? Finally, apparently Paul has had to duplicate a fair amount of Wine code inside his libfst (library for loading Cubase VST plugins) because the relevant functions are declared static in Wine. Paul, could you post a list of exactly what you use? It might be worth extending and starting to freeze some of these semi-internal interfaces. thanks -mike

3 5

[MSVCRT] Separate internal definitions from the public headers
by Dimitrie O. Paun 13 Jun '04

13 Jun '04

Hi Alexandre, Welcome back! I did this last Friday, but I didn't want to continue before running it by you. I'm sending here just the first cut of the definitions I needed to duplicate in msvcrt.h, to compile the entire msvcrt DLL without the MSVCRT() define in the public headers. Looking at the changes it seems to me: 1. There aren't that many 2. We can easily add a test file to check for consistency with the public headers (ideally, this file would be automatically generated by a script) 3. We should be able to actually drop some of them, this is just the first cut, and I've tried to keep the number of changes to the source code to a minimum. Should I carry on? -- Dimi. Index: dlls/msvcrt/msvcrt.h =================================================================== RCS file: /var/cvs/wine/dlls/msvcrt/msvcrt.h,v retrieving revision 1.25 diff -u -r1.25 msvcrt.h --- dlls/msvcrt/msvcrt.h 16 Mar 2004 19:17:11 -0000 1.25 +++ dlls/msvcrt/msvcrt.h 4 Jun 2004 23:05:05 -0000 @@ -28,8 +28,27 @@ #include "winerror.h" #include "winnls.h" -#include "msvcrt/string.h" -#include "msvcrt/eh.h" +typedef unsigned short MSVCRT_wchar_t; +typedef unsigned short MSVCRT_wint_t; +typedef unsigned short MSVCRT_wctype_t; +typedef unsigned short MSVCRT__ino_t; +typedef unsigned long MSVCRT__fsize_t; +typedef unsigned int MSVCRT_size_t; +typedef unsigned int MSVCRT__dev_t; +typedef int MSVCRT__off_t; +typedef long MSVCRT_clock_t; +typedef long MSVCRT_time_t; +typedef long MSVCRT_fpos_t; + +typedef void (*terminate_handler)(); +typedef void (*terminate_function)(); +typedef void (*unexpected_handler)(); +typedef void (*unexpected_function)(); +typedef void (*_se_translator_function)(unsigned int code, struct _EXCEPTION_POINTERS *info); +typedef void (*_beginthread_start_routine_t)(void *); +typedef unsigned int (__stdcall *_beginthreadex_start_routine_t)(void *); +typedef int (*MSVCRT__onexit_t)(void); + /* TLS data */ extern DWORD MSVCRT_tls_index; @@ -123,4 +142,363 @@ #define _RT_CRNL 252 #define _RT_BANNER 255 +struct MSVCRT_tm { + int tm_sec; + int tm_min; + int tm_hour; + int tm_mday; + int tm_mon; + int tm_year; + int tm_wday; + int tm_yday; + int tm_isdst; +}; + +struct _timeb +{ + MSVCRT_time_t time; + unsigned short millitm; + short timezone; + short dstflag; +}; + +typedef struct MSVCRT_iobuf +{ + char* _ptr; + int _cnt; + char* _base; + int _flag; + int _file; + int _charbuf; + int _bufsiz; + char* _tmpfname; +} MSVCRT_FILE; + +struct MSVCRT_lconv +{ + char* decimal_point; + char* thousands_sep; + char* grouping; + char* int_curr_symbol; + char* currency_symbol; + char* mon_decimal_point; + char* mon_thousands_sep; + char* mon_grouping; + char* positive_sign; + char* negative_sign; + char int_frac_digits; + char frac_digits; + char p_cs_precedes; + char p_sep_by_space; + char n_cs_precedes; + char n_sep_by_space; + char p_sign_posn; + char n_sign_posn; +}; + +struct MSVCRT__exception +{ + int type; + char *name; + double arg1; + double arg2; + double retval; +}; + +struct MSVCRT__complex +{ + double x; /* Real part */ + double y; /* Imaginary part */ +}; + +typedef struct _heapinfo +{ + int* _pentry; + MSVCRT_size_t _size; + int _useflag; +} _HEAPINFO; + +#ifdef __i386__ +typedef struct __JUMP_BUFFER +{ + unsigned long Ebp; + unsigned long Ebx; + unsigned long Edi; + unsigned long Esi; + unsigned long Esp; + unsigned long Eip; + unsigned long Registration; + unsigned long TryLevel; + /* Start of new struct members */ + unsigned long Cookie; + unsigned long UnwindFunc; + unsigned long UnwindData[6]; +} _JUMP_BUFFER; +#endif /* __i386__ */ + +struct MSVCRT__diskfree_t { + unsigned int total_clusters; + unsigned int avail_clusters; + unsigned int sectors_per_cluster; + unsigned int bytes_per_sector; +}; + +struct MSVCRT__finddata_t +{ + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + MSVCRT__fsize_t size; + char name[260]; +}; + +struct MSVCRT__finddatai64_t +{ + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + __int64 size; + char name[260]; +}; + +struct MSVCRT__wfinddata_t { + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + MSVCRT__fsize_t size; + MSVCRT_wchar_t name[260]; +}; + +struct MSVCRT__wfinddatai64_t { + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + __int64 size; + MSVCRT_wchar_t name[260]; +}; + +struct _utimbuf +{ + MSVCRT_time_t actime; + MSVCRT_time_t modtime; +}; + +/* for FreeBSD */ +#undef st_atime +#undef st_ctime +#undef st_mtime + +struct MSVCRT__stat { + MSVCRT__dev_t st_dev; + MSVCRT__ino_t st_ino; + unsigned short st_mode; + short st_nlink; + short st_uid; + short st_gid; + MSVCRT__dev_t st_rdev; + MSVCRT__off_t st_size; + MSVCRT_time_t st_atime; + MSVCRT_time_t st_mtime; + MSVCRT_time_t st_ctime; +}; + +struct MSVCRT_stat { + MSVCRT__dev_t st_dev; + MSVCRT__ino_t st_ino; + unsigned short st_mode; + short st_nlink; + short st_uid; + short st_gid; + MSVCRT__dev_t st_rdev; + MSVCRT__off_t st_size; + MSVCRT_time_t st_atime; + MSVCRT_time_t st_mtime; + MSVCRT_time_t st_ctime; +}; + +struct MSVCRT__stati64 { + MSVCRT__dev_t st_dev; + MSVCRT__ino_t st_ino; + unsigned short st_mode; + short st_nlink; + short st_uid; + short st_gid; + MSVCRT__dev_t st_rdev; + __int64 st_size; + MSVCRT_time_t st_atime; + MSVCRT_time_t st_mtime; + MSVCRT_time_t st_ctime; +}; + +#define MSVCRT_WEOF (MSVCRT_wint_t)(0xFFFF) +#define MSVCRT_EOF (-1) +#define MSVCRT_TMP_MAX 0x7fff +#define MSVCRT_BUFSIZ 512 + +#define MSVCRT_STDIN_FILENO 0 +#define MSVCRT_STDOUT_FILENO 1 +#define MSVCRT_STDERR_FILENO 2 + +/* more file._flag flags, but these conflict with Unix */ +#define MSVCRT__IOFBF 0x0000 +#define MSVCRT__IONBF 0x0004 +#define MSVCRT__IOLBF 0x0040 + +#define MSVCRT_FILENAME_MAX 260 +#define MSVCRT_stdin (MSVCRT__iob+MSVCRT_STDIN_FILENO) +#define MSVCRT_stdout (MSVCRT__iob+MSVCRT_STDOUT_FILENO) +#define MSVCRT_stderr (MSVCRT__iob+MSVCRT_STDERR_FILENO) + +#define _P_WAIT 0 +#define _P_NOWAIT 1 +#define _P_OVERLAY 2 +#define _P_NOWAITO 3 +#define _P_DETACH 4 + +#define MSVCRT_EPERM 1 +#define MSVCRT_ENOENT 2 +#define MSVCRT_ESRCH 3 +#define MSVCRT_EINTR 4 +#define MSVCRT_EIO 5 +#define MSVCRT_ENXIO 6 +#define MSVCRT_E2BIG 7 +#define MSVCRT_ENOEXEC 8 +#define MSVCRT_EBADF 9 +#define MSVCRT_ECHILD 10 +#define MSVCRT_EAGAIN 11 +#define MSVCRT_ENOMEM 12 +#define MSVCRT_EACCES 13 +#define MSVCRT_EFAULT 14 +#define MSVCRT_EBUSY 16 +#define MSVCRT_EEXIST 17 +#define MSVCRT_EXDEV 18 +#define MSVCRT_ENODEV 19 +#define MSVCRT_ENOTDIR 20 +#define MSVCRT_EISDIR 21 +#define MSVCRT_EINVAL 22 +#define MSVCRT_ENFILE 23 +#define MSVCRT_EMFILE 24 +#define MSVCRT_ENOTTY 25 +#define MSVCRT_EFBIG 27 +#define MSVCRT_ENOSPC 28 +#define MSVCRT_ESPIPE 29 +#define MSVCRT_EROFS 30 +#define MSVCRT_EMLINK 31 +#define MSVCRT_EPIPE 32 +#define MSVCRT_EDOM 33 +#define MSVCRT_ERANGE 34 +#define MSVCRT_EDEADLK 36 +#define MSVCRT_EDEADLOCK MSVCRT_EDEADLK +#define MSVCRT_ENAMETOOLONG 38 +#define MSVCRT_ENOLCK 39 +#define MSVCRT_ENOSYS 40 +#define MSVCRT_ENOTEMPTY 41 + +#define MSVCRT_LC_ALL 0 +#define MSVCRT_LC_COLLATE 1 +#define MSVCRT_LC_CTYPE 2 +#define MSVCRT_LC_MONETARY 3 +#define MSVCRT_LC_NUMERIC 4 +#define MSVCRT_LC_TIME 5 +#define MSVCRT_LC_MIN MSVCRT_LC_ALL +#define MSVCRT_LC_MAX MSVCRT_LC_TIME + +#define _HEAPEMPTY -1 +#define _HEAPOK -2 +#define _HEAPBADBEGIN -3 +#define _HEAPBADNODE -4 +#define _HEAPEND -5 +#define _HEAPBADPTR -6 + +#define _FREEENTRY 0 +#define _USEDENTRY 1 + +#define _OUT_TO_DEFAULT 0 +#define _REPORT_ERRMODE 3 + +/* ASCII char classification table - binary compatible */ +#define _UPPER 0x0001 /* C1_UPPER */ +#define _LOWER 0x0002 /* C1_LOWER */ +#define _DIGIT 0x0004 /* C1_DIGIT */ +#define _SPACE 0x0008 /* C1_SPACE */ +#define _PUNCT 0x0010 /* C1_PUNCT */ +#define _CONTROL 0x0020 /* C1_CNTRL */ +#define _BLANK 0x0040 /* C1_BLANK */ +#define _HEX 0x0080 /* C1_XDIGIT */ +#define _LEADBYTE 0x8000 +#define _ALPHA (0x0100|_UPPER|_LOWER) /* (C1_ALPHA|_UPPER|_LOWER) */ + +#define MSVCRT__IOREAD 0x0001 +#define MSVCRT__IOWRT 0x0002 +#define MSVCRT__IOMYBUF 0x0008 +#define MSVCRT__IOEOF 0x0010 +#define MSVCRT__IOERR 0x0020 +#define MSVCRT__IOSTRG 0x0040 +#define MSVCRT__IORW 0x0080 + +#define _S_IEXEC 0x0040 +#define _S_IWRITE 0x0080 +#define _S_IREAD 0x0100 +#define _S_IFIFO 0x1000 +#define _S_IFCHR 0x2000 +#define _S_IFDIR 0x4000 +#define _S_IFREG 0x8000 +#define _S_IFMT 0xF000 + +void MSVCRT_free(void*); +void* MSVCRT_malloc(MSVCRT_size_t); +void* MSVCRT_calloc(MSVCRT_size_t,MSVCRT_size_t); +void* MSVCRT_realloc(void*,MSVCRT_size_t); + +int MSVCRT_iswalpha(MSVCRT_wint_t); +int MSVCRT_iswspace(MSVCRT_wint_t); +int MSVCRT_iswdigit(MSVCRT_wint_t); +int MSVCRT_isleadbyte(int); + +int MSVCRT_fgetc(MSVCRT_FILE*); +int MSVCRT_ungetc(int,MSVCRT_FILE*); +MSVCRT_wint_t MSVCRT_fgetwc(MSVCRT_FILE*); +MSVCRT_wint_t MSVCRT_ungetwc(MSVCRT_wint_t,MSVCRT_FILE*); +void MSVCRT__exit(int); +void MSVCRT_abort(); +unsigned long* MSVCRT___doserrno(void); +int* MSVCRT__errno(void); +char* MSVCRT_getenv(const char*); +char* MSVCRT_setlocale(int,const char*); +int MSVCRT_fclose(MSVCRT_FILE*); +void MSVCRT_terminate(); +MSVCRT_FILE* MSVCRT__p__iob(void); +MSVCRT_time_t MSVCRT_time(MSVCRT_time_t*); + +MSVCRT_wchar_t* _wcsdup(const MSVCRT_wchar_t*); +MSVCRT_wchar_t*** __p__wenviron(void); + +int _write(int,const void*,unsigned int); +int _vsnwprintf(MSVCRT_wchar_t*,MSVCRT_size_t,const MSVCRT_wchar_t*,va_list); +void _splitpath(const char*,char*,char*,char*,char*); +int _ismbstrail(const unsigned char* start, const unsigned char* str); +int _spawnve(int,const char*,const char* const *,const char* const *); +void _searchenv(const char*,const char*,char*); +void _sleep(unsigned long); +int _getdrive(void); +int _futime(int,struct _utimbuf*); +char* _strdup(const char*); +char* _strlwr(char*); +char* _strupr(char*); +char* _strnset(char*,int,MSVCRT_size_t); +char* _strset(char*,int); +int _getch(void); +int _ungetch(int); +int _cputs(const char*); +int _cprintf(const char*,...); +int _snprintf(char*,MSVCRT_size_t,const char*,...); + +char*** __p__environ(void); +int* __p___mb_cur_max(void); +unsigned int* __p__fmode(void); + #endif /* __WINE_MSVCRT_H */

2 1

Re: FindClose crash fix.
by Mike Hearn 13 Jun '04

13 Jun '04

On Sat, 2004-06-12 at 20:34 +0200, Rein Klazes wrote: > BTW. I thought Crossover Office supports this application? It does (well, not the NL version specifically ...) so I checked and the CrossOver version of FindClose is the same as the WineHQ version. I seem to recall some talk of double closing find handles, but I guess either we have a hack elsewhere, or for some reason the bug doesn't appear in the builds we support? thanks -mike

2 1

Windows are unmaxmized when closing other window
by Gerhard W. Gruber 13 Jun '04

13 Jun '04

Some time ago I noticed a strange behviour in Agent. When the windows are maxmized and you close any other window (doesn't matter if it is a dialog or any other normal window) the remaining windows are unmaximized. They arr not minimized, but they are getting smaller. Don't know if this is the same for all types but it seems at least for multiple document windows it is true. I just downloaded the current CVS version and there this behaviour is also. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://pice.sourceforge.net/ Fast application launcher - http://sourceforge.net/projects/launchmenu

3 3

[REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)
by Luca Capello 13 Jun '04

13 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, as reported on bug #2017 [1], Adobe Photoshop 7.0 stops working after wine-20031212 (in the majority of cases). This happens on Debian unstable (where I am) as well as on other distro. As suggested by Tony Lambregts, I made a regression testing to find the patch that broke this. The problem is between cvs-20040130-165720 and cvs-20040130-165721. The 'cvs -d ...' command gives me updates for only 3 files: ===== U dlls/kernel/Makefile.in U dlls/kernel/actctx.c U dlls/kernel/kernel32.spec ===== so I think the problem should be in these files, am I right? If it's so, well, the patch that broke Photoshop 7.0 working is the following [2] - - Jon Griffiths <jon_p_griffiths(a)yahoo.com> Add stubs for the Activation Context API (XP+). Please fix this problem, now that you know the cause. Thx, bye, Gismo / Luca [1] http://bugs.winehq.org/show_bug.cgi?id=2017 [2] http://www.winehq.org/hypermail/wine-cvs/2004/01/0394.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAu1FuVAp7Xm10JmkRAgWIAJ90THCdqfIu6/uLGyurqrLfNNWEkACeIAze ALi4ZeOtMTEEDp8ETWu4G4c= =/pZb -----END PGP SIGNATURE-----

6 25

A bug in symbol loading in winedbg
by Shachar Shemesh 13 Jun '04

13 Jun '04

Hi all, Bug Report: If winedbg is asked to load an external PDB file, and that file does not match the executable being run, the debugger does not warn about it. Instead, bad things (tm) happen when actually trying to run the executable. Shachar

2 8

Re: Implement a --backtrace-all mode for winedbg
by Eric Pouech 12 Jun '04

12 Jun '04

I'm not sure I understand the purpose of the --backtrace-all. There's no way you can ensure a complete synchro between all threads & processes to get a global picture of the whole system, so the option is likely not very useful (except for the threads which are in a wait operation), but you will miss some other information for that (ie an event (entering/leaving CS...) tracker tool would be better). More over, I don't like either adding options to winedbg. So, I'd prefer adding an option to actually process the commands from a file (or even a string from command line) would be better. And, finally, you leak the handle for the snapshot. A+

3 4

Re: [USER] 'Fix' SetWindowsHookEx
by Shachar Shemesh 12 Jun '04

12 Jun '04

Lionel Ulmer wrote: >I have no idea if it's correct >though (as I do not know if what GetModuleHandle returns is really the same >thing as what SetWindowsHookEx expects as an HINSTANCE input). > > Yes, it is. It's just used to grab the procedure address to call when the hook is activated. >Index: dlls/user/hook.c >=================================================================== >RCS file: /home/wine/wine/dlls/user/hook.c,v >retrieving revision 1.12 >diff -u -r1.12 hook.c >--- dlls/user/hook.c 19 May 2004 03:22:55 -0000 1.12 >+++ dlls/user/hook.c 12 Jun 2004 15:27:01 -0000 >@@ -141,11 +141,15 @@ > else /* system-global hook */ > { > if (id == WH_KEYBOARD_LL || id == WH_MOUSE_LL) inst = 0; >- else if (!inst || !(len = GetModuleFileNameW( inst, module, MAX_PATH )) || len >= MAX_PATH) >- { >- SetLastError( ERROR_INVALID_PARAMETER ); >- return 0; >- } > > If you just remove the "!inst" test, does the game work? I think that would be simpler. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

Re: Investigating a crash at startup
by Filip Navara 12 Jun '04

12 Jun '04

1 0

wingcc and -Wb option
by Jon Griffiths 12 Jun '04

12 Jun '04

Hi, The -Wb argument to winegcc currently expects a comma separated list of arguments which it then splits up and passes to winebuild. This conflicts with the --ignore=x,y,z syntax of winebuilds ignore argument, since it also uses a comma to delimit the list to ignore. The easiest way to fix this is to change the delimiting character in either option, i.e.: winebuild: --ignore=x,y,z => --ignore=x;y;z winegcc: -Wb,--ignore=x,y,z,<opts> => -Wb;--ignore=x,y,z;<opts> Does anyone care which one it is? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

2 2

(Still) problem on AMD64 with wine CVS
by Maurizio Monge 12 Jun '04

12 Jun '04

Hello, i have retried to compile wine CVS on amd64 (gcc 3.4 with -m32, etc + kernel 2.6.4-rc2), where i was thinking the 0xc0000000 problem was solved. but i get: wine: failed to initialize: /opt/wine/lib/wine/ntdll.dll.so: failed to map segment from shared object: Cannot allocate memory attach to this mail the output of "strace32 wine" one of the last lines is (i have 512Mb of ram) old_mmap(NULL, 482376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = -1 ENOMEM (Cannot allocate memory) It looks like my kernel absolutly wants to allocate memory > 0xc0000000 :-) Any idea? Thanx Maurizio Please CC answers to monge(at)sns(dot)it, since i'm not subscribed.

4 5

Game Testing Update - 20040505
by Mike Kost 12 Jun '04

12 Jun '04

Here a continuation of my game testing efforts. Same rules still apply in my efforts: All games tested are freely available as demos or F/OSS games on the Internet and they don't work right. I know 20040505 is showing its age, but there isn't a 200406xx yet. Since my last report: - Bugzlla bugs #2128 & #2129 have closed. The problems were self-correcting - 2 More Bugs Filed - - #2276 - Screen refresh/redraw errors in Austerlitz demo - - #2277 - Redraw/refresh errors for Remote Assault demo - Stopped testing The War Engine. I don't want to juggle more than 4 programs at a time and I want to pick up Galactic Civilization. Austerlitz Summary ------------------ Bug #2276 is newly filed and the unhandled exception error is no longer present. There is still a screen redraw error Full report: http://www.tashcorp.net/Wine/Austerlitz/austerlitz-20040505.html Dominions II ------------ No noticable change. Dominions II still has screen redraw errors and mouse errors. Full report: http://www.tashcorp.net/Wine/DominionsII/dominionsII-20040505.html Remote Assault -------------- Remote Assault has started running but has several refresh/redraw errors. There are several new 'err:ddraw' messages: err:ddraw:set_render_state Unhandled dwRenderStateType ... and err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! Full report: http://www.tashcorp.net/Wine/RemoteAssault/remoteassault-20040505.html

1 0

Winrash update
by Chris Morgan 11 Jun '04

11 Jun '04

Just released a new version of winrash. I'm sending this email because after asking people who are running Winrash to send an email to the list or myself , I didn't receive any emails. This isn't usually a problem except when there is an issue with Winrash. I get error reports that have the IDs people put in but no way to contact them. So I added a field in the installer for a contact email. This will be sent along with the clientID when an error report is generated by winrash. In case anyone is curious the web archive for the error reports is here: http://www.winehq.org/hypermail/wine-tests-results/ I'd like to ask that anyone who installed winrash please run the installer again so they can enter a valid contact email. If you are one of those people wondering why your results aren't found at http://test.winehq.org/data/ this will help both of us by letting me get a hold of you ;-) The one change I should mention is the addition of proxy support in the 0008 release. There are a handful of people running behind proxies, I can tell by squid html in what should be the script part of the error reports. This version of the client *should* fix things for you. Thanks to Florian Steinel for the code change. Here is the SF link to the latest client: http://osdn.dl.sourceforge.net/sourceforge/winrash/winrash-0008-chris-msvc.… Thanks to anyone running the testing suite and for the feedback on winrash changes, I appreciate it. Thanks, Chris

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel