August 2002 - Wine-Devel - list.winehq.org

ReactOS PSAPI released as LGPL

by Steven Edwards

Hi all. To help share code with WINE I have asked some of the ReactOS developers to license thier work as LGPL where possible. ReactOS is distributed under the GPL with certain sources being LGPL or X11/BSD. In case anyone wants to work on PSAPI in wine feel free to leech whatever. I will keep wine-devel up to date if anything else is relicensed. CVSROOT: /CVS/ReactOS Module name: reactos Repository: reactos/lib/psapi/misc/ Changes by: hyperion(a)mok.lvcm.com 02/08/31 08:36:56 Modified files: reactos/lib/psapi/misc/: dllmain.c malloc.c win32.c reactos/lib/psapi/: psapi.def psapi.edf reactos/lib/psapi/enum/: module.c process.c reactos/lib/psapi/include/internal/: psapi.h reactos/lib/psapi/: makefile psapi.def psapi.edf reactos/lib/psapi/misc/: stubs.c win32.c Log message: PSAPI: all the annoying stuff (enumeration and search, basically) has been taken care of. Only profiling remains to be implemented. PSAPI (re)licensed under LGPL to be shared with WinE, as per Steven's request. Interfaces (headers and import library definitions) and trivial sources put in the public domain Check out the subsystem-independent routines in enum/ (FWIW: the whole DLL only imports two calls from kernel32.dll, SetLastError and AreFileApisANSI): they've been tested, and they could make for a great static library, to implement task manager, tlist, ToolHelp API, etc. Maybe a future addition to mingwnt? __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 31, 2002

Re: removing mp3 code

by Igor Izyumin

On Saturday 31 August 2002 02:02 pm, Shachar Shemesh wrote: > Eric Pouech wrote: > >my point is: > >- a company X has an audio player for Win32 > >- company X ports its app to Wine using the wine source, and it's mp3 > >player and makes a closed package of it > >- it'll have to pay for the license > >so I think this has to be documented somehow > > > >A+ > > Isn't it always the case with Open Source software that, when you want > to repackage a piece of code, patent licensing requirements are yours to > figure out and comply? Why is this case any different than the Unisys > LZW patent, when free (bear) implementations were free of charge? Well, yes, but it should probably be disclosed somewhere in the readme and/or the license file. You don't want people to encounter this after they've ported and released stuff, right? Wine is not legally OBLIGATED to find patent dependencies, but I think that developers should make an effort to document known/possible patent issues. It's not that hard, just put a notice in the documentation somewhere. Note: I am not a lawyer, so this is just my opinion and not legal advice. -- -- Igor

Aug. 31, 2002

Re: removing mp3 code

by Shachar Shemesh

Eric Pouech wrote: >my point is: >- a company X has an audio player for Win32 >- company X ports its app to Wine using the wine source, and it's mp3 >player and makes a closed package of it >- it'll have to pay for the license >so I think this has to be documented somehow > >A+ > > > Isn't it always the case with Open Source software that, when you want to repackage a piece of code, patent licensing requirements are yours to figure out and comply? Why is this case any different than the Unisys LZW patent, when free (bear) implementations were free of charge? Shachar

Aug. 31, 2002

Re: quartz.dll

by Gavriel State

Hidenori, I have sent you a private reply to the above address. Since it has the appearance of a temporary address that you might not check, I am replying here as well to let you know. If there is a better address for me to reach you at, please feel free to send it to me. The quick summary: I have an idea that may be able to provide you with protection against the liability that you believe exists. Thanks, -Gav Hidenori Takeshima wrote: > I'm original developer of quartz. > I don't want my quartz code to be restored. > > There seems to be many patented algorythms. > Many codecs like MPEG-1/2/4 are patented. > The ffmpeg library seems to use > many patented codes. > And the legal state of quartz interfaces is > unclear for me. > I can't accept any liability. > > Please add all codes in CVS explicitly: > The code has been removed since the > original author requests 'please > remove my quartz codes' explicitly. > The original author don't accept any liability. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ gav(a)transgaming.com

Aug. 31, 2002

Re: quartz.dll

by Gavriel State

Hidenori, I have sent you a private reply to the above address. Since it has the appearance of a temporary address that you might not check, I am replying here as well to let you know. If there is a better address for me to reach you at, please feel free to sent it to me. The quick summary: I have an idea that may be able to provide you with protection against the liability that you believe exists. Thanks, -Gav Hidenori Takeshima wrote: > I'm original developer of quartz. > I don't want my quartz code to be restored. > > There seems to be many patented algorythms. > Many codecs like MPEG-1/2/4 are patented. > The ffmpeg library seems to use > many patented codes. > And the legal state of quartz interfaces is > unclear for me. > I can't accept any liability. > > Please add all codes in CVS explicitly: > The code has been removed since the > original author requests 'please > remove my quartz codes' explicitly. > The original author don't accept any liability. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ gav(a)transgaming.com

Aug. 31, 2002

Re: PATCH: rename WIN_Handle{16,32} to HWND_{16,32}

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.de> writes: > - rename WIN_Handle{16,32} to HWND_{16,32} to make it consistent > with the other handle <--> handle16 macros I think you should keep WIN_Handle32 as it is, to make it clear that it does more that simply cast the handle to the right type. Especially since we will need an HWND_32 macro in other dlls that does what its name suggests. Otherwise it's going to be very confusing to have HWND_32 be sometimes a simple macro and sometimes a complex function. -- Alexandre Julliard julliard(a)winehq.com

Aug. 31, 2002

Re: Quartz DLL

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > So, well, even if it's not in ReWind I do not see what (except for respect > for Hidenori's wishes) would prevent us to merge it in WineHQ. But of course if we didn't want to respect Hidenori's wishes then we wouldn't have the problem at all because the code would still be there. The fact is that Hidenori doesn't want his code distributed, and that's why I have removed it; so I'm not going to add it again just because it went through WineX first. We can certainly include the LGPL parts that have been written by Transgaming (if any, I haven't checked what they did), but not the ones written by Hidenori. -- Alexandre Julliard julliard(a)winehq.com

Aug. 31, 2002

MYOB 3.5.2 autorun

by Anand Kumria

I just tried out MYOB (a popular financial program used widely in Australia). The autorun program on the CD attempts to start programs using WinExec as WinExec("whatnews\\whatnews.exe") Unfortunately the FILE_contains_pathW function belueves that is a full path which causes (in files/directory.c): if (FILE_contains_pathW(name)) { ret = DOSFS_GetFullName( name, TRUE, full_name ); goto done; } to fail and return an error to WinExec and subsequently not do anything. The below patch fixes this problem (for me) and lets me install a number of ancillory programs. Unfortunately MYOB install uses InstallShield6 as its installer, so I've had no success with the actual program. Is there a better way to do this patch? Thanks, Anand -- `` We are shaped by our thoughts, we become what we think. When the mind is pure, joy follows like a shadow that never leaves. '' -- Buddha, The Dhammapada --- files/directory.c Sun Sep 1 01:27:00 2002 +++ files/directory.c Sun Sep 1 01:26:02 2002 @@ -821,12 +821,11 @@ } /* If the name contains an explicit path, everything's easy */ + /* But only jump if we successfully found it */ - if (FILE_contains_pathW(name)) - { - ret = DOSFS_GetFullName( name, TRUE, full_name ); + if ( FILE_contains_pathW(name) && + DOSFS_GetFullName(name, TRUE, full_name) ) goto done; - } /* Search in the specified path */

Aug. 31, 2002

Re: Quartz DLL

by Gavriel State

Lionel Ulmer wrote: > On Fri, Aug 30, 2002 at 05:37:08PM -0500, Igor Izyumin wrote: > >>Is it in rewind (the LGPL tree?) The link goes to the AFPL tree. Is this >>code also in ReWind? > > Well, I looked at one of the file in the WineX tree pointed by the link and > the license for this particular file is LGPL. And once a file is LGPLed, it > cannot be moved back to APFL (AFAIK). > > So, well, even if it's not in ReWind I do not see what (except for respect > for Hidenori's wishes) would prevent us to merge it in WineHQ. Of course, to > do that, one would have to ask WineX people what files are under which > license (ie is the file license header 'correct' for the whole file to be > sure they did not mix APFL and LGPL code in one file). The WineX head branch hasn't quite had all the license and quartz updating as yet, but you can find the detailed list in the WineX LICENSE file for the winex-2-0-branch CVS branch: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/winex/wine/LICENS… I tried contacting Hidenori for several weeks before we included the quartz code in WineX 2.1, but without success. His email address no longer seems valid, and mail to the postmaster at his domain has gone unanswered. Google searches also turn up very little. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com/ gav(a)transgaming.com

Aug. 31, 2002

Re: seg fault compiling wine

by Sebastian 'yath' Schmidt

On Tue, May 07, 2002 at 08:40:20PM -0500, Mason Kidd wrote: > Hi everyone, Hi, > I'm getting a segmentation fault compiling wine. This is the error > message: > [...] I got the same error. > wine-20020411 release of wine and got the same error. I am assuming > that > there is something wrong with my setup, because I compiled the CVS > source about 2 weeks ago without problems, which was after the > wine-20020411 release. Any ideas? It seems the configure-script is broken; it detects mmap64(), but there isn't mmap64(). So size_t gets 32 bits and off_t 64 bits. fstat() returns a structure with a member of type off_t, which is handed over to mmap(), which wants a size_t. mmap() gets 0 as size, returns a NULL-pointer, and in check_header(), where get_dword() the program receives a segmentation fault. Fix: change the "#define _FILE_OFFSET_BITS 64" in config.h to "#undef _FILE_OFFSET_BITS" and recompile. Sebastian -- pub 1024D/5A13B048 2001-08-28 Sebastian Schmidt (yath) <yathen(a)web.de> Key fingerprint = 8D25 C96B 3DE0 C7D0 AE01 6824 BC15 6273 5A13 B048 VI VI VI The editor of the beast.

Aug. 31, 2002

Re: Quartz DLL

by Lionel Ulmer

On Fri, Aug 30, 2002 at 05:37:08PM -0500, Igor Izyumin wrote: > Is it in rewind (the LGPL tree?) The link goes to the AFPL tree. Is this > code also in ReWind? Well, I looked at one of the file in the WineX tree pointed by the link and the license for this particular file is LGPL. And once a file is LGPLed, it cannot be moved back to APFL (AFAIK). So, well, even if it's not in ReWind I do not see what (except for respect for Hidenori's wishes) would prevent us to merge it in WineHQ. Of course, to do that, one would have to ask WineX people what files are under which license (ie is the file license header 'correct' for the whole file to be sure they did not mix APFL and LGPL code in one file). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 31, 2002

winedbg

by admiral coeyman

Group, I am not the only developer who has trouble reading the wine debugger screen. The solution which was pointed out will not work for me since I do not run wine that way. We should have a real solution rather than one that is bodged together anyway. What I'm getting at is, are any developers already working on making the debugger screen more readable? Since I cannot do much until this is fixed, I'll take a crack at it if somebody can give me some pointers on changing the concole appearance settings, size/font/etc. Ideally, I'd like this to be controlled by a few variables in the wine configuration file, or registry so that they can be adjusted. My personal preference would be to redirect the debugger to an unsued virtual terminal because I can read those. God Bless, --Robert 'Admiral' Coeyman -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

Aug. 31, 2002

quartz.dll

by Hidenori Takeshima

I'm original developer of quartz. I don't want my quartz code to be restored. There seems to be many patented algorythms. Many codecs like MPEG-1/2/4 are patented. The ffmpeg library seems to use many patented codes. And the legal state of quartz interfaces is unclear for me. I can't accept any liability. Please add all codes in CVS explicitly: The code has been removed since the original author requests 'please remove my quartz codes' explicitly. The original author don't accept any liability. __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 31, 2002

