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

Re: "Debugging" a password dialog

by Andreas Mohr

Hi, On Sun, Dec 12, 2004 at 01:21:44AM -0800, Walt Ogburn wrote: > Sorry, I was thinking of the debug channels, but I don't know which ones > to use, short of turning on "trace+all." Probably something like +edit,+relay,+string Andreas Mohr

Dec. 13, 2004

Re: Wine test suite (or winrash, don't know which one) - possible way to improve for some persons (with some antivirus or firewall software running)

by Ferenc Wagner

Tero Tamminen <valeo(a)phreaker.net> writes: >> Yes. But will sticking to a fixed directory name (and >> possibly file name) help, or does ZoneAlarm check eg. MD5 >> sums to thwart any countermeasure from our side? Anyway, >> I have the feeling that this should be solved by >> configuring ZoneAlarm instead of throwing in kludges. >> Don't you know if it's possible to disable this warning >> for an application or a directory? > > Actually ZoneAlarm checks MD5 or some other checksum, but > it can also be configured so, that it doesn't care about > those. Fine, so far. This is absolutely needed, no way around. > There is option where I can specify that "Athenticate > program by full path name only"... name says all I see, thanks for the info. > Zonealarm only sees that, these programs are launcehd from > different directory, I will put in a "try this first" directory name, and fall back to "random" names if creating that fails. > they have different checksum, We can't help this, but it shouldn't pose a problem, right? > wine-test-whatever executable has different name (because > date is part of the name), We can change this, too. > At least to my knowledge ZoneAlarm can't be configured > with wildcards, so that it would check only part of the > executable name. What a shame. We'll have to go the "hard" way then. > But anyway, it is okay to me if you don't want to program > temp directories not to be random, I just have to disable > winrash and thus winetests from my win2k3 server. What would be a shame again, we aren't particularly overwhelmed with Win2k3 testers. Hope we can sort it out. In the meantime just disable winrash if it's too disturbing, I'll drop you a note once the necessary changes are in place. -- Regards, Feri.

Dec. 13, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Jonathan Gevaryahu

Eric Pouech <pouech-eric(a)wanadoo.fr> wrote: >To: Anish Mistry <mistry.7(a)osu.edu> >Cc: wine-devel(a)winehq.org >Subject: Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total > Annihilation > >and if you remove the entire line (if (!is_version_nt()) access = >TIMER_ALL_ACCESS;)? >A+ > > >--__--__-- > That doesn't fix the problem here. Still the same trace response... I haven't run it enough times to see if it will still occasionally work with that line altered or removed... I know it does work (without any changes from the version in CVS) about 5% of the time. Jonathan Gevaryahu lord_nightmare(a)users.sf.net

Dec. 13, 2004

Re: [AppDB] php config

by Jeremy Newman

On Mon, 2004-12-13 at 14:02 +0100, Jonathan Ernst wrote: > I forgot to mention that it should be checked if the used config.php > file is using short tags (<?) if it is, it has to be replaced with > longtags (<?php). It was, and now it isn't.

Dec. 13, 2004

Re: A new systray patch

by Mike Hearn

Shachar Shemesh wrote: > Though, if we would want to support shell extensions, I don't see how we > could effectively do it without having it do everything the native > explorer does.... That would be the other reason. But, I think it makes more sense to try and bridge shell extensions to Nautilus/Konqueror rather than reimplement Explorer-the-file-manager. At least, that's what I'd try first. Flip side is I'm not aware of any shell extensions people want to run on Wine, at least, not yet ...

Dec. 13, 2004

Re: VERSION_GetLinkedDllVersion bug fix

by Andreas Mohr

On Mon, Dec 13, 2004 at 03:09:29PM +0100, Ivan Leo Puoti wrote: > > I fixed a bug in ntdll's VERSION_GetLinkedDllVersion which caused it to > > not be able to return any Windows version higher than WIN98. It has now been > > extended for WIN2K, WINXP, and WIN2K3. This function would eventually be > > called any time that kernel's GetVersionEx was called, which is a problem > > for any software requiring a version higher than WIN98, like Visual Basic > > .NET. > If MajorSubsystemVersion is 4 then the OS can never be win2k or higher, so your > patch can't be correct. > The attached patch should fix the bug you found. Compile tested only. Where's the FIXME message for the default case? ;) (things like this are the prime reason this version issue wasn't uncovered for such a long time!) Andreas Mohr

Dec. 13, 2004

Re: A new systray patch

by Holly Bostick

Alexandre Julliard wrote: > >No, I don't see why it implies that it has to do everything the >Windows one does, > Depends on whose perspective you're looking at if from. From a developer perspective, you are able to easily distinguish what invisible Explorer functions need to be replicated and which do not. From a user perspective, Explorer means "the file manager", and that's all it means. They don't know that it provides shell functions like the taskbar and systray (and all the other cruft it provides) unless they happened to be into alternative shells like Litestep or DesktopX while using Windows-- but that's not very likely. So if the Wine "Explorer" is going to be user-visible, it does imply that to some degree, because the user expectation is somewhat radically different from the developer expectation in this respect. From a developer perspective, the file management function is probably the least important of the Explorer functions (since file management can be replicated separately by many means, under both Windows and Linux, as noted), but to the user, it is the *only* function. > but it has to do everything that some apps depend >on. > > > Well, yes, please ;-) . Holly

Dec. 13, 2004

Re: (LPVOID) NULL: unnecessary cast?

by Marcus Meissner

On Mon, Dec 13, 2004 at 02:08:31PM +0100, Francois Gouget wrote: > > I have noticed a lot of constructs of the form: > > HRESULT WINAPI DMUSIC_CreateDirectMusicScriptImpl (LPCGUID lpcGUID, LPVOID* > ppobj, LPUNKNOWN pUnkOuter) { > IDirectMusicScriptImpl* obj; > > obj = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > sizeof(IDirectMusicScriptImpl)); > if (NULL == obj) { > *ppobj = (LPVOID) NULL; > return E_OUTOFMEMORY; > } > > > What's the point of casting NULL to (LPVOID)? Isn't it already a void* > anyway? Is it to fix a warning issued by ultra-recent gcc versions? (gcc > 3.4.2 does not complain here) No, this should work as is. NULL should be able to be assigned to any pointer. > > Similarly there are a lot of casts like this: > > *ppobj = (LPVOID)&This->UnknownVtbl; > Again I thought any kind of pointer could be assigned to a void* > pointer so is this cast really necessary? This is different and needs to be there. Ciao, Marcus

Dec. 13, 2004

Re: A new systray patch

by Shachar Shemesh

Alexandre Julliard wrote: >>Calling it Explorer would imply that it's supposed to do everything >>Windows explorer does, which seems a bit dubious to me. It'd be like >>calling the wineserver the winekernel. >> >> > >No, I don't see why it implies that it has to do everything the >Windows one does, but it has to do everything that some apps depend >on. > > Though, if we would want to support shell extensions, I don't see how we could effectively do it without having it do everything the native explorer does.... Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 13, 2004

(LPVOID) NULL: unnecessary cast?

by Francois Gouget

I have noticed a lot of constructs of the form: HRESULT WINAPI DMUSIC_CreateDirectMusicScriptImpl (LPCGUID lpcGUID, LPVOID* ppobj, LPUNKNOWN pUnkOuter) { IDirectMusicScriptImpl* obj; obj = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectMusicScriptImpl)); if (NULL == obj) { *ppobj = (LPVOID) NULL; return E_OUTOFMEMORY; } What's the point of casting NULL to (LPVOID)? Isn't it already a void* anyway? Is it to fix a warning issued by ultra-recent gcc versions? (gcc 3.4.2 does not complain here) Similarly there are a lot of casts like this: *ppobj = (LPVOID)&This->UnknownVtbl; Again I thought any kind of pointer could be assigned to a void* pointer so is this cast really necessary? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Dec. 13, 2004