ALSA 0.9 sound problems

by TJ

Hi =) I have ALSA 0.9 with OSS compat modules. I recently got DeusEx to run (on Wine w/ openGL, not talking about WineX) However using winealsa.drv sound is very laggy and lots of nasty clicks and hissing occurs, but if I use wineoss.drv sound is fine?? (note OSS driver will be talking to ALSA via the snd-pcm-oss compat module) Also when using the wineoss module and the game (not just DeusEx but most games I got working) is setting up sound it seems to freeze, all i do then is ctrl+z, fg, in controling term and things run fine from then on. -TJ

Aug. 31, 2002

Re: Press: Running Windows Games with WineX 2.1

by Francois Gouget

On Sat, 31 Aug 2002, Jas Sandys-Lumsdaine wrote: > > > Some application will work better with the native (Windows) > > libraries, and some others with the builtin (Wine) libraries. > > Assuming native Windows dlls etc are correct (by definition of what Wine's > APIs are trying to copy), doesn't this imply the Wine framework (excl. built > in dlls) still has issues. > > Otherwise, what else could be going wrong when an app fails to run? Windows libraries (e.g. comctl32, shlwapi, etc) use other libraries (e.g. user32, ole32, etc). So if you use the Windows shlwapi library you may end up making calls to the ole32 or user32 library which are not yet completely implemented, especially if it is an undocumented API. Obviously Wine libraries tend not to call undocumented and/or unimplemented APIs in other libraries, thus sometimes resulting in better behavior. You will say "why not use only Windows libraries then?" Simply because for some libraries it is not possible. user32.dll is one such library, ntdll.dll, kernel32.dll, socket libraries, sound libraries and DirectX libraries are some others. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Aug. 30, 2002

Re: Press: Running Windows Games with WineX 2.1

by Jas Sandys-Lumsdaine

> Some application will work better with the native (Windows) > libraries, and some others with the builtin (Wine) libraries. Assuming native Windows dlls etc are correct (by definition of what Wine's APIs are trying to copy), doesn't this imply the Wine framework (excl. built in dlls) still has issues. Otherwise, what else could be going wrong when an app fails to run? Just interested! :)

Aug. 30, 2002

Re: Press: Running Windows Games with WineX 2.1

by Francois Gouget

On Fri, 30 Aug 2002, Jas Sandys-Lumsdaine wrote: > After reading this, (I'm very new to the Wine mailing list), I was wondering > the following as he didn't mention it: > > I know you can use the real/native Windows dlls etc under Wine - how much > "better" is running Win apps using these instead of the dlls developed by > the Wine team? This very much depends on the application. Some application will work better with the native (Windows) libraries, and some others with the builtin (Wine) libraries. There is no general rule and I think it's even impossible to say with certainty that more applications run with the native libraries (e.g. from a Windows partition) than with the builtin ones. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Aug. 30, 2002

Re: Press: Running Windows Games with WineX 2.1

by Jas Sandys-Lumsdaine

After reading this, (I'm very new to the Wine mailing list), I was wondering the following as he didn't mention it: I know you can use the real/native Windows dlls etc under Wine - how much "better" is running Win apps using these instead of the dlls developed by the Wine team? In other words, buggy or incomplete Wine APIs aside, what issues remain with the bare boned Wine instructure? Does Wine+Win98 CD mean I can run everything under the MS sun? Thanks, Jas. ----- Original Message ----- From: "Francois Gouget" <fgouget(a)free.fr> To: <wine-devel(a)winehq.com> Sent: Friday, August 30, 2002 10:47 PM Subject: Press: Running Windows Games with WineX 2.1 > > * August 29, 2002 - LinuxOrbit > Break out Your Games Library: Running Windows Games with WineX 2.1 > http://www.linuxorbit.com/modules.php?op=modload&name=Reviews&file=index&req =showcontent&id=15 > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > War doesn't determine who's right. War determines who's left. > > >

Aug. 30, 2002

Re: Quartz DLL

by Igor Izyumin

On Friday 30 August 2002 03:58 pm, Lionel Ulmer wrote: > > I was looking at the WineX cvs version on sourceforge > > and it looks as if they have a quartz.dll based on ffmpeg. > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/winex/wine/dlls/quartz/ > > > > What are the odd's of this work being put into the > > main wine tree ? As the old quartz.dll got pulled........ > > Well, as most of the code is LGPLed in there, it could be integrated easily > in WineHQ (after clean-up and reimplentation of the APFL parts if any). > > Of course, that is, if people want to use some code that the original > author explicitely asked us to remove from Wine. Is it in rewind (the LGPL tree?) The link goes to the AFPL tree. Is this code also in ReWind? -- -- Igor

Aug. 30, 2002

Press: Running Windows Games with WineX 2.1

by Francois Gouget

* August 29, 2002 - LinuxOrbit Break out Your Games Library: Running Windows Games with WineX 2.1 http://www.linuxorbit.com/modules.php?op=modload&name=Reviews&file=index&re… -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Aug. 30, 2002

Re: Quartz DLL

by Lionel Ulmer

> I was looking at the WineX cvs version on sourceforge > and it looks as if they have a quartz.dll based on ffmpeg. > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/winex/wine/dlls/quartz/ > > What are the odd's of this work being put into the > main wine tree ? As the old quartz.dll got pulled........ Well, as most of the code is LGPLed in there, it could be integrated easily in WineHQ (after clean-up and reimplentation of the APFL parts if any). Of course, that is, if people want to use some code that the original author explicitely asked us to remove from Wine. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 30, 2002

Quartz DLL

by tom

Hello, I was looking at the WineX cvs version on sourceforge and it looks as if they have a quartz.dll based on ffmpeg. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/winex/wine/dlls/quartz/ What are the odd's of this work being put into the main wine tree ? As the old quartz.dll got pulled........ Tom

Aug. 30, 2002

Re: removing mp3 code

by Eric Pouech

Alexandre Julliard a écrit : > > Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > > > well, perhaps we should add a note in case someone makes a commercial > > package out of wine... LICENSE file should be the right place IMO. > > comments ? > > I don't think it belongs in LICENSE, but I do think the mp3 code > should be disabled by default, with a configure option to enable > it. This way people who don't know about the issue don't get in > trouble, and those who enable it are expected to know what they are > doing. ok, I'll see to 1/ add a autoconf option to enable/disable compiling a given DLL (this may also be useful for mingw configuration for example) 2/ add a note in the dlls/msacm/winemp3 directory A+

Aug. 30, 2002

Re: removing mp3 code

by Eric Pouech

Sylvain Petreolle a écrit : > > --- Eric Pouech <eric.pouech(a)wanadoo.fr> a écrit : > Uwe Bonnes a > écrit : > no, there is misunderstanding. > see http://newsforge.com/article.pl?sid=02/08/29/1633205&tid=17 > no fee is needed for the use of free players. > only vendors needs to pay a fee. my point is: - a company X has an audio player for Win32 - company X ports its app to Wine using the wine source, and it's mp3 player and makes a closed package of it - it'll have to pay for the license so I think this has to be documented somehow A+

Aug. 30, 2002

Re: Wine Ma os X port

by Lionel Ulmer

> You cannot have a tool that is going to write the translation layer > automatically. I guess it is simpler to write it by hand for the Unix > APIs (maybe a couple thousands at most?), rather than for the Windows > APIs >> 10 thousands, plus tons of messages, plus tons of callbacks, > plus poor documentation, etc. Well, who would need documentation as we HAVE the source of these APIs (ie the Wine source code itself). My conception of a tool would have been something like that : each time in the Wine code that a function is 'exportable' to the application itself (be it via DLL loading, GetProcAddress, COM, ...), its signature could be stored somewhere (as is already done for relay traces in the .spec files but much more precise). Then, a tool could then, for any two given architectures, generate translation thunks from one to the other (which would convert structures with the various alignements for each platform, ...). Of course, Varargs function would be hell to simulate (but well, same problem for glibc translation than for Wine). The remaining problems would be callbacks. But for these too, as we have access to the code filling the data given to those, we could also do some special code handling the various translations. So, all in all, I still do not see why it would be much more difficult for Wine rather than for any other library.... Lionel (playing devil's advocate) -- Lionel Ulmer - http://www.bbrox.org/

Aug. 30, 2002

Re: Check accelerator descriptions in CreateAcceleratorTableA

by Sylvain Petreolle

--- Vincent Béron <vberon(a)mecano.gme.usherb.ca> a écrit : > > If you use cvs diff, you can add it to your .cvsrc as "diff -u". > > Vincent > Thanks for the info :) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 30, 2002

Re: Problem with regression tests getting stuck

by Sylvain Petreolle

Paul, I recently tried to compile gcc 3.2 from sources on my RedHat 7.3. It seems that it is a gcc 2.96 bug as tests now pass 100%. (even if gcc 3.2 is a bit slower to compile wine;)) For Codeweavers webmaster: Tried to update bug #852 but have a bugzilla error: SELECT profiles.realname, profiles.login_name, longdescs.bug_when, longdescs.thetext FROM longdescs, profiles WHERE profiles.userid = longdescs.who AND longdescs.bug_id = 852 ORDER BY longdescs.bug_when: Can't find record in 'longdescs' at globals.pl line 231. (30/08 08 PM EST) --- Paul Millar <paulm(a)astro.gla.ac.uk> a écrit : > Hi everyone, > > I've had the regression tests freeze on me again (see [1] for > previous > report). Sylvain has reported problems with the wininet regression > tests > (described in [2]). The symptoms are the same, but for me the problem > is > only intermittent. This time I caught the problem with gdb and > obtained > the following info: > > [...] > Loaded symbols for /lib/libresolv.so.2 > 0x402e7744 in __libc_close () at __libc_close:-1 > -1 __libc_close: No such file or directory. > in __libc_close > (gdb) bt > #0 0x402e7744 in __libc_close () at __libc_close:-1 > #1 0x400ec9a4 in __DTOR_END__ () > from /home/paulm/WINE-cvs/wine/dlls/libntdll.dll.so > #2 0x400b3df5 in WaitForMultipleObjectsEx (count=0, handles=0x0, > wait_all=0, > timeout=100, alertable=0) at ../../scheduler/synchro.c:257 > #3 0x400b3b88 in Sleep (timeout=100) at > ../../scheduler/synchro.c:178 > #4 0x40358747 in winapi_test (flags=268435456) at tests/http.c:121 > #5 0x40358b36 in func_http () at tests/http.c:184 > #6 0x40358f9d in run_test (name=0xbffffc63 "http.c") at wtmain.c:244 > #7 0x40357037 in __wine_exe_main () at wininet_test.exe.spec.c:133 > #8 0x400aff84 in start_process () at ../../scheduler/process.c:528 > #9 0x400b3f3f in call_on_thread_stack (func=0x400afd2c) > at ../../scheduler/sysdeps.c:108 > > So, to summarise (with some extra bits of information): > > The problem occurs when wininet/tests/http.c is testing asynchronous > HttpSendRequest(), so flags > 0. The problem is triggered at line 121 > of > http.c, i.e.: > 120 while ((flags)&&(!goon)) > 121 Sleep(100); > > > Sleep(), in turn, just calls WaitForMultipleObjectsEx(). From > scheduler/synchro.c: > 176 VOID WINAPI Sleep( DWORD timeout ) > 177 { > 178 WaitForMultipleObjectsEx( 0, NULL, FALSE, timeout, FALSE ); > 179 } > > > WaitForMultipleObjectsEx() has problems when it gets to 257: > 256 SERVER_END_REQ; > 257 if (ret == STATUS_PENDING) ret = wait_reply( &cookie ); > 258 if (ret != STATUS_USER_APC) break; > > ret is 1079729528, btw. > > AFAIK, __DTOR_END__ (see near bottom of stack) is the destructor for > a > function call in ntdll. I'm probably missing something obvious, but I > don't see the connection between scheduler/synchro.c:257 and ntdll. > The > closest is wait_reply() (in scheduler/client.c) calls wait_reply_data > (in > same file), which calls NtCurrentTeb(), which is commented as an > NTDLL > function. But there doesn't seem to be an implementation of > NtCurrentTeb > in ntdll. > > Any ideas? > > Cheers, > > Paul. > > [1] http://www.winehq.com/hypermail/wine-devel/2002/08/0006.html > [2] http://www.winehq.com/hypermail/wine-devel/2002/07/0386.html > > PS, I'll create a bugzilla in a bit. > > ---- > Paul Millar > > > > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 30, 2002

Re: removing mp3 code

by Sylvain Petreolle

--- Eric Pouech <eric.pouech(a)wanadoo.fr> a écrit : > Uwe Bonnes a écrit : no, there is misunderstanding. see http://newsforge.com/article.pl?sid=02/08/29/1633205&tid=17 no fee is needed for the use of free players. only vendors needs to pay a fee. > > > > >>>>> "Marcus" == Marcus Meissner <meissner(a)suse.de> writes: > > > > Marcus> Hi, Apparently distributing even mp3 decoders is not > royaltee > > Marcus> free anymore, according to the slashdot thread and the > Thomson > > Marcus> MultiMedia pages. > > > > http://www.heise.de/newsticker/data/vza-29.08.02-000/ (german) tell > about a > > Thompson Statement that free decoders are still royalty free. The > Thompson > > statement in in english. > well, perhaps we should add a note in case someone makes a commercial > package out of wine... LICENSE file should be the right place IMO. > comments ? > A+ > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 30, 2002

Re: removing mp3 code

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > well, perhaps we should add a note in case someone makes a commercial > package out of wine... LICENSE file should be the right place IMO. > comments ? I don't think it belongs in LICENSE, but I do think the mp3 code should be disabled by default, with a configure option to enable it. This way people who don't know about the issue don't get in trouble, and those who enable it are expected to know what they are doing. -- Alexandre Julliard julliard(a)winehq.com

Aug. 30, 2002

Re: removing mp3 code

by Eric Pouech

Uwe Bonnes a écrit : > > >>>>> "Marcus" == Marcus Meissner <meissner(a)suse.de> writes: > > Marcus> Hi, Apparently distributing even mp3 decoders is not royaltee > Marcus> free anymore, according to the slashdot thread and the Thomson > Marcus> MultiMedia pages. > > http://www.heise.de/newsticker/data/vza-29.08.02-000/ (german) tell about a > Thompson Statement that free decoders are still royalty free. The Thompson > statement in in english. well, perhaps we should add a note in case someone makes a commercial package out of wine... LICENSE file should be the right place IMO. comments ? A+

Aug. 30, 2002

Re: trying to draw off-screen

by Bill Medland

----- Original Message ----- From: "Jean-Claude Batista" <jcb(a)macadamian.com> To: "Bill Medland" <billmedland(a)look.ca> Cc: <wine-devel(a)winehq.com> Sent: Friday, August 30, 2002 7:23 AM Subject: Re: trying to draw off-screen > Hi, > > Which window manager are you using ? Often it is the window manager that > reposition the window on the top right if the coordinates of the window are > beyond the screen. Not Wine. That's what I was afraid of. (I get a bit confused as to what is the window manager and what is the desktop but) KDE3 I guess. > > -- JcB > Macadamian Technologies. > > ---Original Message ----- > From: "Bill Medland" <billmedland(a)look.ca> > To: "wine-devel" <wine-devel(a)winehq.org> > Sent: Thursday, August 29, 2002 6:28 PM > Subject: trying to draw off-screen > > > > Does anyone know who constrains a window to be on the screen? > > > > Our application, in order to minimise flicker, does the hard work with a > > container application deliberately positioned well off-screen (enormous > > negative coordinates I think). > > > > This works under Windows. > > > > However under WINE the initial window appears in the top right corner of > my > > screen (I think I've seen it appear in other corners too on other > > computers). It then resizes , keeping the same top left corner (with > parts > > of the window off-screen) before correctly repositioning itself into the > > middle of the screen. > > > > Does anyone know which code is doing the initial positioning in the top > > right corner? Is this deliberate? > > > > Bill > > > > > > > Bill

Aug. 30, 2002

Re: trying to draw off-screen

by Jean-Claude Batista

Hi, Which window manager are you using ? Often it is the window manager that reposition the window on the top right if the coordinates of the window are beyond the screen. Not Wine. -- JcB Macadamian Technologies. ---Original Message ----- From: "Bill Medland" <billmedland(a)look.ca> To: "wine-devel" <wine-devel(a)winehq.org> Sent: Thursday, August 29, 2002 6:28 PM Subject: trying to draw off-screen > Does anyone know who constrains a window to be on the screen? > > Our application, in order to minimise flicker, does the hard work with a > container application deliberately positioned well off-screen (enormous > negative coordinates I think). > > This works under Windows. > > However under WINE the initial window appears in the top right corner of my > screen (I think I've seen it appear in other corners too on other > computers). It then resizes , keeping the same top left corner (with parts > of the window off-screen) before correctly repositioning itself into the > middle of the screen. > > Does anyone know which code is doing the initial positioning in the top > right corner? Is this deliberate? > > Bill > >

Aug. 30, 2002

wine regression - win16 file read problem!?

by Rizsanyi Zsolt

Hi! I have recently upgraded wine cvs and done a recompile and install. But now one of the programs I'm using does not work. My last cvs update was about 2 weeks ago. Its an old dictionary program (win16). It starts up ok, but when it tries to open the dictionary data, it says, that it is not found, and I should specify a location. I have looked at the +file debug channel output, and it does not even contain the location I have specified. Does that mean, that it does not even tries to open the file? Does somebody has some ideas where the problem could come from? Or which debug channel should I turn on to get some info about the problem? I just would like to ask for ideas before I start more serious debugging... Thanks Zsolt

Aug. 30, 2002

Re: Wine Status

by tom

> > >A couple of good sources of information about changes >in Wine: >1) Wine Weekly News articles http://www.winehq.com >2) Notes in the release ANNOUNCE file >http://cvs.winehq.com/cvsweb/wine/ANNOUNCE > >Good luck, >Andriy > >Boston, MA, USA > > > > Thanks I will start looking over the WWN articles. Me reading over the source changelog was to get a feel of who the current developers are and there patches. 15,000 lines in the last year :) I would like to say thanks to eveyone who has responded so far And I hope to have a first draft in a week or so .. I will send it here for overview and you can guy's can send patches against it. Tom

Aug. 30, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Martin Wilck

Am Don, 2002-08-29 um 18.37 schrieb Duane Clark: > Since I also was stumbled for a long period on a similar problem, due to > specifying a "unix" filesystem, perhaps it would be appropriate in the > documentation to put some large warnings on that option. Wait a bit - the usual suspect is not guilty here. My FS used to be "win95" all the time. I just reckoned "unix" might come as a friend here. For "win95", it is inherently clear that "wine" and "Wine" can't be distinguished. For "unix", that shouldn't be so. Thus I suggest improving "unix" and make it work nicely in cases where "win95" cannot possibly do the job, rather than deprecating it. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Aug. 30, 2002

Re: Wine Ma os X port

by Francois Gouget

On Thu, 29 Aug 2002, Lionel Ulmer wrote: > On Wed, Aug 28, 2002 at 04:51:29PM -0700, Francois Gouget wrote: > > Not necessarily. What you propose to do for Wine can be done for the C > > and X11 libraries. Then you get an emulator that lets you run x86 Linux > > applications on a PPC machine... including Wine. > > Well, yes... But if you have a system that creates for you a 'translation' > layer for all the libraries used by Wine, why not use it directly on Wine > itself ? You cannot have a tool that is going to write the translation layer automatically. I guess it is simpler to write it by hand for the Unix APIs (maybe a couple thousands at most?), rather than for the Windows APIs >> 10 thousands, plus tons of messages, plus tons of callbacks, plus poor documentation, etc. -- 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

Aug. 30, 2002

Re: RFC: 'test' bugzilla keyword

by Tony Lambregts

Francois Gouget wrote: >On Tue, 27 Aug 2002, Paul Millar wrote: >[...] > > >>>Maybe 'conformance' would work? >>> >>> >>Personally, I prefer "regression" to "conformance", although both are >>applicable names. >> >> > >The problem is we already have a 'regression' keyword with a reasonable >meaning: 'bugs relating to programs that were working at one time but >stoped working for some reason'. But this does not specifically cover >the 'conformance test suite'. > >If a conformance test used to work and no longer does, then I think it >would be reasonable to tag it as 'conformance, regression'. > >But I have also found that some tests do not pass on Windows. IIRC, >there's a test having to do with TEMP that fails if it is set to >'c:\Windows\Temp' rather than 'c:\'. I would like to be able to make a >bug report and tag it with a keyword to indicate it is related to the >'conformance test suite' (or whatever we want to call it). Similarly, >there would be reports to be made about the conformance tests as run on >FreeBSD and Solaris. And note that none of these are regressions. > > > > You have sold me on "conformance" . The real proplem is that we have been calling the conformance test suite by the wrong name if you ask me. The thing is that this is exactly what the suite is for (to be able to track where wine and windows differ in thier behavior.) To be able to have a bug report where the source is available is indispensible. Mr Newman can we please, please, please have this. Tony Lambregts

Aug. 30, 2002

trying to draw off-screen

by Bill Medland

Does anyone know who constrains a window to be on the screen? Our application, in order to minimise flicker, does the hard work with a container application deliberately positioned well off-screen (enormous negative coordinates I think). This works under Windows. However under WINE the initial window appears in the top right corner of my screen (I think I've seen it appear in other corners too on other computers). It then resizes , keeping the same top left corner (with parts of the window off-screen) before correctly repositioning itself into the middle of the screen. Does anyone know which code is doing the initial positioning in the top right corner? Is this deliberate? Bill

Aug. 29, 2002

RE: Added H_SRCS (used by msvcmaker)

by Patrik Stridvall

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps files such as include/winuser.h should be included > > for USER32 for example? > > > > Anyway what do you think about adding H_SRCS to > > every Makefile.in file? > > I don't think we want that, especially if you want to add all relevant > includes it's going to be a nightmare to maintain. Yes, I'm a little worried about that myself, but then the C_SRCS doesn't change that often and the H_SRCS are likely to change MUCH less. Futhermore it doesn't really matter if it out out sync either. If somebody developing in MSVC misses a file he can add it. It not like Wine won't build correctly. > And make depend (or > some perl equivalent) can easily determine that information for you. Well, if you just want all .h files the DLL depends on MSVC already have that in a automatically generated "folder" called External dependencies. The H_SRCS is mostly for the .h files that you are likely to want to look at or modify while developing the DLL under MSVC. But it is not strictly nessary. It is more a convenience sort of thing. Another reason that I proposed it is that maybe H_SRCS could be used fo something else though I can't think of anything right now... But sure I can search for the .h files in the director{y,ies} of each DLL. However for a DLL like ntdll files like include/wine/exception.h is very much relevent and won't be included is such a case. Not that it really matters that much but still...

Aug. 29, 2002

Re: Added H_SRCS (used by msvcmaker)

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > Perhaps files such as include/winuser.h should be included > for USER32 for example? > > Anyway what do you think about adding H_SRCS to > every Makefile.in file? I don't think we want that, especially if you want to add all relevant includes it's going to be a nightmare to maintain. And make depend (or some perl equivalent) can easily determine that information for you. -- Alexandre Julliard julliard(a)winehq.com

Aug. 29, 2002

Re: Wine Ma os X port

by Lionel Ulmer

On Wed, Aug 28, 2002 at 04:51:29PM -0700, Francois Gouget wrote: > Not necessarily. What you propose to do for Wine can be done for the C > and X11 libraries. Then you get an emulator that lets you run x86 Linux > applications on a PPC machine... including Wine. Well, yes... But if you have a system that creates for you a 'translation' layer for all the libraries used by Wine, why not use it directly on Wine itself ? I do not see why it would so much more difficult for Wine than for libc or X11 libs (the only additionnal problem I see would be endianness problems for ressource loading, but a part from that, I see none). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 29, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Duane Clark

Andreas Mohr wrote: > On Thu, Aug 29, 2002 at 09:37:13AM -0700, Duane Clark wrote: > >>Martin Wilck wrote: >> >>>In any case this is relatively minor and we can live without. If we >>>don't patch, we need to be prepared that other people stumble into the >>>problem I had, though. I am still feeling dumb - my wine development was >>>practically stuck for 2 months because of that "wine" file. >> >>Since I also was stumbled for a long period on a similar problem, due to >>specifying a "unix" filesystem, perhaps it would be appropriate in the >>documentation to put some large warnings on that option. > > Well, uh, where have you been recently ? ;-) > That's exactly what we've been doing in several docu places for two years now. > OK, it may not be specified in every relevant docu, but I'd say that at least > 40% of all docs tell this story. > Obviously I should have actually looked at the docs before posting that. It is clearly spelled out in the important spots. Oh well, now that I think about it, it was more than two years ago that I had created the config file that had caused the problem for me.

Aug. 29, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Andreas Mohr

On Thu, Aug 29, 2002 at 09:37:13AM -0700, Duane Clark wrote: > Martin Wilck wrote: > > > > In any case this is relatively minor and we can live without. If we > > don't patch, we need to be prepared that other people stumble into the > > problem I had, though. I am still feeling dumb - my wine development was > > practically stuck for 2 months because of that "wine" file. > > Since I also was stumbled for a long period on a similar problem, due to > specifying a "unix" filesystem, perhaps it would be appropriate in the > documentation to put some large warnings on that option. Well, uh, where have you been recently ? ;-) That's exactly what we've been doing in several docu places for two years now. OK, it may not be specified in every relevant docu, but I'd say that at least 40% of all docs tell this story. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

Aug. 29, 2002

Re: WineDbg and sources

by Eric Pouech

Fabian Cenedese a écrit : > > Hello > > If WineDbg stops it tries to show the actual source line. With my files it > always says "Unable to open file X" Looking into debugger/source.c I found > that it always bails out after stat (returns -1). This seems like it can't find > the file. But if I use wine wcmd I can go there without a problem. My guess > is that stat is a Unix tool and therefore case sensitive so this could arise > a problem. But still after trying out different cases it could never find my > source files. The code looks good as does the (windows-) path it is looking > for the file. The only reason is the failing return value of stat. > Is it important if the files are Dos/Unix style? (Kate says it's Unix). > Does anybody have any ideas? the point is rather that under windows, file names are case insensitive (even if they are stored with lower/upper cases) since the debugger doesn't open files with the Windows interface but with the unix interface, name lookup likely fails we should rewrite it using windows API (or link winedbg with msvcrt instead of glibc) the DOS/Unix style (if you mean the \r\n vs \n issues) shouldn't matter I'll try to give a try later on A+

Aug. 29, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Duane Clark

Martin Wilck wrote: > > In any case this is relatively minor and we can live without. If we > don't patch, we need to be prepared that other people stumble into the > problem I had, though. I am still feeling dumb - my wine development was > practically stuck for 2 months because of that "wine" file. Since I also was stumbled for a long period on a similar problem, due to specifying a "unix" filesystem, perhaps it would be appropriate in the documentation to put some large warnings on that option.

Aug. 29, 2002

Re: Wine Status

by Shachar Shemesh

BiDi - 5% done. me tom wrote: > Hello , > > The Wine Status page located here : > http://www.winehq.com/about/index.php?status > Has gone for about one year now with out updates and I > have volunteer'd to work on bringing this page up to date. > I am new to the Wine Project and I am in need of some assistance to make > sure all changes are corrct and accurate. > Over the next week or so I plan to read over the change log's for the > last year > so I will have a feel of the changes that have been made. > > If current Users/Developers could send me changes that they are aware of > I will start a log of changes against the current page. > > If anyone is willing to help me with this I would be most appreciative . > > Thomas Wickline > > >

Aug. 29, 2002

Re: Wine Status

by Dimitrie O. Paun

I also keep track on individual control status, do you want to integrate that too? -- Dimi.

Aug. 29, 2002

Re: Wine Status

by Andriy Palamarchuk

[skipped] > I am new to the Wine Project and I am in need of some > assistance to make > sure all changes are corrct and accurate. > Over the next week or so I plan to read over the change > log's for the > last year > so I will have a feel of the changes that have been > made. A couple of good sources of information about changes in Wine: 1) Wine Weekly News articles http://www.winehq.com 2) Notes in the release ANNOUNCE file http://cvs.winehq.com/cvsweb/wine/ANNOUNCE Good luck, Andriy Boston, MA, USA __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 29, 2002

WineDbg and sources

by Fabian Cenedese

Hello If WineDbg stops it tries to show the actual source line. With my files it always says "Unable to open file X" Looking into debugger/source.c I found that it always bails out after stat (returns -1). This seems like it can't find the file. But if I use wine wcmd I can go there without a problem. My guess is that stat is a Unix tool and therefore case sensitive so this could arise a problem. But still after trying out different cases it could never find my source files. The code looks good as does the (windows-) path it is looking for the file. The only reason is the failing return value of stat. Is it important if the files are Dos/Unix style? (Kate says it's Unix). Does anybody have any ideas? Thanks Fabi

Aug. 29, 2002

Re: Menu patch breakage

by Andreas Mohr

On Thu, Aug 29, 2002 at 01:03:38PM +0200, Rein Klazes wrote: > Hi, > > Yesterday's destroymenu patch broke a number of applications, among > them Forte Agent. Because I don't quite understand the issues yet, I > have uploaded a +relay,+menu log to > www.xs4all.nl/~rklazes/temp/ag.log.bz2 if anyone wants to have a look. ARGL ! ;) Hah, but I guess I understand it, fortunately ! :-) The program first creates a window: 0806eae8:Call user32.CreateWindowExA(00000000,005c4183 "ForteAgent:Main",417123b 0 "Agent",1acf0000,80000000,00000000,80000000,00000000,00000000,0000008c,0040000 0,00000000) ret=00598ea1 trace:menu:MENU_GetSysMenu loading system menu, hWnd 10025, hPopupMenu 0000 trace:menu:CreateMenu return 00c8 trace:menu:MENU_GetSysMenu hWnd 10025 (hMenu 00c8) then it assigns a menu to this window: trace:menu:SetMenu (10025, 008c); later it does: 0806eae8:Call window proc 0x406fc3dc (hwnd=00010026,msg=WM_MDISETMENU,wp=0000010 4,lp=0000053c) trace:menu:GetMenu for 10025 returning 008c trace:menu:SetMenu (10025, 0104); 0806eae8:Ret window proc 0x406fc3dc (hwnd=00010026,msg=WM_MDISETMENU,wp=0000010 4,lp=0000053c) retval=0000008c And since hmenu 0x008c isn't used any more, it does: 0806eae8:Call user32.DestroyMenu(0000008c) ret=004dd671 trace:menu:DestroyMenu (008c) 0806eae8:Ret user32.DestroyMenu() retval=00000001 ret=004dd671 and thus WIPING OUT the hMenu member of the window, since 0x008c's hWnd member *still* points to the hWnd now owning the 0x0104 hMenu, and thus lets DestroyMenu() wipe out the *old*, wrong hWnd's hMenu member ! So either: a) DestroyMenu should check whether the hMenu's "owner" window still contains the very same menu handle and set it to 0 in this case *only* (i.e.: not eliminate "foreign" hMenu values) or b) a SetMenu should unregister the hWnd member of the hMenu previously assigned to the window (i.e.: set hMenu->hWnd to 0). I'll do some testing to find out which path to take ASAP. For now, I'd assume that b) is the correct answer. Thank you very much for this report ! -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