Re: [AppDB] php config

by Jonathan Ernst

I forgot to mention that it should be checked if the used config.php file is using short tags (<?) if it is, it has to be replaced with longtags (<?php). thanks, -- Jonathan Ernst <Jonathan(a)ErnstFamily.ch>

Dec. 13, 2004

Re: Includes [4] shlwapi

by Jon Griffiths

Hi, > Well, it's more work for the poor slob who has to review, test, and > commit the resulting patches <g> gulp, I guess thats me, <sniff> ;-) > (not to mention for people who > maintain local changes and need to fix merge conflicts after each > commit). I wondered about that; the good news is that all the diffs are at the very top of the source files, so any existing patches should continue to apply, albeit offset by a line or two. The only real conflict possible is if local changes are messing with the includes (which of course, does/will happen). But of course, everyones future rebuild times after a cvs update will go down as a result, so the net result should be a win :-) Anyway, I've updated my script with the suggestions given and include it below if anyones interested. I will be posting the (much reduced, but still significant) patch very shortly to wine-patches. As mentioned in the script blurb, this only removes headers that don't cause extra warnings or build errors, that actually reduce dependencies, and it won't remove a header that provides a prototype for the function(s) implemented in a source file. As the private includes get cleaned up I'll re-run this once in a while to weed out any more that crop up. 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!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

Dec. 13, 2004

Re: A new systray patch

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > If by explorer you mean things like the taskbar then yes, maybe once > the winedesktop works gets in (I wonder what happened to that) we'll > need some kind of task switcher/shell program. I don't think we need > an entire file browser - there is winefile but who uses it? What is it > for? > There are native file browsers that work well. That's not the reason, the reason is that there are apps that depend on Explorer. It's for the same reason we have Notepad even though there are better native editors. > Calling it Explorer would imply that it's supposed to do everything > Windows explorer does, which seems a bit dubious to me. It'd be like > calling the wineserver the winekernel. No, I don't see why it implies that it has to do everything the Windows one does, but it has to do everything that some apps depend on. -- Alexandre Julliard julliard(a)winehq.org

Dec. 13, 2004

Re: A new systray patch

by Mike Hearn

Alexandre Julliard wrote: > We will sooner or later need an Explorer clone, if only for desktop > mode, and it seems to me it is exactly the right place for the systray > code. If by explorer you mean things like the taskbar then yes, maybe once the winedesktop works gets in (I wonder what happened to that) we'll need some kind of task switcher/shell program. I don't think we need an entire file browser - there is winefile but who uses it? What is it for? There are native file browsers that work well. Calling it Explorer would imply that it's supposed to do everything Windows explorer does, which seems a bit dubious to me. It'd be like calling the wineserver the winekernel. thanks -mike

Dec. 13, 2004

Re: A new systray patch

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > No, I think that'd be misleading. It doesn't explore stuff and never > will, and it may also do other things in future that Explorer > doesn't. It's a rough analogue of Explorer in the same way that the > wineserver is a bit like the Windows kernel. We will sooner or later need an Explorer clone, if only for desktop mode, and it seems to me it is exactly the right place for the systray code. -- Alexandre Julliard julliard(a)winehq.org

Dec. 13, 2004

Re: A new systray patch

by Mike Hearn

Steven Edwards wrote: > Maybe we should just go ahead and call it explorer in case you plan on adding stuff later on or > adapting parts of ReactOS explorer. No, I think that'd be misleading. It doesn't explore stuff and never will, and it may also do other things in future that Explorer doesn't. It's a rough analogue of Explorer in the same way that the wineserver is a bit like the Windows kernel.