Aug. 29, 2002

Re: GetObject with empty buffer

by Uwe Bonnes

>>>>> "Fabian" == Fabian Cenedese <Cenedese(a)indel.ch> writes: ... Fabian> <MSDN> If the lpvObject parameter is NULL, the function return Fabian> value is the number of bytes required to store the information Fabian> it writes to the buffer for the specified graphics object. Fabian> </MSDN> Fabian> But I couldn't find this anywhere, not in the general function Fabian> in gdiobj.c nor in the subtypes FONT_GetObject or Fabian> BRUSH_GetObject (sure others neither). As my app uses this Fabian> feature Wine tries to memcpy to a NULL pointer and jumps out of Fabian> the window... literally :) FONT_GetObject sure checks: if(buffer) memcpy( buffer, &lfA, count ); return count; BRUSH_GetObject does not: if (count > sizeof(brush->logbrush)) count = sizeof(brush->logbrush); memcpy( buffer, &brush->logbrush, count ); return count; Someone has to carefully check all subtypes... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 29, 2002

heise online: Tumultuous Response to Alleged Change in MP3 Licensing Conditions

by Thomas Rösch

>From a huge german computer magazin, you can found it under: http://www.heise.de/english/newsticker/data/jk-28.08.02-008/ -------------------------------------------------------------------- Tumultuous Response to Alleged Change in MP3 Licensing Conditions Ever since the early morning heise online has been receiving a swelling stream of disapproving comment on alleged changes to MP3 licenses: According to a posting at Slashdot[1] Thomson Multimedia, the exclusive licensor of MP3, is said to have erased a passage from its licensing conditions according to which no licensing fees were due for non-commercial free MP3 decoders. In doing so the company was said to be referring to the official table of fees[2], according to which a fee of 75 US cents per MP3 decoder or a one-off payment of 60,000 US dollars (for patent and software; 50,000 US dollars for the patent only) was due. As a matter of fact this rule has been in force for about eighteen months now[3]. At that time not only was the web design of MP3licensing.com modified, in the course of the creation of the then new MP3Pro the licensing conditions were also adjusted. Another decisive passage was also scrapped at that time: "No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users". By inquiring with the Fraunhofer Institute for Integrated Circuits (IIS[4]) and MP3Pro developer Coding Technologies[5] heise online was able to verify the existence of this link -- the tumult has hence been pretty late in coming. Given that Thomson Multimedia has since then not taken any legal steps against developers or distributors of non-commercial MP3 decoders, it does not appear that the future of free MP3 decoders is in jeopardy. As it is, for Thomson to take drastic legal measures in this matter would not make much sense: There is not much money to be had from freeware and open source developers who have created their own MP3 decoders. This is probably the reason why the licensor has refrained to date from taking the appropriate steps. The situation appears to be different with regard to encoders for the creation of MP3 files, however: As a rule in these cases the Fraunhofer Institute as well as Thomson insist that the licensing conditions be met; an open source packet called lame does, however, exist (whether, in the event, its self-referential Gödelian acronym reading LAME Ain't a Mp3 Encoder has enough protective charm is a moot point). It is also not to be feared that such popular players as Winamp or the Musicmatch Jukebox will in future be distributed free-of-charge only without an MP3 decoder: Nullsoft as well as Musicmatch are among the official licensees of MP3(Pro), in the case of Musicmatch this statement also applies to its integrated encoder. Whatever the merits, if any, of the changes in licensing conditions, Mr. Emmett Plant, CEO by profession of Xiph.org Foundation has expressed his considerable delight at the turn of events. In an open letter[6] he thanked Thomson Multimedia. "Thank you for the huge amount of free advertising to our benefit created by your announcement that licensing conditions had changed," Mr. Plant wrote. The letter closes with: "We support all actions on the part of Thomson that make it plain that MP3 costs money. Once again thank you and good luck." Unlike MP3, Ogg Vorbis, recently published in its version 1.0 (according to its developers' statements), is free of patent protection and subject to the GNU Public License; hence, even in future no license fees of any sort would be due for this compression process. It is not a good idea as yet to rely exclusively on Ogg Vorbis, however: Even if Ogg Vorbis manages to close the quality gap between it and MP3 or even manages to get ahead of the latter, it will still take some time before Ogg-capable portable players make their appearance as hardware. (Robert W. Smith) / (jk[7]/c't) URL of this article: http://www.heise.de/english/newsticker/data/jk-28.08.02-008/ Links in this article: [1] http://www.slashdot.org [2] http://www.mp3licensing.com/royalty/software.html [3] http://web.archive.org/web/20010331223305/www.mp3licensing.com/royalty/swde… [4] http://www.iis.fhg.de/ [5] http://www.codingtechnologies.com/ [6] http://www.xiph.org/ogg/vorbis/openletter.html [7] mailto:jk(a)ct.heise.de -------------------------------------------------------------------- Copyright 2002 by Verlag Heinz Heise

Aug. 29, 2002

GetObject with empty buffer

by Fabian Cenedese

Hello I think I found my (or better a :) problem with fonts. The function GetObject <MSDN> int GetObject( HGDIOBJ hgdiobj, // handle to graphics object int cbBuffer, // size of buffer for object information LPVOID lpvObject // buffer for object information ); </MSDN> should either return the info in the object buffer or, if this pointer is zero, just the size the required info would need. <MSDN> If the lpvObject parameter is NULL, the function return value is the number of bytes required to store the information it writes to the buffer for the specified graphics object. </MSDN> But I couldn't find this anywhere, not in the general function in gdiobj.c nor in the subtypes FONT_GetObject or BRUSH_GetObject (sure others neither). As my app uses this feature Wine tries to memcpy to a NULL pointer and jumps out of the window... literally :) bye Fabi

Aug. 29, 2002

Menu patch breakage

by Rein Klazes

Hi, Yesterday's destroymenu patch broke a number of applications, among them Forte Agent. Because I don't quite understand the issues yet, I have uploaded a +relay,+menu log to www.xs4all.nl/~rklazes/temp/ag.log.bz2 if anyone wants to have a look. Thanks, Rein. -- Rein Klazes rklazes(a)xs4all.nl

Aug. 29, 2002

Re: Return value GetStockObject

by Fabian Cenedese

> > In my app I try to get a handle to a system font with following call: > > HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); > > If the call succeeds it should return a handle to the requested object, > > otherwise zero. In Windows I get something like 0x018A000E (looks ok), > > but in Wine I get 0x0000009E. Even not zero I can't imagine that this is > > a valid handle (address). ANSI_FIXED_FONT is never really used in Wine, > > only SYSTEM_FONT. > > Is this an error or am I barking up the wrong tree? > >In Wine, handles are not (yet) all void * (see bug #90). Even then, it >doesn't mean a handle is a valid heap address; I know there are a couple >places in Wine where they are used as an index in an array locating all >objects of a kind. It doesn't exactly follow the Windows convention, but >I think handles are supposed to be passed back to APIs, not handled >(dereferenced) directly by apps. > >So 0x0000009E doesn't strike me as bad. If you use it in calls to font >APIs, does it work correctly? With this returned handle I try to fill a structure with GetObject: HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); LOGFONT lfSys; int ret=GetObject(hobj, sizeof(lfSys), &lfSys); (Windows returns 36) After that lfSys has all the info about this font. In Windows the members are filled nicely, lfSys.lfFaceName is "Courier". In Wine GetObject returns 60 (for whatever reason), and lfSys.lfFaceName is empty. Now this could mean that the handles are invalid or that there is something wrong with my fonts. Thanks Fabi

Aug. 29, 2002

Re: removing mp3 code

by Uwe Bonnes

>>>>> "Marcus" == Marcus Meissner <meissner(a)suse.de> writes: Marcus> Hi, Apparently distributing even mp3 decoders is not royaltee Marcus> free anymore, according to the slashdot thread and the Thomson Marcus> MultiMedia pages. http://www.heise.de/newsticker/data/vza-29.08.02-000/ (german) tell about a Thompson Statement that free decoders are still royalty free. The Thompson statement in in english. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 29, 2002

Re: removing mp3 code

by Marcus Meissner

On Thu, Aug 29, 2002 at 11:03:26AM +0200, Michael Stefaniuc wrote: > Hello, > > On Thu, Aug 29, 2002 at 10:52:34AM +0200, Marcus Meissner wrote: > > Apparently distributing even mp3 decoders is not royaltee free anymore, > > according to the slashdot thread and the Thomson MultiMedia pages. > > > > So we probably should remove the msacm mp3 decoder we include. :( > I would wait with that, because every day you get an other information. > Have a look at http://www.heise.de/newsticker/data/vza-29.08.02-000/ Hmm, ok. Ignore my last mail then ;) Ciao, Marcus

Aug. 29, 2002

RE: removing mp3 code

by Patrik Stridvall

> Apparently distributing even mp3 decoders is not royaltee > free anymore, > according to the slashdot thread and the Thomson MultiMedia pages. > > So we probably should remove the msacm mp3 decoder we include. :( At the very least we should make it compile option that is by default disabled. I don't think we need to go that far as to remove it. IIRC LAME an mp3 ENCODER (that was non royalty free even before) got around it by only distributing source code and so can we. BTW: Why do we include a mp3 decoder in the Wine tree? Why not just link to an external library? I can't see maintaining a mp3 decoder being in the best intrest of Wine anyway patents or not...

Aug. 29, 2002

Re: removing mp3 code

by Michael Stefaniuc

Hello, On Thu, Aug 29, 2002 at 10:52:34AM +0200, Marcus Meissner wrote: > Apparently distributing even mp3 decoders is not royaltee free anymore, > according to the slashdot thread and the Thomson MultiMedia pages. > > So we probably should remove the msacm mp3 decoder we include. :( I would wait with that, because every day you get an other information. Have a look at http://www.heise.de/newsticker/data/vza-29.08.02-000/ bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 29, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Martin Wilck

Am Don, 2002-08-29 um 03.25 schrieb Alexandre Julliard: > I'd say that DOSFS_ToDosFCBFormat should fail when the file contains > upper-case chars on a case-sensitive file system. This will probably > make it impossible to access some files in certain cases though. I'm > afraid it's not possible to support case-sensitive file systems 100% > right given that Windows apps don't preserve case correctly. I propose another patch with is is IMO the least intrusive: - changes nothing for non-"unix" filesystems - for "unix", searches the whole directory for exact matches first, then again for DOS matches; i.e. DOS matches will be used, but only if there are no exact ones. Sorry the patch is difficult to read - you'll see the point if you compare the patched an non-patched versions visually. In any case this is relatively minor and we can live without. If we don't patch, we need to be prepared that other people stumble into the problem I had, though. I am still feeling dumb - my wine development was practically stuck for 2 months because of that "wine" file. Martin Index: dos_fs.c =================================================================== RCS file: /home/wine/wine/files/dos_fs.c,v retrieving revision 1.117 diff -u -r1.117 dos_fs.c --- dos_fs.c 27 Aug 2002 01:13:59 -0000 1.117 +++ dos_fs.c 29 Aug 2002 08:34:51 -0000 @@ -746,31 +746,53 @@ return FALSE; } - while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) + if (ignore_case) { - /* Check against Unix name */ - if (len == strlenW(long_name)) + while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) { - if (!ignore_case) + /* Check against Unix name */ + if (len == strlenW(long_name) && !strncmpiW( long_name, name, len )) + goto found; + + if (dos_name[0]) { - if (!strncmpW( long_name, name, len )) break; - } - else - { - if (!strncmpiW( long_name, name, len )) break; + /* Check against hashed DOS name */ + if (!short_name) + { + DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case ); + short_name = tmp_buf; + } + if (!strcmpW( dos_name, short_name )) goto found; } } - if (dos_name[0]) + } + else /* ignore_case ("unix" file system): try to find exact match first */ + { + while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) + if (len == strlenW(long_name) && !strncmpW( long_name, name, len )) + goto found; + + DOSFS_CloseDir( dir ); + dir = DOSFS_OpenDir( DRIVE_GetCodepage(path->drive), path->long_name ); + + while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name ))) { - /* Check against hashed DOS name */ - if (!short_name) + if (dos_name[0]) { - DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case ); - short_name = tmp_buf; + /* Check against hashed DOS name */ + if (!short_name) + { + DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case ); + short_name = tmp_buf; + } + if (!strcmpW( dos_name, short_name )) goto found; } - if (!strcmpW( dos_name, short_name )) break; } } + +found: + DOSFS_CloseDir( dir ); + if (ret) { if (long_buf) WideCharToMultiByte(DRIVE_GetCodepage(path->drive), 0, @@ -787,7 +809,6 @@ } else WARN("%s not found in '%s'\n", debugstr_w(name), path->long_name); - DOSFS_CloseDir( dir ); return ret; } -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Aug. 29, 2002

removing mp3 code

by Marcus Meissner

Hi, Apparently distributing even mp3 decoders is not royaltee free anymore, according to the slashdot thread and the Thomson MultiMedia pages. So we probably should remove the msacm mp3 decoder we include. :( Ciao, Marcus

Aug. 29, 2002

Re: Need to know some macro values

by Dmitry Timoshkov

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > one of the ERROR_ constant values you provided to me > looks suspicious: > > ERROR_AUDITING_DISABLED c0090001 > > All other error codes have much lesser values (the > biggest is 14011 - 0x36bb). The value for this error > code reminds me values for STATUS_ constants. > > Could you check if this is correct value? > Is it definend in header file with other ERROR_ > constants or with STATUS_ constants? The value above is the correct one. It's defined along with other ERROR_ constants in the WinXP DDK header file \WINDDK\inc\crt\winerror.h One more constant which has a 0xc00 prefix is #define ERROR_ALL_SIDS_FILTERED _HRESULT_TYPEDEF_(0xC0090002L) -- Dmitry.

Aug. 29, 2002

Keyboard Switching

by Supphachoke Suntiwichaya

Hi I made Thai keyboard layout and compiled but I can't switch to thai char.. I use th in X but it not support X thai key input.. Help me.. Serious..! MrChoke -- ========================================== Supphachoke Suntiwichaya WWW:http://jedi.links.nectec.or.th/~mrchoke UIN:10509387 TEL:+66-1-5408959 Love Me Love Linux.... ===========================================

Aug. 29, 2002

Press: A couple articles about Wine products

by Francois Gouget

I have added a couple entries to WineHQ's press references: http://www.winehq.com/about/index.php?press Let me know if you know of other Wine-related articles or announcements that you think would be worth mentioning there. * August 19, 2002 - TransGaming TransGaming and TimeGate Partner to Port KOHAN http://www.transgaming.com/news.php?newsid=43 * August 14, 2002 - CodeWeavers CodeWeavers CrossOver Office Wins 'Best Desktop Office Solution' At LinuxWorld 2002 http://www.codeweavers.com/about/press_releases/?id=20020814 * August 13, 2002 - CodeWeavers CodeWeavers Unveils CrossOver Office Server Edition for Solaris and Linux thin clients http://www.codeweavers.com/about/press_releases/?id=20020813 * August 6, 2002 - DesktopLinux CrossOver Office 1.2 review: Quicken and QuickBooks and Visio, oh my! (on Linux, that is) http://www.desktoplinux.com/articles/AT2282537026.html -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

Aug. 29, 2002

Re: CVS wine/ dlls/gdi/win16drv/font.c dlls/gdi/win16d ...

by Duane Clark

Xilinx again:-) This patch http://cvs.winehq.com/patch.py?id=1030574123182059719300927 causes a bunch of error messages when scrolling the main window in fpga_editor. The scrolling however works fine. This is repeated for every "sliver" (or whatever that is called) as the window is scrolled. trace:nonclient:WIN_UpdateNCRgn hwnd 2005a [1e12] hrgn 0000, unc 0005, ncf 0 err:region:CombineRgn Invalid rgn=0000