Dec. 13, 2004

Re: winsock:WS_setsockopt

by Rein Klazes

On Sun, 12 Dec 2004 21:35:44 +0200, you wrote: > Well, if the setting is win98 instead of win2k, than the output differs > a little. The program tries to connect to a http server and gets the > HEAD of the server / page. That's what's actually doing. Right now it > just fails, i.e. no connection, so there is one (even iexplore connects > happily). It connects here and receives plenty of data (some 30kB before I shut the program up). Sound does not work under wine here ATM ( a kernel problem I think), but communication is OK as far as I can tell. Run wine as WINEDEBUG=+winsock wine ... to follow the communication activity. (I have win version set as winxp btw, for no particular reason) > > I think this is a problem of the ?Unimplemented or unknown socket level? > and returns a error. This is what the program checks. So if it could > fetch the HEAD of the server, everything would be fine, if not, it > sounds the alarm. I don't think the program checks that. To be sure, edit dlls/winsock/socket.c. Around line 2469, you will find the "invalid level ..." message. Change the following "return SOCKET_ERROR;" by "return 0;" and recompile. > > I tried contacting the author, but no reply as of now....Maybe we can > just satisfy the program in an other way, i.e. return it a socket? Any > ideas? Look for other failures then these errors (eg. in the +winsock log). The programs seems to want to run from the systray, you may want to try the last patch that Mike Hearn has uploaded to wine-patches. Rein.

Dec. 13, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Eric Pouech

and if you remove the entire line (if (!is_version_nt()) access = TIMER_ALL_ACCESS;)? A+

Dec. 13, 2004

Re: Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Jonathan Gevaryahu

On Sunday 12 December 2004 02:54 pm, Eric Pouech wrote: > Jonathan Gevaryahu a écrit : > does this help? > A+ > > Index: sync.c > =================================================================== > RCS file: /home/cvs/cvsroot/wine/wine/dlls/kernel/sync.c,v > retrieving revision 1.64 > diff -u -u -r1.64 sync.c > --- sync.c 7 Dec 2004 14:23:03 -0000 1.64 > +++ sync.c 12 Dec 2004 19:53:14 -0000 > @@ -893,7 +893,7 @@ > OBJECT_ATTRIBUTES attr; > NTSTATUS status; > > - if (!is_version_nt()) access = SEMAPHORE_ALL_ACCESS; > + if (!is_version_nt()) access = TIMER_ALL_ACCESS; > > attr.Length = sizeof(attr); > attr.RootDirectory = 0; Unfortunately, your patch doesn't fix the problem. But I noticed something disturbing: in CVS (without your patch) occasionally Total Annihilation will run fine (it did ONCE), but almost all of the time it will not work, and give the previously mentioned trace result. Sometimes, it will give a different trace result: ... 000d: select() = PENDING warn:file:wine_nt_to_unix_file_name L"units\\CORDEV1.OVR" not found in /home/jon athan/.wine/dosdevices/g:/cavedog/totala/units warn:ntdll:NtCreateFile L"\\??\\G:\\cavedog\\totala\\units\\CORDEV1.OVR" not fou nd (c000003a) warn:file:CreateFileW Unable to create file L"units\\CORDEV1.OVR" (status c00000 3a) trace:ntdll:NtCreateFile handle=0x4087f7a4 access=80000000 name=L"\\??\\G:\\cave dog\\totala\\units-english\\CORDOOM.FBI" objattr=00000042 root=(nil) sec=(nil) i o=0x4087f7a8 alloc_size=(nil) attr=00000080 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102914722.834956 (+0.003836) , handles={0x110} ) 000d: select() = PENDING warn:file:wine_nt_to_unix_file_name L"units-english\\CORDOOM.FBI" not found in / home/jonathan/.wine/dosdevices/g:/cavedog/totala warn:ntdll:NtCreateFile L"\\??\\G:\\cavedog\\totala\\units-english\\CORDOOM.FBI" not found (c000003a) warn:file:CreateFileW Unable to create file L"units-english\\CORDOOM.FBI" (statu s c000003a) trace:ntdll:NtCreateFile handle=0x4087f7c8 access=80000000 name=L"\\??\\G:\\cave dog\\totala\\units\\CORDOOM.FBI" objattr=00000042 root=(nil) sec=(nil) io=0x4087 f7cc alloc_size=(nil) attr=00000080 sharing=00000003 disp=1 options=00000050 ea=(nil).0x00000000 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102914722.844670 (+0.005838) , handles={0x110} ) 000d: select() = PENDING warn:file:wine_nt_to_unix_file_name L"units\\CORDOOM.FBI" not found in /home/jon athan/.wine/dosdevices/g:/cavedog/totala/units warn:ntdll:NtCreateFile L"\\??\\G:\\cavedog\\totala\\units\\CORDOOM.FBI" not fou nd (c000003a) 000a: event_op( handle=0xc0, op=1 ) 000a: event_op() = 0 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102914722.854135 (+0.007851) , handles={0x110} ) 000d: select() = PENDING warn:file:CreateFileW Unable to create file L"units\\CORDOOM.FBI" (status c00000 3a) 0009: get_handle_fd( handle=0xec, access=00000000 ) 0009: get_handle_fd() = 0 { fd=24, flags=0 } trace:ntdll:NtReadFile (0xec,(nil),(nil),(nil),0x4087f80c,0x44404668,0x00000200, (nil),(nil)),partial stub! 0009: get_handle_fd( handle=0xec, access=80000000 ) 0009: get_handle_fd() = 0 { fd=24, flags=0 } 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102914722.864331 (+0.009845) , handles={0x110} ) 000d: select() = PENDING trace:ntdll:NtReadFile = 0x00000000 0009: get_handle_fd( handle=0xec, access=00000000 ) 0009: get_handle_fd() = 0 { fd=24, flags=0 } trace:ntdll:NtReadFile (0xec,(nil),(nil),(nil),0x4087f414,0x4506cf40,0x00000200, (nil),(nil)),partial stub! 0009: get_handle_fd( handle=0xec, access=80000000 ) 0009: get_handle_fd() = 0 { fd=24, flags=0 } trace:ntdll:NtReadFile = 0x00000000 trace:ntdll:NtReadFile (0xec,(nil),(nil),(nil),0x4087f404,0x44404668,0x00000200, (nil),(nil)),partial stub! ... And that trace means that it was actually working. If I hadn't Control-C terminated that trace, it would have run the game. Jonathan Gevaryahu lord_nightmare(a)users.sf.net

Dec. 12, 2004

Re: A new systray patch

by Steven Edwards

Hi, --- Mike Hearn <mh(a)codeweavers.com> wrote: > - Add a wineshell process to stand in for Explorer > - Rewrite system tray code to be standards compliant Maybe we should just go ahead and call it explorer in case you plan on adding stuff later on or adapting parts of ReactOS explorer. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

Dec. 12, 2004

Baldur's Gate 2 randomly crashes ("Runtime error") with Wine-20041201

by Michal Kepien

Hi there, I've recently compiled Wine-20041201 and I'm trying to get Baldur's Gate II running. The installation sequence is fine, so is the main menu, character creation etc. The problem is, once inside the actual game, the application randomly crashes giving me: Runtime error c:\bg2\BGMain.exe abnormal program termination This happens often enough to render the gameplay quite unnerving. Especially when it happens 15 minutes after the last quicksave ;-) I haven't found out what makes the game crash. I'm quite sure it isn't a sound problem - I've turned sound off both in ~/.wine/config and in BGConfig.exe - not better at all. The only clue I've got is the message which appears in the system console after the game quits: err:ntdll:RtlpWaitForCriticalSection section 0x40689020 "?" wait timed out in thread 000f, blocked by 0009, retrying (60 sec) Whatever it means ;-) The same thing happened in Wine-20041019. I'd be grateful for any clues as right now I'm quite fed up with restarting the game every 3 minutes (or even worse). If you need any more debug messages, just ask. System specification: Toshiba Satellite Pro 4270 - Celeron 500, Savage/IX (8 MB), Yamaha sound card, 320 MB RAM. Slackware 10.0, kernel 2.4.27. X.org - 6.8.1.99 (CVS), CVS Savage driver. ALSA sound driver, using OSS emulation. Window manager: Fluxbox v0.9.10. Thanks in advance for any support, Michal Kepien

Dec. 12, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Anish Mistry

On Sunday 12 December 2004 02:54 pm, Eric Pouech wrote: > Jonathan Gevaryahu a écrit : > does this help? > A+ > > Index: sync.c > =================================================================== > RCS file: /home/cvs/cvsroot/wine/wine/dlls/kernel/sync.c,v > retrieving revision 1.64 > diff -u -u -r1.64 sync.c > --- sync.c 7 Dec 2004 14:23:03 -0000 1.64 > +++ sync.c 12 Dec 2004 19:53:14 -0000 > @@ -893,7 +893,7 @@ > OBJECT_ATTRIBUTES attr; > NTSTATUS status; > > - if (!is_version_nt()) access = SEMAPHORE_ALL_ACCESS; > + if (!is_version_nt()) access = TIMER_ALL_ACCESS; > > attr.Length = sizeof(attr); > attr.RootDirectory = 0; I'm still seeing the same error on my system: 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x67f53c, timeout=0, handles={0x2114} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x67f53c, timeout=0, handles={0x2114} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x67f53c, timeout=0, handles={0x2114} ) 0009: select() = ACCESS_DENIED -- Anish Mistry

Dec. 12, 2004

Re: winsock:WS_setsockopt

by MediaHost (TM)

Sure! The URL is http://www.lanwatch.da.ru/ and it's free... Dan Kegel wrote: > You wrote: > >>... the program is "Lanwatch". A nice little app, which makes a lot of > >>noise (if configured correctly) when the Internet connection goes down. > >>I used it for years, but now we've got rid of the last Windows here.... > >> > >>I have other network monitoring tools, but it's just the acoustical > >>waring, for which I used it...I'll just attach it to the mail, OK? > > Do you have a URL for lanwatch, or a few more details that would let us > identify it (e.g. vendor name, version number)? > (There may be several programs by that name.) > Is there a free demo download? > - Dan > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/>

Dec. 12, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Eric Pouech

Jonathan Gevaryahu a écrit : does this help? A+ Index: sync.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/kernel/sync.c,v retrieving revision 1.64 diff -u -u -r1.64 sync.c --- sync.c 7 Dec 2004 14:23:03 -0000 1.64 +++ sync.c 12 Dec 2004 19:53:14 -0000 @@ -893,7 +893,7 @@ OBJECT_ATTRIBUTES attr; NTSTATUS status; - if (!is_version_nt()) access = SEMAPHORE_ALL_ACCESS; + if (!is_version_nt()) access = TIMER_ALL_ACCESS; attr.Length = sizeof(attr); attr.RootDirectory = 0;

Dec. 12, 2004

Re: winsock:WS_setsockopt

by MediaHost (TM)