Aug. 29, 2002

Re: WIN_Handle{16,32} questions

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.de> writes: > Assuming that WIN_Handle{16,32} are not windows funtions (a search on > google has given only links to wine pages) i would do following: > - rename WIN_Handle{16,32} to HWND_{16,32} to make the naming consistent > to the othe handle conversions > - maybe remove the declaration of the two functions from include/win.h > (or at least don't include win.h where it isn't yet used) > - define HWND_16 as macro like the other HANDLE_16 macros and put it > directly in the files where it's needed The macros should stay in win.h, you must not define them in every single C file. For other dlls, you need to define them in some appropriate internal header of the dll. There shouldn't be more than one definition of the macros for each dll. > - HWND_32 has to do a little bit more work then the other HANDLE_32 > macros and i would keep it as function. This means it has to be > duplicated in every dll that needs it and one of the *16.c files in > the dll directory would be the place to put it in. Other dlls should probably do a simple 16->32 conversion like for other handles; you definitely don't want to duplicate WIN_Handle32 in the other dlls. -- Alexandre Julliard julliard(a)winehq.com

Aug. 29, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > Now in /home/martin/Software, I have subdirectories "Wine" and "wine". > DOSFS_FindUnixName() uses "wine" because > a) DOSFS_ReadDir returns it first, > b) The DOS short names match (the Unix names obviously don't). > > Since "wine" is the wrong path, the search fails shortly after. > This happens even if I set the Filesystem type of drive Y: to "unix". I'd say that DOSFS_ToDosFCBFormat should fail when the file contains upper-case chars on a case-sensitive file system. This will probably make it impossible to access some files in certain cases though. I'm afraid it's not possible to support case-sensitive file systems 100% right given that Windows apps don't preserve case correctly. -- Alexandre Julliard julliard(a)winehq.com

Aug. 29, 2002

Re: Wine Ma os X port

by Francois Gouget

On Wed, 28 Aug 2002, Lionel Ulmer wrote: [...] > Anyway, if you do that, you would need to simulate also a full Linux kernel > on this emulator (as otherwise, on what system would emulated Wine run). Not necessarily. What you propose to do for Wine can be done for the C and X11 libraries. Then you get an emulator that lets you run x86 Linux applications on a PPC machine... including Wine. It is similar, though more complex, to FreeBSD's Linux emulation mode. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ $live{free} || die "";

Aug. 28, 2002

WIN_Handle{16,32} questions

by Michael Stefaniuc

Hello, while converting HWND to a void* i've seen that the WIN_Handle{16,32} functions were used (but not everywhere) to do the conversion HWND16 <--> HWND. WIN_Handle16 is declared and implemented in include/win.h and WIN_Handle32 is also declared in include/win.h but implemented in windows/win.c . I have used both functions with success in dlls/user/, windows/, controls/ but i would have to link to windows/win.c to make that work for other dlls too. Assuming that WIN_Handle{16,32} are not windows funtions (a search on google has given only links to wine pages) i would do following: - rename WIN_Handle{16,32} to HWND_{16,32} to make the naming consistent to the othe handle conversions - maybe remove the declaration of the two functions from include/win.h (or at least don't include win.h where it isn't yet used) - define HWND_16 as macro like the other HANDLE_16 macros and put it directly in the files where it's needed - HWND_32 has to do a little bit more work then the other HANDLE_32 macros and i would keep it as function. This means it has to be duplicated in every dll that needs it and one of the *16.c files in the dll directory would be the place to put it in. Comments? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 28, 2002

Re: DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Andreas Mohr

On Wed, Aug 28, 2002 at 06:35:08PM +0200, Martin Wilck wrote: > I wrote on 2002-06-27: > > > > $ make test > > > /home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so' > > > make: *** [tests/alloc.ok] Fehler 1 > > > > Am I the only one with this problem? Or is it so trivial that I should > > have figured it out? > > I have finally figured this out. It has to do with some (intentional?) > DOSFS_FindUnixName() weirdness. > > My wine sources are in a directory /home/martin/Software/Wine/CVS/wine. > /home/martin is my Windows drive Y: > > Now in /home/martin/Software, I have subdirectories "Wine" and "wine". > DOSFS_FindUnixName() uses "wine" because > a) DOSFS_ReadDir returns it first, > b) The DOS short names match (the Unix names obviously don't). > > Since "wine" is the wrong path, the search fails shortly after. > This happens even if I set the Filesystem type of drive Y: to "unix". > > I guess this is the right thing to do on Windows-style file systems, > but should it be this way on a "unix" file system, too? > > The patch below does what I'd consider "sane" behaviour on Unix. > Alternatively, on a "unix" filesystem, one could search the whole > directory for exact matches, and try short names only if that fails. Well, if your patch makes sure that on a "unix" mapping (as opposed to "win95" !) we only lookup the *exact* case sensitive name instead of iterating through all sorts of case cases (heh ! :), then I guess your patch is right. I guess nobody really cared about having correct behaviour of the "unix" mapping mode. (since everybody should use "win95" for normal use anyway) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

Aug. 28, 2002

Re: Patch to restore iconified window

by Duane Clark

Alexandre Julliard wrote: > Duane Clark <dclark(a)akamail.com> writes: > > >>Unlike most other apps, when iconified fpga_editor triggers >>X11DRV_ShowWindow() with a cmd==SW_HIDE, to hide the window. When >>X11DRV_MapNotify() was subsequently called, it did nothing because >>WS_VISIBLE was not set. This patch fixes that. >> >>I've been using this patch with everything I run for about 5 months now. >> >>Log message: >> Fix restoring of windows that were iconified with SW_HIDE. > > > Well, SW_HIDE is supposed to hide the window, not iconify it, so we > are not supposed to get a MapNotify at this point. What is probably > missing is proper handling for hiding an iconified window. > More particularly, I see that the ShowWindow function in Wine first calls a user function and then sends the message (WM_WINE_SHOWWINDOW, cmd) to the window. Most apps don't seem to have a user function, so I guess the later message iconifies the window. In the case of Xilinx, there is a user function that just does: 0806f758:Call window proc 0x5f401b81 (hwnd=00010021,msg=WM_SHOWWINDOW,wp=00000006,lp=00000000) It is within this call that the X11DRV_ShowWindow() with a cmd==SW_HIDE is called, which in turn calls trace:win:SetWindowPos hwnd 10021, after 0, 0,0 (0x0), flags 00000097 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_NOZORDER SWP_NOACTIVATE SWP_HIDEWINDOW 0806f758:Call x11drv.SetWindowPos(404863c8) ret=4077aa2e Then all this returns and Wine sends the (WM_WINE_SHOWWINDOW, cmd) message, which does another SetWindowPos. So the SetWindowPos command is sent twice, though I haven't figured out whether that is the problem.

Aug. 28, 2002

Re: Need to know some macro values

by Andriy Palamarchuk

Dmitry, one of the ERROR_ constant values you provided to me looks suspicious: ERROR_AUDITING_DISABLED c0090001 All other error codes have much lesser values (the biggest is 14011 - 0x36bb). The value for this error code reminds me values for STATUS_ constants. Could you check if this is correct value? Is it definend in header file with other ERROR_ constants or with STATUS_ constants? Thank you for help, Andriy __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 28, 2002

Re: BreakOnDllLoad crashes Wine

by Eric Pouech

> Has anyone else had this problem? same here. a dirty hacked fix is attached. I'll post later on a decent fix to this pb A+ Index: debugger/winedbg.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/winedbg.c,v retrieving revision 1.64 diff -u -r1.64 winedbg.c --- debugger/winedbg.c 2 Aug 2002 19:00:53 -0000 1.64 +++ debugger/winedbg.c 28 Aug 2002 17:33:20 -0000 @@ -600,7 +600,8 @@ if (!DBG_IVAR(BreakOnAttach)) break; } - DEBUG_context.ContextFlags = CONTEXT_CONTROL + handle_execpt: + DEBUG_context.ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER #ifdef CONTEXT_SEGMENTS | CONTEXT_SEGMENTS @@ -764,6 +765,7 @@ { DEBUG_Printf(DBG_CHN_MESG, "Stopping on DLL %s loading at %08lx\n", buffer, (unsigned long)de->u.LoadDll.lpBaseOfDll); + goto handle_execpt; ret = TRUE; } break;

Aug. 28, 2002

"conformance" tests succeeding in TODO block ...

by Paul Millar

Hi, The test in dlls/kernel/tests/path.c:360 succeeds despite being marked "todo". path.c:360: Test succeeded inside todo block: GetTempPathA should not have modified the buffer Trivial diff not included :) Cheers, Paul. ---- Paul Millar

Aug. 28, 2002

Re: Return value GetStockObject

by Vincent Béron

Le mer 28/08/2002 à 11:10, Fabian Cenedese a écrit : > Hi again > > In my app I try to get a handle to a system font with following call: > HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); > If the call succeeds it should return a handle to the requested object, > otherwise zero. In Windows I get something like 0x018A000E (looks ok), > but in Wine I get 0x0000009E. Even not zero I can't imagine that this is > a valid handle (address). ANSI_FIXED_FONT is never really used in Wine, > only SYSTEM_FONT. > Is this an error or am I barking up the wrong tree? In Wine, handles are not (yet) all void * (see bug #90). Even then, it doesn't mean a handle is a valid heap address; I know there are a couple places in Wine where they are used as an index in an array locating all objects of a kind. It doesn't exactly follow the Windows convention, but I think handles are supposed to be passed back to APIs, not handled (dereferenced) directly by apps. So 0x0000009E doesn't strike me as bad. If you use it in calls to font APIs, does it work correctly? Vincent

Aug. 28, 2002

DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

by Martin Wilck

I wrote on 2002-06-27: > > $ make test > > /home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so' > > make: *** [tests/alloc.ok] Fehler 1 > > Am I the only one with this problem? Or is it so trivial that I should > have figured it out? I have finally figured this out. It has to do with some (intentional?) DOSFS_FindUnixName() weirdness. My wine sources are in a directory /home/martin/Software/Wine/CVS/wine. /home/martin is my Windows drive Y: Now in /home/martin/Software, I have subdirectories "Wine" and "wine". DOSFS_FindUnixName() uses "wine" because a) DOSFS_ReadDir returns it first, b) The DOS short names match (the Unix names obviously don't). Since "wine" is the wrong path, the search fails shortly after. This happens even if I set the Filesystem type of drive Y: to "unix". I guess this is the right thing to do on Windows-style file systems, but should it be this way on a "unix" file system, too? The patch below does what I'd consider "sane" behaviour on Unix. Alternatively, on a "unix" filesystem, one could search the whole directory for exact matches, and try short names only if that fails. Martin Index: dos_fs.c =================================================================== RCS file: /home/wine/wine/files/dos_fs.c,v retrieving revision 1.117 diff -u -r1.117 dos_fs.c --- dos_fs.c 27 Aug 2002 01:13:59 -0000 1.117 +++ dos_fs.c 28 Aug 2002 16:27:47 -0000 @@ -760,7 +760,7 @@ if (!strncmpiW( long_name, name, len )) break; } } - if (dos_name[0]) + if (dos_name[0] && ignore_case) { /* Check against hashed DOS name */ if (!short_name) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Aug. 28, 2002