Well, if the setting is win98 instead of win2k, than the output differs a little. The program tries to connect to a http server and gets the HEAD of the server / page. That's what's actually doing. Right now it just fails, i.e. no connection, so there is one (even iexplore connects happily). I think this is a problem of the ?Unimplemented or unknown socket level? and returns a error. This is what the program checks. So if it could fetch the HEAD of the server, everything would be fine, if not, it sounds the alarm. I tried contacting the author, but no reply as of now....Maybe we can just satisfy the program in an other way, i.e. return it a socket? Any ideas? Rein Klazes wrote: >On Sun, 12 Dec 2004 12:42:55 +0200, you wrote: > > > >>It's a little bit...embracing :-) >> >>But the program is "Lanwatch". A nice little app, which makes a lot of >>noise (if configured correctly) when the Internet connection goes down. >>I used it for years, but now we've got rid of the last Windows here.... >> >>I have other network monitoring tools, but it's just the acoustical >>waring, for which I used it...I'll just attach it to the mail, OK? >> >>It would be great, if there could be a fix for this....Also I contacted >>the writer of the little app, but didn't got a answer... >> >>I think, that it just tries to open a socket (with correct or wrong >>parameters), and than gets a back a error and reports (wrongly) that the >>Internet connection is down...It might be easy to fix (or hack >>workaround) for it, just if you can lead me to the solution? >> >> > >| fixme:winsock:convert_sockopt Unimplemented or unknown socket level >| err:winsock:WS_setsockopt Invalid level (65407) or optname (128) >| fixme:mpr:WNetGetUniversalNameA ("K:\\", 0x00000001, 0x779cf98c, 0x779cfd98): stub >| fixme:winsock:convert_sockopt Unimplemented or unknown socket level >| err:winsock:WS_setsockopt Invalid level (65407) or optname (128) >| fixme:winsock:convert_sockopt Unknown SOL_SOCKET optname 0xff7f >| err:winsock:WS_setsockopt Invalid level (1) or optname (65407) > >The same output as Space Empires 4. The unknown optname 65407 or 0xff7f, >is suspiciously looking like the option SO_DONT_LINGER, 0xffffff7f, with >the high bits chopped off. Both these calls fail under Windows (win2K). > >It is a good idea to ask the programmer, to see what he is trying to >accomplish here. > >Also note that these errors may not be fatal at all if the program is >just ignoring them. Letting the program going through I see a fair bit >of data exchange, so communications seems to work, at least partly. > >Rein. > > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/>

Dec. 12, 2004

Re: winsock:WS_setsockopt

by Dan Kegel

You wrote: >>... the program is "Lanwatch". A nice little app, which makes a lot of >>noise (if configured correctly) when the Internet connection goes down. >>I used it for years, but now we've got rid of the last Windows here.... >> >>I have other network monitoring tools, but it's just the acoustical >>waring, for which I used it...I'll just attach it to the mail, OK? Do you have a URL for lanwatch, or a few more details that would let us identify it (e.g. vendor name, version number)? (There may be several programs by that name.) Is there a free demo download? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Dec. 12, 2004

Re: Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Anish Mistry

On Sunday 12 December 2004 10:59 am, Jonathan Gevaryahu wrote: > The CVS commit on 12/02 at 18:05:37 UTC causes the game "Total > Annihilation" to cease functioning. Previously the game worked (although > sounds don't work due to a seperate directsound issue), but since the > aformentioned commit, the game changes resolution but does not ever > display its titlescreen (it isn't invisible either, clicking where the > exit button would be has no effect), and cpu usage is maxed out, > suggesting an infinite loop. > > I did a trace using > WINEDEBUG="err+all,warn+all,fixme+all,trace+ntdll,trace+kernel,trace+ser >ver" and got the following, repeated over and over with some small > variation: ... > 0009: select() = ACCESS_DENIED > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102866572.849273 > (+0.002667) > , handles={0x10c} ) > 000d: select() = PENDING > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 000a: event_op( handle=0xc0, op=1 ) > 000a: event_op() = 0 > 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102866572.859131 > (+0.005230) > , handles={0x10c} ) > 000d: select() = PENDING > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) > 0009: select() = ACCESS_DENIED > 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 > ... > > This was tested on both normal and modified (no-CD crack) versions of > total annihilation, and no difference in behavior was noted. > > Here is the information about the commit in question: > > CVS Commit 12/02 18:05:37 message: > Eric Pouech <pouech-eric(a)wanadoo.fr> > - moved event, semaphore, mutex implementation from kernel32 to ntdll > - added mutant implementation in ntdll, and use it for mutex > implementation in kernel32 > - added access parameter on event, semaphore, timer creation in > wineserver (as ntdll interface requires it) > - added missing definitions in include/winternl.h > > Files modified by commit: > dlls/kernel/sync.c > dlls/ntdll/ntdll.spec > dlls/ntdll/sync.c > include/winternl.h > include/wine/server_protocol.h > server/event.c > server/mutex.c > server/protocol.def > server/semaphore.c > server/timer.c > server/trace.c > Ditto. This kills warcraft3 and diablo2 on my FreeBSD system too. Same errors. -- Anish Mistry

Dec. 12, 2004

Re: [AppDB] login problem

by Jonathan Ernst

Thanks for the tip Jeremy. Chris Morgan and myself don't have this problem locally this was tested using php 4.3.9 and php 5.x Tony Lambregts has the same version of php as the online server 4.2.2 and has the same problem. After a lot of testingand googling he found out that he had an extra carriage return at the end of his includes/config.php file and thus there was a problem with the sessions (because headers cannot be sent). Could you check if the config.php has an extra carriage return ? If not, could you maybe enable error reporting to see if php is trowing some errors about sessions or cookies. Thank you. Le dimanche 12 décembre 2004 à 11:14 -0600, Jeremy Newman a écrit : > On Sat, 2004-12-11 at 18:52, Jonathan Ernst wrote: > > Finally there are still some register_globals to clean up and when we > > are done we can turn off the following options in php.ini: > > short_open_tag = Off > > session.bug_compat_42 = 0 > > register_globals = Off > > register_long_arrays = Off > > Actually, you can add: > php_value register_globals 0 > to .htaccess to disable it per site. > > Just a tip. > > > >