Contact info / Leaving Sun

by Gregg Mattinson

Unfortunatly, this is my last week at Sun. I will no longer be able to submit Sparc / Solaris patches, but I will probably continue working on Wine from home on i386 / RedHat. If anyone needs to contact me, my home email address is grmattin(a)uwaterloo.ca Thanks, Gregg Mattinson Co-op Developer Sun Microsystems of Canada

Aug. 28, 2002

Return value GetStockObject

by Fabian Cenedese

Hi again In my app I try to get a handle to a system font with following call: HGDIOBJ hobj=GetStockObject(ANSI_FIXED_FONT); If the call succeeds it should return a handle to the requested object, otherwise zero. In Windows I get something like 0x018A000E (looks ok), but in Wine I get 0x0000009E. Even not zero I can't imagine that this is a valid handle (address). ANSI_FIXED_FONT is never really used in Wine, only SYSTEM_FONT. Is this an error or am I barking up the wrong tree? Thanks Fabi

Aug. 28, 2002

Re: New win api docs

by Andreas Mohr

On Wed, Aug 28, 2002 at 08:04:41PM +0900, Dmitry Timoshkov wrote: > "Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > > > here is the documentation for the API's that m$ had to disclose after > > the settlement: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/… > > And nothing regarding undocumented comctl32 interfaces... > > Almost all disclosed APIs are already known or useless. Well, did you expect otherwise from a company known to be in bed with government ? William B. Gates should probably do a name change to "Bill of Rights". </sarcasm> Well, but at least they did publish some interfaces, which is actually more than I expected from such a company. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

Aug. 28, 2002

Re: New win api docs

by Michael Stefaniuc

On Wed, Aug 28, 2002 at 08:16:36AM -0400, tom wrote: > Dmitry Timoshkov wrote: > >"Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > >>here is the documentation for the API's that m$ had to disclose after > >>the settlement: > >>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/… > >And nothing regarding undocumented comctl32 interfaces... > > > >Almost all disclosed APIs are already known or useless. > Yea here is a nice link : http://www.theregister.co.uk/content/4/26803.html > > It tell's the real story about the API documentation ;-) Yes, i've seen it too on http://www.heise.de/newsticker/data/ps-28.08.02-000/ (in german only) but sent the email before I've read the lower part of the message (sorry to have spamed the list). bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 28, 2002

Re: New win api docs

by tom

Dmitry Timoshkov wrote: >"Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > > > >>here is the documentation for the API's that m$ had to disclose after >>the settlement: >>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/… >> >> > >And nothing regarding undocumented comctl32 interfaces... > >Almost all disclosed APIs are already known or useless. > > > Yea here is a nice link : http://www.theregister.co.uk/content/4/26803.html It tell's the real story about the API documentation ;-) Tom

Aug. 28, 2002

Re: Wine Status

by Jas Sandys-Lumsdaine

I'm completely new to the Wine project mailing list - but I noticed on the status page mentioned below there's a section for "CPU Emulation" which has "No serious efforts yet". Is there some plan to integrate bochs (or some other) x86 emulator into WINE so WINE can be run on non-x86 platforms. I realise this is very non-critical to 1.0 release! Just interested. Jas. >The Wine Status page located here : >http://www.winehq.com/about/index.php?status >Has gone for about one year now with out updates and I

Aug. 28, 2002

BreakOnDllLoad crashes Wine

by Fabian Cenedese

Hi I set the registry setting BreakOnDllLoad to 1 to find a problem in the DllMain function of my dll. Like that WineDbg stops first while loading NTDll.dll. After continuing with c it stops again at Kernel32.dll. If I try now to continue with c I get an "illegal instruction in 32-bit code" and I can't continue. Without the registry setting it starts up without a problem. Has anyone else had this problem? (WinNT4, Wine-20020804, all dlls builtin) WineDbg starting on pid 81433c8 Loaded debug information from ELF 'wine' (0x00000000) Breakpoint 2 at 0x4000c714 (_end+0x37fbefec) Loaded debug information from ELF '/usr/local/lib/libntdll.dll.so' (0x4002b000) Loaded debug information from ELF '/usr/local/lib/libwine.so' (0x40125000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so' (0x4013d000) No debug information in ELF '/lib/libm.so.6' (0x40207000) No debug information in ELF '/lib/libc.so.6' (0x4022b000) No debug information in ELF '/lib/libdl.so.2' (0x40353000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from 32bit DLL 'C:\imd\Bin\ImdD.exe' (0x18000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40063000) Stopping on DLL C:\WINDOWS\SYSTEM\NTDLL.DLL loading at 40063000 Wine-dbg>c No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x4084b000) Stopping on DLL C:\WINDOWS\SYSTEM\KERNEL32.DLL loading at 4084b000 Wine-dbg>c First chance exception: illegal instruction in 32-bit code (0xbffff3d6). In 32-bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:bffff3d6 ESP:405c65d0 EBP:bffff3c4 EFLAGS:00010243( R- 00 I Z- - 1C) EAX:4001600c EBX:40015a60 ECX:bffff3c4 EDX:4001600c ESI:40016004 EDI:4001600c Stack dump: 0x405c65d0 (NTDLL.DLL.sscanf+0x33dd10): 4034db98 00000008 080501b8 40000660 0x405c65e0 (NTDLL.DLL.sscanf+0x33dd20): 405c6668 4000bcd0 00000003 bffff3c4 0x405c65f0 (NTDLL.DLL.sscanf+0x33dd30): 00000003 080501b8 405c6668 4032b6b1 0x405c6600 (NTDLL.DLL.sscanf+0x33dd40): bffff3d4 08050354 00000000 00000000 0x405c6610 (NTDLL.DLL.sscanf+0x33dd50): 40015a60 00000000 08050108 00009052 0x405c6620 (NTDLL.DLL.sscanf+0x33dd60): 4022a000 00000000 00000000 00000000 0x405c6630 (NTDLL.DLL.sscanf+0x33dd70): 0011: sel=008f base=401225c0 limit=00000fff 32-bit rw- Backtrace: =>0 0xbffff3d6 (KERNEL32.DLL.TryEnterCriticalSection+0x7f77005a) (ebp=bffff3c4) 1 0xbffff58f (KERNEL32.DLL.TryEnterCriticalSection+0x7f770213) (ebp=bffff57b) 2 0x636f6c2f (KERNEL32.DLL.TryEnterCriticalSection+0x22e678b3) (ebp=7273752f) 0xbffff3d6 (KERNEL32.DLL.TryEnterCriticalSection+0x7f77005a): Wine-dbg>c Unhandled exception: illegal instruction in 32-bit code (0xbffff3d6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:bffff3d6 ESP:405c65d0 EBP:bffff3c4 EFLAGS:00010243( R- 00 I Z- - 1C) EAX:4001600c EBX:40015a60 ECX:bffff3c4 EDX:4001600c ESI:40016004 EDI:4001600c Stack dump: 0x405c65d0 (NTDLL.DLL.sscanf+0x33dd10): 4034db98 00000008 080501b8 40000660 0x405c65e0 (NTDLL.DLL.sscanf+0x33dd20): 405c6668 4000bcd0 00000003 bffff3c4 0x405c65f0 (NTDLL.DLL.sscanf+0x33dd30): 00000003 080501b8 405c6668 4032b6b1 0x405c6600 (NTDLL.DLL.sscanf+0x33dd40): bffff3d4 08050354 00000000 00000000 0x405c6610 (NTDLL.DLL.sscanf+0x33dd50): 40015a60 00000000 08050108 00009052 0x405c6620 (NTDLL.DLL.sscanf+0x33dd60): 4022a000 00000000 00000000 00000000 0x405c6630 (NTDLL.DLL.sscanf+0x33dd70): 0011: sel=008f base=401225c0 limit=00000fff 32-bit rw- Backtrace: =>0 0xbffff3d6 (KERNEL32.DLL.TryEnterCriticalSection+0x7f77005a) (ebp=bffff3c4) 1 0xbffff58f (KERNEL32.DLL.TryEnterCriticalSection+0x7f770213) (ebp=bffff57b) 2 0x636f6c2f (KERNEL32.DLL.TryEnterCriticalSection+0x22e678b3) (ebp=7273752f) 0xbffff3d6 (KERNEL32.DLL.TryEnterCriticalSection+0x7f77005a): Wine-dbg>c Invalid address for breakpoint 1, disabling it Invalid address for breakpoint 2, disabling it Process of pid=081433c8 has terminated Thanks Fabi

Aug. 28, 2002

Re: New win api docs

by Dmitry Timoshkov

"Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > here is the documentation for the API's that m$ had to disclose after > the settlement: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/… And nothing regarding undocumented comctl32 interfaces... Almost all disclosed APIs are already known or useless. -- Dmitry.

Aug. 28, 2002

New win api docs

by Michael Stefaniuc

Hello, here is the documentation for the API's that m$ had to disclose after the settlement: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/… bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Aug. 28, 2002

Re: [Help] Handwriting input?

by leanne

When I found that it got: switch (event->type) { case SelectionNotify: /* all of these should be caught by XCheckTypedWindowEvent() */ FIXME("Got SelectionNotify - must not happen!\n"); Handwriting is through clipboard, where I could get more information about clipboard mechanism of X and WINE? Very thanks. leanne wrote: > Dear all, > > Does WINE support hand-writing input? > I got a software and use mouse for input, here is my error: > > > err:clipping:CLIPPING_UpdateGCRegion DC is dirty. Please report this. > err:clipping:CLIPPING_UpdateGCRegion DC is dirty. Please report this. > > Any idea? > > Thanks in advance. > Leanne > > >

Aug. 28, 2002

Re: RFC: 'test' bugzilla keyword

by Francois Gouget

On Tue, 27 Aug 2002, Paul Millar wrote: [...] > > Maybe 'conformance' would work? > > Personally, I prefer "regression" to "conformance", although both are > applicable names. The problem is we already have a 'regression' keyword with a reasonable meaning: 'bugs relating to programs that were working at one time but stoped working for some reason'. But this does not specifically cover the 'conformance test suite'. If a conformance test used to work and no longer does, then I think it would be reasonable to tag it as 'conformance, regression'. But I have also found that some tests do not pass on Windows. IIRC, there's a test having to do with TEMP that fails if it is set to 'c:\Windows\Temp' rather than 'c:\'. I would like to be able to make a bug report and tag it with a keyword to indicate it is related to the 'conformance test suite' (or whatever we want to call it). Similarly, there would be reports to be made about the conformance tests as run on FreeBSD and Solaris. And note that none of these are regressions. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

Aug. 28, 2002

Re: Patch to restore iconified window

by Alexandre Julliard

Duane Clark <dclark(a)akamail.com> writes: > Unlike most other apps, when iconified fpga_editor triggers > X11DRV_ShowWindow() with a cmd==SW_HIDE, to hide the window. When > X11DRV_MapNotify() was subsequently called, it did nothing because > WS_VISIBLE was not set. This patch fixes that. > > I've been using this patch with everything I run for about 5 months now. > > Log message: > Fix restoring of windows that were iconified with SW_HIDE. Well, SW_HIDE is supposed to hide the window, not iconify it, so we are not supposed to get a MapNotify at this point. What is probably missing is proper handling for hiding an iconified window. -- Alexandre Julliard julliard(a)winehq.com

Aug. 27, 2002

Re: RFC: 'test' bugzilla keyword

by Paul Millar

Hi everyone, A few thoughts ... although the bits about winelib should be taken with a pinch of salt: I've never used winelib in anger. Personally, I don't like the keyword "test". Its far too ambiguous. On Tue, 27 Aug 2002, Francois Gouget wrote: > Maybe 'conformance' would work? Personally, I prefer "regression" to "conformance", although both are applicable names. Yes, the tests are checking that wine _conforms_ to what we've specified (via the tests) as correct windows behaviour, but equally if a test fails then wine has _regressed_ to a more primitive (and therefore less useful) state. I think most people would think of "regression testing" as an automated process: a suite of many (usually short) tests all of which which must pass. This is just "make testclean && make test || echo Regression found" :) The problem (in terms of nomenclature) is that wine (as opposed to winelib) runs applications. So a regression is also when an application doesn't behave as well as it did. (This is in the docs as what we mean by "regression".) But, from another point-of-view, running an application is just another test. Its a test that checks _lots_ of different aspects of wine. Perhaps another possibility worth considering is winelib: whether test applications continue to build correctly. If something were to interfere with winelib (perhaps subtle enough not to affect wine running of native applications), then a different type of regression has been introduced. So I'd say we have possibility of regressions in: 1. core Windows functionality - currently tested by many "little" tests: an automated process. 2. running native applications - tested by people using wine and complaining when something breaks. 3. winelib infrastructure - tested by building tools? People complaining? If we cannot sub-categorise "regression" in bugzilla, how about implicitly subgrouping. For example, calling them something like: regression-automated regression-application regression-winelib Alternatively, we could have the "regression" keyword and also the "application", "winelib", "automated" keywords. The bug-reporter adds whatever s/he feels best describes their bug. Cheers, Paul. ---- Paul Millar

Aug. 27, 2002

Re: Wine Ma os X port

by Francois Gouget

On Tue, 27 Aug 2002, Fausto Saporito wrote: > Hello, > > i'm completely a newbie, but should be possible merge bochs code in > order to emulate an x86 cpu in wine? > The MacOS port of Bochs is quite operative. Trying to run an x86 Windows application inside a non-x86 Wine(lib) environment is going to be a nightmare. If you want to run Wine (i.e. the binary emulator) on non-x86 architectures, the best approach is to run the Windows application and Wine-x86 in an x86 emulator. If your emulator is fast enough to run the Windows application with a reasonable performance, then it should be fast enough to run Wine-x86 too. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

Aug. 27, 2002

Re: Wine Hides On-board RAM

by Francois Gouget

On Mon, 26 Aug 2002, Ian D. Stewart wrote: [...] > > To differentiate from Windows, nobody's suggesting you remove and > > reinstall > > Linux, here :-) > > Unless I misunderstood Andreas' e-mail, that i pretty much what he is > recomending. Not quite. You can compile and run a new Linux kernel without reinstalling your system. Furthermore, you can switch back and forth between the old kernel and the new one at each reboot. Andreas was recommending a blind upgrade with a prayer that the bug be fixed, but you can also view this as a way to diagnose the problem, pretty much like one would do a binary search on Wine's CVS sources to find when a bug appeared. In your case, either the bug is still present in the latest kernel which then means you are not wasting your time trying to fix a bug that has already been fixed, or it is no longer present and then analyzing the differences between the two kernels may help you find what was wrong. Note: I'm running Wine a lot on my system and have never seen MemTotal change (with 2.4.17 and older kernels). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Aug. 27, 2002

Re: RFC: 'test' bugzilla keyword

by Francois Gouget

On Sat, 24 Aug 2002, Tony Lambregts wrote: [...] > I would suggest that "apifailure" would be better (and longer..) but > It would be great to have this. The problem with apifailure (and api*) is that it may be the test that is wrong, not the API implementation. Also I would like something that reminds people this is about the conformance tests (previously known as regression tests). Maybe 'conformance' would work? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Aug. 27, 2002

Re: Wine Ma os X port

by Andriy Palamarchuk

--- Fausto Saporito <fausto.saporito(a)virgilio.it> wrote: > Hello, > > i'm completely a newbie, but should be possible > merge bochs code in > order to emulate an x86 cpu in wine? > The MacOS port of Bochs is quite operative. Such idea was descussed before many times. Run search on Google with keywords Wine bochs for more information. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 27, 2002

Re: Need to know some macro values

by Andriy Palamarchuk

Fabian, thank you for help. --- Fabian Cenedese <Cenedese(a)indel.ch> wrote: > > >I'm going to add some define's to our headers, but > >can't find their values online. > >Can somebody who has Microsoft headers compile and > run > >the test application and send me the output? > > I tried but I failed. I don't know where you have > these definitions from, I'm working on implementing a function LsaNtStatusToWinError, which maps NT status codes to Windows error codes, according to: http://support.microsoft.com/default.aspx?scid=KB;EN-US;q113996& > but they aren't anywhere in the normal MSVC6 Studio. > Also MSDN > doesn't know anything. Maybe in some SDK... I just got response from Dmitry. You are right, he found almost all of them in XP/Win2000 development kits headers. Thank you, Andriy __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com

Aug. 27, 2002

Re: Need to know some macro values

by Fabian Cenedese

>I'm going to add some define's to our headers, but >can't find their values online. >Can somebody who has Microsoft headers compile and run >the test application and send me the output? I tried but I failed. I don't know where you have these definitions from, but they aren't anywhere in the normal MSVC6 Studio. Also MSDN doesn't know anything. Maybe in some SDK... Sorry Fabi

Aug. 27, 2002

Re: Wine Ma os X port

by Fausto Saporito

Hello, i'm completely a newbie, but should be possible merge bochs code in order to emulate an x86 cpu in wine? The MacOS port of Bochs is quite operative. regards, fausto Lunedì, Agosto 26, 2002, alle 09:27 PM, Lionel Ulmer ha scritto: >> b) Wine includes an x86 emulator and gets nearly re-written. > > Well, the 'nearly gets re-written' is maybe a little bit exagerated.... > Winelib already works on PPC (or at least Marcus is trying to get it to > work). That is already a first step :-) After, there are a lot of tricky > stuff to do, but no big rewrite (well, except in the core DLLs like > Kernel > and the server). > > I wonder if anybody ever started a 'bug' or 'task' on Bugzilla to write > down > everything that would be needed to support Wine + emulation. > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ >

Aug. 27, 2002

Re: wine/ dlls/kernel/wowthunk.c dlls/ntdll/file.c ...

by Dmitry Timoshkov

"Marcus Meissner" <meissner(a)suse.de> wrote: > > Convert most of the file APIs to Unicode. > > Is it just me or did this patch and several more not go over wine-patches? It's a usual merge from Crossover Office which Alexandre does every time when new version of cxoffice is released. -- Dmitry.

Aug. 27, 2002

Re: wine/ dlls/kernel/wowthunk.c dlls/ntdll/file.c ...

by Marcus Meissner

On Mon, Aug 26, 2002 at 08:14:00PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1030410840440784468854876 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 02/08/26 20:14:00 > > Modified files: > dlls/kernel : wowthunk.c > dlls/ntdll : file.c > dlls/winedos : int21.c > files : directory.c dos_fs.c drive.c file.c profile.c > smb.c smb.h > include : drive.h file.h > loader : task.c > memory : registry.c > misc : registry.c > msdos : dosconf.c int11.c int21.c ioports.c > scheduler : process.c > > Log message: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Convert most of the file APIs to Unicode. Is it just me or did this patch and several more not go over wine-patches? Ciao, Marcus

Aug. 27, 2002

Re: Wine Hides On-board RAM

by Ian D. Stewart

On 2002.08.25 07:38 Andreas Mohr wrote: > On Sun, Aug 25, 2002 at 08:17:09AM -0400, Ian D. Stewart wrote: > > On 2002.08.18 12:21 Andreas Mohr wrote: > > > On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote: > > > > After running Wine for awhile, /proc/meminfo reports MemTotal as > > > 32680 > > > > kb. The system performs as if it only had 32 MB of RAM. A > reboot > > > of > > > > the system resets total memory to the proper value. > > > > > > > > My question is: > > > > > > > > 1) Has anybody else encountered this? > > > > 2) Does anyone know what causes this, or better yet how to avoid > it? > > > > 3) Is there anyway to recover the lost RAM short of a reboot? > > > > > > Huh ? This is very, very, VERY strange ! > > > Something like this should never happen. > > > Are you sure it's caused by Wine only, or maybe it is due to > faulty > > > memory > > > instead ? (and thus the board/Linux notices that only 32MB are > useable > > > and resorts to accessing 32MB only). > > > > Well I can't say with absolute certainty that it's caused by Wine, > but > > the system runs without any problems for extended periods of time so > > > long as I don't run Wine, and consistently 'loses' memory when I > *do* > > run wine. > > > > I don't know exactly what's going on. I do know that there appears > to > > be some sort of threshold that is reached at which point the memory > > hiding occurs (e.g., the same issue arises whether I run Wine for 5 > > hours at one shot or for 30 minutes a day for 10 days) and the > > threshold isn't 'reset' until I reboot. > > > > > > > > Again, I'm utterly puzzled when hearing such a story. > > > Or maybe Wine accesses some Linux memory management function in > some > > > way > > > that causes Linux to tamper with the value for some reason ? > > > This wouldn't be the first time that Wine is the only program to > > > reveal > > > some severe bug in Linux memory management... > > > > > > Definitely try upgrading your kernel, too. > > > > I have no problem with upgrading, but I would like to know *why* I > am > > upgrading (i.e., what bug is causing the problem, and how does the > new > > kernel address the bug). To do otherwise strikes me as being > > equivelant to the tendency in the Windows community whenever > something > > odd happens. > *sigh* > You're definitely not of the easy kind of people, are you ? ;-) > A lot of people would just upgrade and be happy in case the bug is > fixed, > but you... :) Guilty as charged ;) > > Well, if you're so eager to learn what the problem is, then I'd > suggest > to get your hands pitch black dirty immediately ;-) > > Find out where /proc/meminfo gets fed with values, then find out which > part messes with the MemTotal value in any way. > > Hmm, arch/i386/mm/init.c/si_meminfo() sounds like a sure winner. > I'd suggest looking for the totalram_pages variable (add logging > whenever > that one gets modified in some way). > OTOH I don't see any place where there is a direct assignment of that > variable. Hmm, where does that variable even get initialized then ??? > (well, probably declaration auto initialization then) > > Oh well, good luck ! ;) Thanks. I'll report back once I know more. Ian

Aug. 27, 2002

Re: Wine Hides On-board RAM

by Ian D. Stewart

On 2002.08.26 09:03 Derek Broughton wrote: > From: "Ian D. Stewart" <idstewart(a)compuvative.com> > > > I have no problem with upgrading, but I would like to know *why* I > am > > upgrading (i.e., what bug is causing the problem, and how does the > new > > kernel address the bug). To do otherwise strikes me as being > > equivelant to the tendency in the Windows community whenever > something > > odd happens. > > Not at all. Wine has always been distributed as 'alpha' software, and > thus > we can expect that a lot of things are continuously getting fixed. > Nobody's > going to try fixing something that's only reported in an old version > of the > software. So you upgrade, test again, and if it's still a problem > report > the bug. I thonk you misunderstood my e-mail. The problem apparently does not lie with Wine per se (I have no problem with upgrading Wine, especially considering its alpha status and active development, and have on several occasions IOT track down regression bugs), but rather with the memory management aspects of the Linux kernel. > > To differentiate from Windows, nobody's suggesting you remove and > reinstall > Linux, here :-) Unless I misunderstood Andreas' e-mail, that i pretty much what he is recomending. Ian

Aug. 27, 2002