Dec. 12, 2004

Re: [AppDB] login problem

by Jeremy Newman

On Sat, 2004-12-11 at 18:52, Jonathan Ernst wrote: > Finally there are still some register_globals to clean up and when we > are done we can turn off the following options in php.ini: > short_open_tag = Off > session.bug_compat_42 = 0 > register_globals = Off > register_long_arrays = Off Actually, you can add: php_value register_globals 0 to .htaccess to disable it per site. Just a tip.

Dec. 12, 2004

Re: winsock:WS_setsockopt

by Rein Klazes

On Sun, 12 Dec 2004 12:42:55 +0200, you wrote: > It's a little bit...embracing :-) > > But the program is "Lanwatch". A nice little app, which makes a lot of > noise (if configured correctly) when the Internet connection goes down. > I used it for years, but now we've got rid of the last Windows here.... > > I have other network monitoring tools, but it's just the acoustical > waring, for which I used it...I'll just attach it to the mail, OK? > > It would be great, if there could be a fix for this....Also I contacted > the writer of the little app, but didn't got a answer... > > I think, that it just tries to open a socket (with correct or wrong > parameters), and than gets a back a error and reports (wrongly) that the > Internet connection is down...It might be easy to fix (or hack > workaround) for it, just if you can lead me to the solution? | fixme:winsock:convert_sockopt Unimplemented or unknown socket level | err:winsock:WS_setsockopt Invalid level (65407) or optname (128) | fixme:mpr:WNetGetUniversalNameA ("K:\\", 0x00000001, 0x779cf98c, 0x779cfd98): stub | fixme:winsock:convert_sockopt Unimplemented or unknown socket level | err:winsock:WS_setsockopt Invalid level (65407) or optname (128) | fixme:winsock:convert_sockopt Unknown SOL_SOCKET optname 0xff7f | err:winsock:WS_setsockopt Invalid level (1) or optname (65407) The same output as Space Empires 4. The unknown optname 65407 or 0xff7f, is suspiciously looking like the option SO_DONT_LINGER, 0xffffff7f, with the high bits chopped off. Both these calls fail under Windows (win2K). It is a good idea to ask the programmer, to see what he is trying to accomplish here. Also note that these errors may not be fatal at all if the program is just ignoring them. Letting the program going through I see a fair bit of data exchange, so communications seems to work, at least partly. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 12, 2004

Wine regression caused by 12/02 18:05:37 UTC commit: breaks Total Annihilation

by Jonathan Gevaryahu

The CVS commit on 12/02 at 18:05:37 UTC causes the game "Total Annihilation" to cease functioning. Previously the game worked (although sounds don't work due to a seperate directsound issue), but since the aformentioned commit, the game changes resolution but does not ever display its titlescreen (it isn't invisible either, clicking where the exit button would be has no effect), and cpu usage is maxed out, suggesting an infinite loop. I did a trace using WINEDEBUG="err+all,warn+all,fixme+all,trace+ntdll,trace+kernel,trace+server" and got the following, repeated over and over with some small variation: ... 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102866572.849273 (+0.002667) , handles={0x10c} ) 000d: select() = PENDING 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 000a: event_op( handle=0xc0, op=1 ) 000a: event_op() = 0 000d: select( flags=12, cookie=0x44f7f4a0, timeout=1102866572.859131 (+0.005230) , handles={0x10c} ) 000d: select() = PENDING 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 0009: select( flags=4, cookie=0x4087f794, timeout=0, handles={0x10} ) 0009: select() = ACCESS_DENIED 000d: *wakeup* signaled=258 cookie=0x44f7f4a0 ... This was tested on both normal and modified (no-CD crack) versions of total annihilation, and no difference in behavior was noted. Here is the information about the commit in question: CVS Commit 12/02 18:05:37 message: Eric Pouech <pouech-eric(a)wanadoo.fr> - moved event, semaphore, mutex implementation from kernel32 to ntdll - added mutant implementation in ntdll, and use it for mutex implementation in kernel32 - added access parameter on event, semaphore, timer creation in wineserver (as ntdll interface requires it) - added missing definitions in include/winternl.h Files modified by commit: dlls/kernel/sync.c dlls/ntdll/ntdll.spec dlls/ntdll/sync.c include/winternl.h include/wine/server_protocol.h server/event.c server/mutex.c server/protocol.def server/semaphore.c server/timer.c server/trace.c Jonathan Gevaryahu lord_nightmare(a)users.sf.net

Dec. 12, 2004

Re: Wine test suite (or winrash, don't know which one) - possible way to improve for some persons (with some antivirus or firewall software running)

by Tero Tamminen

> Yes. But will sticking to a fixed directory name (and > possibly file name) help, or does ZoneAlarm check eg. MD5 > sums to thwart any countermeasure from our side? Anyway, I > have the feeling that this should be solved by configuring > ZoneAlarm instead of throwing in kludges. Don't you know if > it's possible to disable this warning for an application or > a directory? Actually ZoneAlarm checks MD5 or some other checksum, but it can also be configured so, that it doesn't care about those. There is option where I can specify that "Athenticate program by full path name only"... name says all (tried it, but in this case, it doesn't help because programs are launched from different directories). I think it was sometime called "This program changes frequently" but maybe I am not remembering it correctly, or it was somewhere else. It is possible to disable the warning by application. But because ZoneAlarm thinks these programs are different, it isn't. Zonealarm only sees that, these programs are launcehd from different directory, they have different checksum, wine-test-whatever executable has different name (because date is part of the name), ZoneAlarm doesn't see same program. At least to my knowledge ZoneAlarm can't be configured with wildcards, so that it would check only part of the executable name. But anyway, it is okay to me if you don't want to program temp directories not to be random, I just have to disable winrash and thus winetests from my win2k3 server. Thanks -- Tero Tamminen Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.

Dec. 12, 2004

Re: Visual studio 6 build fix.

by Rein Klazes

On Sun, 12 Dec 2004 14:02:54 +0100, you wrote: > > Is this one acceptable? > > > > If there is still a problem, then I need more hints to what is needed. > the only part which is questionnable is as follows: > - what happens (in your case) if the child (after being run through all the > init) calls FreeConsole and then AllocConsole? > - I don't know the answer. The patch will let the new standard handles be still > the ones the child as inherited, while it could be the ones allocated by > AllocConsole. > I don't know the answer for sure (my wild guess would be the second), but that > requires testing (and a proper test case for winetest wouldn't hurt of course). > If I'm right, then you should keep AllocConsole as it is and in > dlls/kernel/kernel_main.c set the default handles to what's inherited after > calling AllocConsole That makes sense. I will have a look into it. Rein.

Dec. 12, 2004

Re: ntdll / kernel32: #52

by Eric Pouech

> Oops, sorry for the confusion then. I didn't really look at the code, > only was reading your comments and was under impression that was the > case. Sorry again. Do you know how NT handles that? I'd say local & global are really the same stuff, both reside in kernel space, but the second is shared across process while the first isn't. A+

Dec. 12, 2004

Re: ntdll / kernel32: #52

by Dmitry Timoshkov

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > > Moving local atom support to wineserver makes it also a lot slower, > > and that's not acceptable IMO. > > > local atom is already in wineserver (before the patch) ;-) > only 16 bit atom is in kernel Oops, sorry for the confusion then. I didn't really look at the code, only was reading your comments and was under impression that was the case. Sorry again. Do you know how NT handles that? -- Dmitry.

Dec. 12, 2004

Re: ntdll / kernel32: #52

by Eric Pouech

Dmitry Timoshkov a e'crit : > Moving local atom support to wineserver makes it also a lot slower, > and that's not acceptable IMO. > local atom is already in wineserver (before the patch) ;-) only 16 bit atom is in kernel A+

Dec. 12, 2004

Re: ntdll / kernel32: #52

by Dmitry Timoshkov

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > > Rtl* functions should generally avoid doing server calls. You should > > implement the Rtl* functions on top of the Nt* functions, not the other > > way around. > the "real" fix would mean (which I decided not to implement) > - not moving local atom tables to wineserver (and handling them in the local memory) > - that would by the way allow to use the internal representation of local atom > tables > - then, just Nt atom related functions would call wineserver Moving local atom support to wineserver makes it also a lot slower, and that's not acceptable IMO. -- Dmitry.

Dec. 12, 2004

Re: Visual studio 6 build fix.

by Eric Pouech

> Is this one acceptable? > > If there is still a problem, then I need more hints to what is needed. the only part which is questionnable is as follows: - what happens (in your case) if the child (after being run through all the init) calls FreeConsole and then AllocConsole? - I don't know the answer. The patch will let the new standard handles be still the ones the child as inherited, while it could be the ones allocated by AllocConsole. I don't know the answer for sure (my wild guess would be the second), but that requires testing (and a proper test case for winetest wouldn't hurt of course). If I'm right, then you should keep AllocConsole as it is and in dlls/kernel/kernel_main.c set the default handles to what's inherited after calling AllocConsole A+

Dec. 12, 2004

Re: Fwd: Foobar2000 audio player Regression

by nx12

On vie, 2004-12-10 at 10:37 +0100, Paul van Schayck wrote: > A regression test showed the "menu not being drawed" issue was caused > by this patch: > http://cvs.winehq.org/patch.py?id=14371 > http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html Reverting this patch helped me with foobar. Thank you, Paul. Hope this will be fixed in next wine release. -- Regards nx12

Dec. 12, 2004

Re: winsock:WS_setsockopt

by Rein Klazes

On Sat, 11 Dec 2004 12:55:49 +0200, you wrote: > Hi Wine-Devel, > > Is here anybody which knows what the following function is supposed to > do and what needs to get implemented? I'm referring to this: > > fixme:winsock:convert_sockopt Unimplemented or unknown socket level > err:winsock:WS_setsockopt Invalid level (65407) or optname (128) Which program is this? I have seen this message before. I concluded then it was a bug in the program not a problem with wine. But if more applications do this .... Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 12, 2004

Re: Visual studio 6 build fix.

by Rein Klazes

On 10 Dec 2004 15:14:30 +0100, you wrote: > Rein Klazes <wijn(a)wanadoo.nl> writes: > > > @@ -210,7 +212,12 @@ static int set_process_console( struct p > > if (process->create_flags & CREATE_NEW_CONSOLE) > > { > > /* let the process init do the allocation */ > > - return 1; > > + /* unless the startup info specifies to use */ > > + /* the io handles in the startup info */ > > + if( !info || !info->data || > > + !((((RTL_USER_PROCESS_PARAMETERS *)info->data)->dwFlags) & > > + STARTF_USESTDHANDLES)) > > + return 1; > > The server must not know about the process parameters structure, the > STARTF_USESTDHANDLES flag has to be handled on the client side. Is this one acceptable? If there is still a problem, then I need more hints to what is needed. Rein.

Dec. 12, 2004

Re: "Debugging" a password dialog

by Walt Ogburn

Sorry, I was thinking of the debug channels, but I don't know which ones to use, short of turning on "trace+all." - Walter On Sat, 11 Dec 2004, David [iso-8859-1] G�mbel wrote: > On Samstag 11 Dezember 2004 01:42, Walt Ogburn wrote: > > Dump a trace into a file, then grep for the username and password you > > entered? > > Are you refering to using something like strace, or would you use a debug > channel? If a debug channel, which ?-) > > > > Bye, and thanks for your input! > > > David > >

Dec. 12, 2004

Re: [AppDB] login problem

by Jonathan Ernst

I noticed that if I put: session.use_cookies = 0 In my php.ini I cannot login and the behaviour is the same as the one on the website. maybe someone could check if the online server configuration has changed. Tony could you check if you have this option enabled or not on your local server ?

Dec. 11, 2004

[AppDB] login problem

by Jonathan Ernst

Hi guys, It's nearly 2 o'clock and I have to wake up early "tomorrow". I made a very big patch that cleans up a lot of code (thousands of tabs, bad indentation, etc. and follows the CODING_STANDARD we wrote together. Of course I didn't had time to clean up every single line of code (I didn't wanted to use any automated mean to do the cleanup to avoid problems). As for the login problem I re-read most of the code and I runned it with all compatibility options turned off and all warnigns turned on and it works very well on my local system. I think there is still one $current occurence somewhere but the problem doesn't come from here. As for the online version that doesn't work, I think that first thing would be to put a test page on the server with phpinfo() in it to know exactly what version of php and what options we are using. Then we have to understand why in function cmd_do_login() of file account.php we have something like: if($result == null) { $_SESSION['current'] = $user; addmsg("You are successfully logged in as '$user->username'.", "green"); redirect(apidb_fullurl("index.php")); } else { retry("login","Login failed ($result)"); $_SESSION['current'] = ""; } And when providing a wrong password we get the error message and when providing a good password we get no message at all ! The reason why it's buggy online and works locally using the latest cvs versions is still to be found... Finally there are still some register_globals to clean up and when we are done we can turn off the following options in php.ini: short_open_tag = Off session.bug_compat_42 = 0 register_globals = Off register_long_arrays = Off P.S. I send a copy to wine-devel in case someone finds out the solution before us.

Dec. 11, 2004

Re: "Debugging" a password dialog

by David Gümbel

On Samstag 11 Dezember 2004 01:42, Walt Ogburn wrote: > Dump a trace into a file, then grep for the username and password you > entered? Are you refering to using something like strace, or would you use a debug channel? If a debug channel, which ?-) Bye, and thanks for your input! David

Dec. 11, 2004

Re: msacm: pcm compatibility patch

by Mike Hearn

On Sat, 11 Dec 2004 09:29:21 -0500, Robert Reif wrote: > The Microsoft code will not read and/or > write the entire contents of the buffers under some > circumstances. Duplicating this behavior lead to the code I > have presented. What bugs did this behaviour cause? If it's purely a matter of correctness with no known negative side-effects I'm not sure it should go in ...

Dec. 11, 2004

Re: "Debugging" a password dialog

by David Gümbel

On Samstag 11 Dezember 2004 02:09, Robert Shearman wrote: > David Gümbel wrote: > >I am trying to get an application to run under Wine that requires a > > login with a username and a password. The program runs all fine, > > however I can't login with data that should work (and AFAIK works under > > Windows). > > > >Having entered the password, in the corresponding part of the dialog I > > only see "*****" (which is correct). However, when I change focus to > > some other part of that dialog afterwards, the password field shows > >"*************" (way more asterisks than before). The previous (i.e. > >correct) length of ****s is restored when setting the focus back onto > > the password field. > > Are you sure this isn't a security feature of the program? Does the > program exhibit this behaviour in Windows? I don't think so, no, but I'll check again. I am, however, pretty sure this is not a feature. > >I have reason to believe that the password I entered is not correctly > > passed on to the login procedure of the program. However, I am sort of > > badly lacking a nice idea how to efficiently debug this thingy and > > verify (falsify ;) that I'm right. So, does anybody have an idea? > > It is unlikely, but not impossible to be a bug in the edit control. That > code has been around for ages and is well tested, but then again this > program could be using some really weird side effects. I would look > elsewhere though. OK, that sounds a lot like I was wrong assuming the problem is in the password dialog ;) > What is the password being checked against? Is it > going over the network? Is it reading in a file off the disk and > processing it? Is it using cryptography functions? Answering these will > give you some clues with which to start debugging with. The password is (I think) stored in a database file on disk. There's no networking involved at all, and I don't believe there's crypto being used. I'll try to look elsewhere now, that is - not in the dialog part of the system. Thank you for you input, I appreciate it. Bye, David

Dec. 11, 2004

Re: BeginPaint not called on WM_PAINT

by Mike Hearn

On Sat, 11 Dec 2004 11:28:21 -0600, Robert Shearman wrote: > Then that means there was already some problem with the app that has now > been exposed. We should find out why the app isn't calling BeginPaint > like it should. Actually the code that printed that warning was removed in a recent patch.

Dec. 11, 2004

Re: include file cleanup : another step

by Rémi Assailly

Robert Shearman wrote : > Nice try, but I don't think we want three copies of the same defines. > That's just asking for trouble with them getting out of sync. > > Rob I thought we do not have to change these values. OK, I have to find something else...

Dec. 11, 2004

Re: dlls/gdi/tests/metafile.c warning about test_mf_PatternBrush

by Gerald Pfeifer

On Thu, 9 Dec 2004, Walt Ogburn wrote: > It's commented out because the test currently crashes under Wine. I > submitted one patch earlier, but the metafile records weren't the same as > the correct Windows values and it didn't get committed. Now that there's > a test I'll work on another patch. Cool, thanks. There was also the question on similar warnings, and indeed the following three have remained unaddressed for probably more than half a year: rtlstr.c:552: warning: `test_RtlUpcaseUnicodeChar' defined but not used rtlstr.c:578: warning: `test_RtlUpcaseUnicodeString' defined but not used rtlstr.c:629: warning: `test_RtlDowncaseUnicodeString' defined but not used Gerald

Dec. 11, 2004