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

Re: wine/dlls x11drv/x11drv_main.c x11drv/x11drv.s ...

by Dmitry Timoshkov

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Log message: > Aric Stewart <aric(a)codeweavers.com> > Use X11 XIM callbacks to enable full IME support. > Correct some timing issues with XIM input. > Start to provide the framework for the MSIME messages. > langid = PRIMARYLANGID(LANGIDFROMLCID(layout)); > if (langid == LANG_CHINESE || langid == LANG_JAPANESE || langid == LANG_KOREAN) > - layout |= 0xe001 << 16; /* FIXME */ > + layout = 0xe001 << 16; /* FIXME */ The above change looks wrong. This thrashes low 16 bits of layout id. Moreover, 0xe001 was added already in the global keyboard table list for Japanese kbd layout (btw, why not for Chinese and Korean?). -- Dmitry.

Jan. 21, 2004

Re: WINMM problem with Half-Life

by Mike McCormack

Eric Pouech wrote: >> Any ideas? > > as an ugly hack, does setting the dwEventCount in the WINE_MCIAVI struct > as volatile help ? (private_mciavi.h). No, that didn't help, the one below does: Mike diff -u -r1.1.1.10 mciavi.c --- dlls/winmm/mciavi/mciavi.c 10 Jan 2004 00:11:58 -0000 1.1.1.10 +++ dlls/winmm/mciavi/mciavi.c 21 Jan 2004 02:51:15 -0000 @@ -503,7 +503,7 @@ } if (wma->lpWaveFormat) { - while (wma->dwEventCount != nHdr - 1) + while (wma->dwEventCount < (nHdr - 1) ) { LeaveCriticalSection(&wma->cs); Sleep(100);

Jan. 21, 2004

Re: charset related compilation errors in authors.c

by Hans Leidekker

On Tuesday 20 January 2004 15:28, Mike Hearn wrote: > I've carbon copied this to wine-devel. This looks like some > charset/toolchain issue, but I'm not sure how to diagnose it. This is on > Fedora Core 1 yes? What is the output of > > echo $LANG You're right. It's sed becoming locale aware in FC (not version 1, but devel, maybe through an update to 1?). I already submitted a patch for this which is in latest CVS. -Hans

Jan. 21, 2004

Re: winapi_test chokes on TITLEBARINFO

by Hans Leidekker

On Tuesday 20 January 2004 11:02, Francois Gouget wrote: > Arg. Spoke a bit too quick in my previous email. This patch introduces a > new problem. When verifying the generated.c files I see a lot of diffs Well, it merely uncovers two more cases of reference variable misuse. Revised patch attached. -Hans

Jan. 21, 2004

Re: charset related compilation errors in authors.c

by jds

Hi: The variable value is: [root(a)toshiba root]# echo $LANG en_US.UTF-8 Regards ---------- Original Message ----------- From: Hans Leidekker <hans(a)it.vu.nl> To: Mike Hearn <mike(a)theoretic.com> Cc: wine-devel(a)winehq.org, jds <jds(a)soltis.cc> Sent: Tue, 20 Jan 2004 22:06:55 -0500 Subject: Re: charset related compilation errors in authors.c > On Tuesday 20 January 2004 15:28, Mike Hearn wrote: > > > I've carbon copied this to wine-devel. This looks like some > > charset/toolchain issue, but I'm not sure how to diagnose it. This is on > > Fedora Core 1 yes? What is the output of > > > > echo $LANG > > You're right. It's sed becoming locale aware in FC (not version 1, > but devel, maybe through an update to 1?). I already submitted a > patch for this which is in latest CVS. > > -Hans ------- End of Original Message -------

Jan. 21, 2004

Re: Fix dashed/solid line in Postscript output

by Alexandre Julliard

Blake Leverett <bleverett(a)att.net> writes: > Index: dlls/wineps/ps.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/ps.c,v > retrieving revision 1.23 > diff -u -r1.23 ps.c > --- dlls/wineps/ps.c 8 Dec 2003 21:40:27 -0000 1.23 > +++ dlls/wineps/ps.c 16 Jan 2004 05:26:55 -0000 > @@ -508,6 +508,7 @@ > BOOL PSDRV_WriteSetPen(PSDRV_PDEVICE *physDev) > { > char buf[256]; > + static char *last_dash = NULL; You can't use a static variable here, this would need to be stored in the device structure. But it's probably easier to always set the dash style unconditionally. -- Alexandre Julliard julliard(a)winehq.com

Jan. 21, 2004

Re: GetCommandLine issue with Dungeon Keeper

by Frank.Schruefer＠t-online.de

( REPOST, again: I was told that my massages need long time to appear because I'm not subscribed as frank.schruefer(a)t-online.de, ok, but my postings as wine(a)man-made.de (which I'm subscribed as) never come through. Maybe that is because mozilla only allows configuration for one outgoing mailserver which is the t-online one? Anything I could do about the situation? ) > > I'll soon come up with a win98 winnt comparison for the functions in > question. > I just have some trouble setting up *real* windows, believe it or not, > asrock > with SIS is nothing (old) windows' like! > Setting up wine is much easier LOL! > Hy, Ok, I made a simple test programm reading argv, GetCommandLineA and GetModuleFileNameA. I failed with NtCurrentTeb, even after installing microsoft sdk ... it didn't get linked. Well, I actually have very little experience if it comes to the C language but the test results I already have answer most of our questions already I think. I'd say the bottom line of the test results below is that wine almost perfectly simulates win32s behaviour but has no support for win9x be- haviour (regarding GetCommandLine* and argv). Changing the 'Windows' config parameter of wine in the [Version] sec- tion didn't make any difference to the test results from wine. That's what needs to be changed. Some of you suggested to always deliver full path but as some others said I also think that might break more programs than it'll make work so I'd oppose that idea. I think the solution is something like: if(GetVersion() & 0x80000000) /* not win32s */ { behave_as_win9x_and_modify_actual_command_line(); } else { behave_as_now(); } Basically: make the 'Windows' param in [Version] affect whether the command line is altered or not. So in my eyes it should come down to this: if(keeper_started_with_full_path() || wine_behaves_as_win9x_set_in_config()) { keeper_working = TRUE; } // woohoo! That I call programming ;-) To introduce a totally new config param to set wines behaviour here is neither necessary nor desireable. I see only one question remaining: at which place in wine should the commandline be modified if_win9x is 'set'? In GetCommandLineA? Guess no. Somewhere before CreateProces I think. But as I already menitioned c is not my mother tongue so I hope somebody else here might come up with the final solution ... Appendet here you'll find the source of a little test prog, a batch and the output the prog produced on: Windows 98, Windows NT 4.0 and Wine (on SuSE Linux 9.0). As I read it simulation of win9x behaviour needs to replace slashs by backslashs (which win32s has no probles with but 9x does) and relative paths by full paths and also the return of GetModuleFileNameA should be made to all uppercase - just to be on the safe side. ===================== TEST PROGRAM ==================== #include <windows.h> #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv) { int i; char buffer[1024]; printf("+++ GetCommandLineA +++\n"); printf("%s\n", GetCommandLineA()); printf("+++ GetModuleFileNameA +++\n"); GetModuleFileNameA(0, buffer, sizeof(buffer)); printf("mfna: %s\n", buffer); printf("+++ argc & argv +++\n"); printf("argc: %i\n", argc); for(i = 0; i<argc; i++) printf("argv #%i: %s\n", i, argv[i]); getch(); } ======================================================= ===================== TEST BATCH ====================== echo %0 cmdline ======================================================= ================= WIN98: FROM EXPLORER ================ +++ GetCommandLineA +++ "C:\Eigene Dateien\WineCommandLine\CMDLINE.exe" +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe ======================================================= ================= WINE: FROM EXPLORER ================= (not applicable) ======================================================= =============== WINNT4.0: FROM EXPLORER =============== +++ GetCommandLineA +++ "C:\Eigene Dateien\WineCommandLine\CMDLINE.exe" +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe ======================================================= ============ WIN98: FROM SHELL, IN .exe DIR =========== C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= ============ WINE: FROM SHELL, IN .exe DIR ============ merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline ======================================================= ========== WINNT4.0: FROM SHELL, IN .exe DIR ========== C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline ======================================================= ========== WIN98: FROM SHELL, NOT IN .exe DIR ========= C:\Eigene Dateien>winecommandline\cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= =========== WINE: FROM SHELL, NOT IN .exe DIR ========= merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien> wine winecommandline/cmdline +++ GetCommandLineA +++ winecommandline/cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: winecommandline/cmdline ======================================================= ========= WINNT4.0: FROM SHELL, NOT IN .exe DIR ======= C:\Eigene Dateien>winecommandline\cmdline +++ GetCommandLineA +++ winecommandline\cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\winecommandline\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: winecommandline\cmdline ======================================================= ============= WIN98: FROM SHELL, FULL PATH ============ C:\Eigene Dateien>"c:\eigene dateien\winecommandline\cmdline" +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE C:\Eigene Dateien>"c:/eigene dateien/winecommandline/cmdline" Befehl oder Dateiname nicht gefunden C:\Eigene Dateien> ======================================================= ============== WINE: FROM SHELL, FULL PATH ============ merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien> wine "c:\\eigene dateien\\winecommandline\\cmdline" +++ GetCommandLineA +++ "c:\eigene dateien\winecommandline\cmdline" +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:\eigene dateien\winecommandline\cmdline merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine "c:/eigene dateien/winecommandline/cmdline" +++ GetCommandLineA +++ "c:/eigene dateien/winecommandline/cmdline" +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:/eigene dateien/winecommandline/cmdline ======================================================= ============ WINNT4.0: FROM SHELL, FULL PATH ========== C:\Eigene Dateien>"c:\eigene dateien\winecommandline\cmdline" +++ GetCommandLineA +++ "c:\eigene dateien\winecommandline\cmdline" +++ GetModuleFileNameA +++ mfna: c:\eigene dateien\winecommandline\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:\eigene dateien\winecommandline\cmdline C:\Eigene Dateien>"c:/eigene dateien/winecommandline/cmdline" +++ GetCommandLineA +++ "c:/eigene dateien/winecommandline/cmdline" +++ GetModuleFileNameA +++ mfna: c:\eigene dateien\winecommandline\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: c:/eigene dateien/winecommandline/cmdline ======================================================= ============ WIN98: FROM BATCH, IN .exe DIR =========== C:\Eigene Dateien\WineCommandLine>batch C:\Eigene Dateien\WineCommandLine>echo batch batch C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= ============= WINE: FROM BATCH, IN .exe DIR =========== merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine batch wine: cannot find 'batch' merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien/WineCommandLine> wine batch.bat wine: cannot determine executable type for L"C:\\Eigene Dateien\\WineCommandLine\\batch.bat" ======================================================= =========== WINNT4.0: FROM BATCH, IN .exe DIR ========= C:\Eigene Dateien\WineCommandLine>batch C:\Eigene Dateien\WineCommandLine>echo batch batch C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline ======================================================= ========== WIN98: FROM BATCH, NOT IN .exe DIR ========= C:\Eigene Dateien>winecommandline\batch C:\Eigene Dateien>echo winecommandline\batch winecommandline\batch C:\Eigene Dateien>cmdline Befehl oder Dateiname nicht gefunden. ======================================================= =========== WINE: FROM BATCH, NOT IN .exe DIR ========= merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien> wine WineCommandLine/batch wine: cannot find 'WineCommandLine/batch' merlin(a)Merlin:~/.wine/fake_windows/Eigene Dateien> wine winecommandline/batch.bat wine: cannot determine executable type for L"C:\\Eigene Dateien\\WineCommandLine\\batch.bat" ======================================================= ========= WINNT4.0: FROM BATCH, NOT IN .exe DIR ======= C:\Eigene Dateien>winecommandline\batch C:\Eigene Dateien>echo winecommandline\batch winecommandline\batch C:\Eigene Dateien>cmdline Der Befehl ist entweder falsch geschrieben oder konnte nicht gefunden werden. Bitte überprüfen Sie die Schreibweise und die Umgebungsvariable 'PATH'. ======================================================= ============ WIN98: FROM BATCH, BY EXPLORER =========== C:\Eigene Dateien\WineCommandLine>echo C:\EIGENE~1\WINECO~1\BATCH.BAT C:\EIGENE~1\WINECO~1\BATCH.BAT C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ C:\EIGENE~1\WINECO~1\CMDLINE.EXE +++ GetModuleFileNameA +++ mfna: C:\EIGENE DATEIEN\WINECOMMANDLINE\CMDLINE.EXE +++ argc & argv +++ argc: 1 argv #0: C:\EIGENE~1\WINECO~1\CMDLINE.EXE ======================================================= ============= WINE: FROM BATCH, BY EXPLORER =========== (not applicable) ======================================================= =========== WINNT4.0: FROM BATCH, BY EXPLORER ========= C:\Eigene Dateien\WineCommandLine>echo "C:\Eigene Dateien\WineCommandLine\batch. bat" "C:\Eigene Dateien\WineCommandLine\batch.bat" C:\Eigene Dateien\WineCommandLine>cmdline +++ GetCommandLineA +++ cmdline +++ GetModuleFileNameA +++ mfna: C:\Eigene Dateien\WineCommandLine\CMDLINE.exe +++ argc & argv +++ argc: 1 argv #0: cmdline =======================================================

Jan. 21, 2004

Re: RFC on our new initiative

by Tom

Mike Hearn wrote: > > Ah yes, exponentially scalable growth. Let's hope so. Graphs of cvs > commits/patch sizes would be neat. I might stick that on my (long) todo > list :) > Here is one, http://www.winehq.org/hypermail/wine-devel/2001/11/0149.html (Wine source code size) its two years old but it's still nice to look at from time to time :) Andreas any plans to update it? Tom

Jan. 20, 2004

Re: charset related compilation errors in authors.c

by jds

Hi: The variable value is: [root(a)toshiba linux-2.6.1]# echo $LANG en_US.UTF-8 Regards ---------- Original Message ----------- From: Hans Leidekker <hans(a)it.vu.nl> To: Mike Hearn <mike(a)theoretic.com> Cc: wine-devel(a)winehq.org, jds <jds(a)soltis.cc> Sent: Tue, 20 Jan 2004 22:06:55 -0500 Subject: Re: charset related compilation errors in authors.c > On Tuesday 20 January 2004 15:28, Mike Hearn wrote: > > > I've carbon copied this to wine-devel. This looks like some > > charset/toolchain issue, but I'm not sure how to diagnose it. This is on > > Fedora Core 1 yes? What is the output of > > > > echo $LANG > > You're right. It's sed becoming locale aware in FC (not version 1, > but devel, maybe through an update to 1?). I already submitted a > patch for this which is in latest CVS. > > -Hans ------- End of Original Message -------

Jan. 20, 2004

Re: wine cvs notes and proposed keyboard detection fix.

by Shane Shields

On Tuesday 20 January 2004 5:23 am, Dmitry Timoshkov wrote: > X11 team tends to remove more than 2 characters per keysym. See > /etc/X11/xkb/symbols/tr. Turkish keyboard layout in Wine has more > than 2 for some of them. Just do 'setxkbmap tr' and run Wine with > +key,keyboard,+x11drv and look for mismatches. I have done that and piped the output to a logfile. Attached is an abbreviated version with just the icelandic and turkish detection included. It seems to be mismatching on detecting the third keysym where the key is defined in /etc/X11/xkb/symbols/tr this could be a clue :) > > That shouldn't happen. Keyboard detection code always does a full round > of comparisons with every keyboard table in x11drv. > I took another look at the code and with the trace I have to say that I was wrong :-( The trace only shows 0x0000 for the third(?) keysymb so I dont know what was returned. I believe (gingerly) that is due to the trace having a precision of 4. TRACE_(key)("mismatch for keysym 0x%04lX, keycode %d, in function X11DRV_KEYBOARD_DetectLayout where it should be TRACE_(key)("mismatch for keysym 0x%08lX, keycode %d, or my version of X11 is returning a larger value than it should. I suspect this because of the large amount of calls to the function KEYBOARD_MapDeadKeysym. Maybe the X11 guys have changed a short to a long somewhere in my version of X11 (cvs 2003-11-24) or my gcc (3.2.2) has defined them differently. If that is the case then the line ckey[i] = keysym & 0xFF; in function X11DRV_KEYBOARD_DetectLayout would change the keysym and cause a mismatch. Another thought popped up is maybe the X11 guys extended the keysymb codes to allow for 6 instead of four combinations. I will have to check the changelogs to be sure. > Other programs have no constrains implied by implementing Win32 APIs on the > top of X11. LOL -- Shane Shields Registered LFS Compiler: 7582 To drink the WINE of success you must first seek the sayings of source Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.

Jan. 20, 2004

shell32 patch 10

by Martin Fuchs

Changelog: - implemented SHGetRealIDL() Index: pidl.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/pidl.c,v retrieving revision 1.96 diff -u -p -d -r1.96 pidl.c --- pidl.c 18 Jan 2004 22:08:46 -0000 1.96 +++ pidl.c 20 Jan 2004 21:32:24 -0000 @@ -688,6 +688,7 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL /* TRACE(pidl,"--new pidl=%p\n",pidlNew);*/ return pidlNew; } + /************************************************************************* * SHGetRealIDL [SHELL32.98] * @@ -695,10 +696,37 @@ LPITEMIDLIST WINAPI ILCombine(LPCITEMIDL */ HRESULT WINAPI SHGetRealIDL(LPSHELLFOLDER lpsf, LPCITEMIDLIST pidlSimple, LPITEMIDLIST *pidlReal) { - FIXME("sf=%p pidlSimple=%p pidlReal=%p\n", lpsf, pidlSimple, pidlReal); + UINT cfShellIDList = RegisterClipboardFormatA(CFSTR_SHELLIDLIST); - pdump (pidlSimple); - return 0; + STGMEDIUM medium = {0, {0}, 0}; + FORMATETC fmt = {cfShellIDList, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL}; + + IDataObject* pDataObj; + HRESULT hr = IShellFolder_GetUIObjectOf(lpsf, 0, 1, &pidlSimple, &IID_IDataObject, 0, (LPVOID*)&pDataObj); + + if (SUCCEEDED(hr)) { + hr = IDataObject_GetData(pDataObj, &fmt, &medium); + + IDataObject_Release(pDataObj); + + if (SUCCEEDED(hr)) { + /*assert(pida->cidl==1);*/ + LPIDA pida = (LPIDA)GlobalLock(medium.hGlobal); + + LPCITEMIDLIST pidl_folder = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[0]); + LPCITEMIDLIST pidl_child = (LPCITEMIDLIST) ((LPBYTE)pida+pida->aoffset[1]); + + *pidlReal = ILCombine(pidl_folder, pidl_child); + + if (!*pidlReal) + hr = E_OUTOFMEMORY; + + GlobalUnlock(medium.hGlobal); + GlobalFree(medium.hGlobal); + } + } + + return hr; } /*************************************************************************

Jan. 20, 2004

charset related compilation errors in authors.c

by Mike Hearn

Hi, I've carbon copied this to wine-devel. This looks like some charset/toolchain issue, but I'm not sure how to diagnose it. This is on Fedora Core 1 yes? What is the output of echo $LANG at the command prompt? Maybe one of our charset experts (hi dmitry! :) knows what's up. thanks -mike On Tue, 2004-01-20 at 20:17, jds wrote: > Hi Mike: > > Iam try the compile source the wine20031212, both have the problems in compiled. > > try with manual and ./tools/wineinstall, recive is the same errors: > > make[2]: Leaving directory `/home/jds/wine-20031212/dlls/setupapi' > make[2]: Entering directory `/home/jds/wine-20031212/dlls/shell32' > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_SHELL32_ > -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 > -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o authors.o authors.c > authors.c:19: error: stray '\366' in program > authors.c:20: error: `m' undeclared here (not in a function) > authors.c:20: error: initializer element is not constant > authors.c:20: error: (near initialization for `SHELL_Authors[18]') > authors.c:20: error: syntax error before string constant > authors.c:37: error: stray '\351' in program > authors.c:46: error: stray '\366' in program > authors.c:47: error: `rklund' undeclared here (not in a function) > authors.c:47: error: initializer element is not constant > authors.c:47: error: (near initialization for `SHELL_Authors[45]') > authors.c:47: error: syntax error before string constant > authors.c:53: error: stray '\370' in program > authors.c:71: error: stray '\351' in program > authors.c:72: error: `ron' undeclared here (not in a function) > authors.c:72: error: initializer element is not constant > authors.c:72: error: (near initialization for `SHELL_Authors[70]') > authors.c:72: error: syntax error before string constant > authors.c:73: error: stray '\363' in program > authors.c:73: error: `pez' undeclared here (not in a function) > authors.c:73: error: initializer element is not constant > authors.c:73: error: (near initialization for `SHELL_Authors[72]') > authors.c:73: error: syntax error before "Caravaca" > authors.c:172: error: stray '\347' in program > authors.c:172: error: `ois' undeclared here (not in a function) > authors.c:172: error: initializer element is not constant > authors.c:172: error: (near initialization for `SHELL_Authors[171]') > authors.c:172: error: syntax error before "Gouget" > authors.c:183: error: stray '\374' in program > authors.c:184: error: `nnewig' undeclared here (not in a function) > authors.c:184: error: initializer element is not constant > authors.c:184: error: (near initialization for `SHELL_Authors[182]') > authors.c:184: error: syntax error before string constant > authors.c:240: error: stray '\366' in program > authors.c:240:13: warning: multi-character character constant > authors.c:240: error: `rgy' undeclared here (not in a function) > authors.c:240: error: initializer element is not constant > authors.c:240: error: (near initialization for `SHELL_Authors[239]') > authors.c:240: error: syntax error before '\x4e6f67' > authors.c:245: error: stray '\351' in program > authors.c:246: error: `nez' undeclared here (not in a function) > authors.c:246: error: initializer element is not constant > authors.c:246: error: (near initialization for `SHELL_Authors[244]') > authors.c:246: error: syntax error before string constant > authors.c:248: error: stray '\351' in program > authors.c:249: error: `Johansen' undeclared here (not in a function) > authors.c:249: error: initializer element is not constant > authors.c:249: error: (near initialization for `SHELL_Authors[247]') > authors.c:249: error: syntax error before string constant > authors.c:288: error: stray '\345' in program > authors.c:289: error: `ven' undeclared here (not in a function) > authors.c:289: error: initializer element is not constant > authors.c:289: error: (near initialization for `SHELL_Authors[287]') > authors.c:289: error: syntax error before string constant > authors.c:315: error: stray '\366' in program > authors.c:316: error: `m' undeclared here (not in a function) > authors.c:316: error: initializer element is not constant > authors.c:316: error: (near initialization for `SHELL_Authors[314]') > authors.c:316: error: syntax error before string constant > authors.c:323: error: stray '\374' in program > authors.c:324: error: `hl' undeclared here (not in a function) > authors.c:324: error: initializer element is not constant > authors.c:324: error: (near initialization for `SHELL_Authors[322]') > authors.c:324: error: syntax error before string constant > authors.c:330: error: stray '\351' in program > authors.c:330: error: `Marcos' undeclared here (not in a function) > authors.c:330: error: initializer element is not constant > authors.c:330: error: (near initialization for `SHELL_Authors[329]') > authors.c:330: error: syntax error before "L" > authors.c:330: error: stray '\363' in program > authors.c:402: error: stray '\345' in program > authors.c:403: error: `rd' undeclared here (not in a function) > authors.c:403: error: initializer element is not constant > authors.c:403: error: (near initialization for `SHELL_Authors[401]') > authors.c:403: error: syntax error before string constant > authors.c:408: error: stray '\351' in program > authors.c:408: error: `Manuel' undeclared here (not in a function) > authors.c:408: error: initializer element is not constant > authors.c:408: error: (near initialization for `SHELL_Authors[407]') > authors.c:408: error: syntax error before "Ferrer" > authors.c:482: error: stray '\374' in program > authors.c:483: error: `ter' undeclared here (not in a function) > authors.c:483: error: initializer element is not constant > authors.c:483: error: (near initialization for `SHELL_Authors[481]') > authors.c:483: error: syntax error before string constant > authors.c:613: error: stray '\305' in program > authors.c:613: error: stray '\366' in program > authors.c:613: error: `ngstr' undeclared here (not in a function) > authors.c:613: error: initializer element is not constant > authors.c:613: error: (near initialization for `SHELL_Authors[612]') > authors.c:613: error: syntax error before "m" > make[2]: *** [authors.o] Error 1 > make[2]: Leaving directory `/home/jds/wine-20031212/dlls/shell32' > make[1]: *** [shell32] Error 2 > make[1]: Leaving directory `/home/jds/wine-20031212/dlls' > make: *** [dlls] Error 2 > > Compilation failed, aborting install. > > Helpme please. > > Regards > > > > ---------- Original Message ----------- > From: Mike Hearn <mike(a)theoretic.com> > To: jds <jds(a)soltis.cc> > Sent: Mon, 19 Jan 2004 09:05:11 +0000 > Subject: Re: install problems IE with fresh winehq > wine-20031212-1fc1winehq.i686.rpm > > > On Sun, 2004-01-18 at 17:35, jds wrote: > > > Hi Mike: > > > I try the intall IE with you script install-ie6.sh in Fedora 1, fresh > intall > > > wine-20031212-1fc1winehq.i686, kernel 2.4.22-1.2149 > > > > > > The process no finish, pause in 72% in recive this errors: > > > > This is a known problem. For now please install Wine from WineHQ > > sources. I'm working on fixing this but the problem is a subtle one. > > > > thanks -mike > ------- End of Original Message ------- >

Jan. 20, 2004

Re: RFC on our new initiative

by Mike Hearn

On Tue, 2004-01-20 at 19:56, Jeremy White wrote: > Further, note that I > didn't say it would run 95% of all apps *perfectly*. That, I > think, is too much. Ah. The small print comes out ;) > I think back to 23 months ago when Wine barely could run MS Office, Was it really only two years ago? Amazing. I once read that reports of MS Word working came in first around 1995, and naively assumed that meant it actually worked, the rest of office at least started etc. Clearly not. > and where we've come to from there, and I think it's doable. > I think it's particularly doable if Desktop Linux continues to > accelerate and we get a bunch more help to make it happen... Ah yes, exponentially scalable growth. Let's hope so. Graphs of cvs commits/patch sizes would be neat. I might stick that on my (long) todo list :) > But I am concerned about the impact this will have on the > appdb. I didn't really want to step on the toes of anyone > that has been working on the appdb; that's a hard and largely > thankless job. But I still believe in the original > vision of the appdb (that's why I paid Jer to build it); > I just think its going to work better in a context where > it has a chance to pay for itself, so I can afford to pay > someone the dirty job of keeping it up to date. OK, I understand now. Glad that's cleared up. > We're genuinely trying to figure out the best way forward, and we want > to do what's best for everyone involved. > > As a result, we're very open to suggested changes. I've not got any suggested changes really, I was just being difficult :) thanks -mike

Jan. 20, 2004

Re: DPA_Create/Search may be missing

by Steven Edwards

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > No, I still think there is value in building the tests with different > import libs to spot problems. We'll just need to work around the > broken comctl32. While we are at it can we work around the broken msvcrt problems in mingw? "../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit'" Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 20, 2004

Re: RFC on our new initiative

by Jeremy White

> "We are confident that Wine has matured to the point that CrossOver will > run 95% of all Windows applications by the end of 2005." > > Uh, guys, are you sure that isn't over-optimistic? I mean, it seems that Wine is moving > faster than ever before and that's great, but do you have any > hard facts or statistics to back up that claim? Uh oh. I knew someone would call me on that <grin>. Actually, this did seem to be a bit over the top, but if you think about it, it doesn't seem all that unreasonable. Wine right now runs a pretty amazing number of applications, and it runs many genuinely hard ones. Further, note that I didn't say it would run 95% of all apps *perfectly*. That, I think, is too much. I think back to 23 months ago when Wine barely could run MS Office, and where we've come to from there, and I think it's doable. I think it's particularly doable if Desktop Linux continues to accelerate and we get a bunch more help to make it happen... I also have a crazy dream of buying thousands of MS Windows titles, locking Aric in room until they all install, and then nailing them all to the floor with CXTest. I think this is conceivable (except for the part where Aric goes crazy and bludgeons his way out of the room with his laptop <grin>). And, I would argue, if were to truly make an effort to get every application to install and come to the main menu, we could make my prediction come true. I just need a bit more money, and a secure enough room to hold Aric... > > I'm also a tiny bit concerned that the site seems to blur its focus a bit > - it seems to be positioned as a replacement for the appdb, despite the > fact that it's CrossOver specific: I think there's enough forkage between > CX Office and Wine now to make them basically separate products. Yah. This is a tricky one. We're genuinely motivated primarily by a desire to see Wine fly. However, we are also required by our spouses and physical law to make enough money to eat. C4 is intended as a community primarily surrounding CrossOver, although the carry over to Wine is obvious. Essentially, the C4 community becomes another benefit of buying Wine from us, rather than simply downloading it for free. So, yes, it is intentional that C4 is focused around CrossOver. But I am concerned about the impact this will have on the appdb. I didn't really want to step on the toes of anyone that has been working on the appdb; that's a hard and largely thankless job. But I still believe in the original vision of the appdb (that's why I paid Jer to build it); I just think its going to work better in a context where it has a chance to pay for itself, so I can afford to pay someone the dirty job of keeping it up to date. [snip] > Possibly there's something I'm missing here, like CXTest. Something like that > sounds invaluable for tracking regressions if it works well, and maybe it's the > secret sauce. I'm not sure. Well, we're just making this up as we go <grin>, so I expect things to evolve and grow. Further, we do think that CXTest is going to add a meaningful and useful component to this. If nothing else, I'm hoping that CXTest will let us 'lock' applications in so that once they start working right, we can prevent them from regressing. Again, the primary purpose of C4 is to give our customers somewhere meaningful to go when they want to work on an app that is outside of our 'supported' list. People can either put their money or their time where their mouth is, or stop bugging me <grin>. As an aside, we have started working on a new policy of patch submission. We had always held an internal tree, worked against it, and then submitted a delta after a release. The merging started to become unmanageable, and so we've switched policy so that (ostensibly) all of our guys submit patches here first, and then we merge into CrossOver frequently. Once we get going with C4 and CXTest, this should have the nice side effect that Wine will get a regression testing tool and a company to run said regression tests every night. (Our goal is to be able to pinpoint the exact patch that breaks half-life <grin>). > > Finally (sorry guys! :) the FAQ lists the first advantage of C4 over the appdb as > the fact that it's maintained, but the cynic in me can't help noting that if you're > capable of maintaining C4 you'd be capable of doing the same for the appdb ;) But we don't get paid to maintain the appdb, and if we did maintain it, we'd encourage people to *not* buy CrossOver, imho. We do get paid by people who buy CrossOver, and we've hopefully given them a reason to be glad that they chose to give us their dollars. > > I know I'm giving you a hard time here, and while I really appreciate all you're doing > I thought I'd better air my concerns. I appreciate the concerns; I really appreciate that you looked it over carefully and took the time to raise your concerns. We're genuinely trying to figure out the best way forward, and we want to do what's best for everyone involved. As a result, we're very open to suggested changes. Cheers, Jeremy

Jan. 20, 2004

Re: WINMM problem with Half-Life

by Eric Pouech

Mike McCormack a écrit : > Hi Eric, > > After implementing the ICCVID codec, the intro AVI in Half-Life plays > nicely, however when it finishes, WinMM gets stuck in a loop while > cleaning up in MCIAVI_mciPlay. > > I think it's trying to wait for the sound to finish, however I'm not > sure how to fix the problem. The patch below makes it work, but I'm not > sure what bad side effects it will have... > > Any ideas? as an ugly hack, does setting the dwEventCount in the WINE_MCIAVI struct as volatile help ? (private_mciavi.h). A+

Jan. 20, 2004

Re: RFC on our new initiative

by Steven Edwards

Hiya, > We've also, we hope, set the stage for a major new Wine > related initiative - we hope to encourage lots of ISVs > to certify their apps against Wine. Yes this is REALLY needed but..... > The rationale for this is pretty simple - apps won't run > on Wine as well as they do on Windows until developers start > testing against Wine. They've got to start somewhere - we're > trying to give them that beginning. > > We're obviously also hoping that this will help us to continue > funding the work we've been able to do on Wine so far. As much > of a struggle as it's been at times, we really feel lucky that > we've been able to do so much. We hope that these initiatives > will give us an extra little boost so we can help push Wine > over the hump. > > I sincerely believe that the day when we can honestly tell people > "It will most likely work nicely on Wine" is not long off. .....depends on what happens at Wineconf..... > At any rate, this is a brand new initiative for us; call it > an 0.1.7 release. We're very open to comments and thoughts > and suggestions, so I would greatly appreciate any public > or private comments you have to make. For all of this to happen WINE Must....Be....Stable. Are we going to see 0.9 tagged as the main event at Wineconf 2004? Until we have a WINE 1.x I dont think we are going to see this in large numbers. Once 1.x happens and our regression testing system is filled with unit tests it will make vendors jump on board. All in all I think its a great idea from the ReactOS side as I have been putting out feelers to ISVs Q&A people and they have no problem adding ReactOS to the already bloated list of Windows versions they have to test apps for. If this is going to really happen though we must have a stable WINE sooner rather than later. Thanks Steven PS. The goal 95% of all Windows apps on crossover is nice but I am afraid I am seeing more and more .Nyet apps out in the real world. For this to happen anytime soon we have to get on the ball with Mono and Windows.Forms. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 20, 2004

Re: RFC on our new initiative

by Mike Hearn

On Tue, 20 Jan 2004 08:05:32 -0600, Jeremy Newman wrote: > We've also, we hope, set the stage for a major new Wine related > initiative - we hope to encourage lots of ISVs to certify their apps > against Wine. Cool! But..... "We are confident that Wine has matured to the point that CrossOver will run 95% of all Windows applications by the end of 2005." Uh, guys, are you sure that isn't over-optimistic? I mean, it seems that Wine is moving faster than ever before and that's great, but do you have any hard facts or statistics to back up that claim? It's been over a decade now, and Wine still crashes and burns with most Windows apps, in my experience. Only two years to implement all the random stuff apps want? MSHTML, MSI, DCOM, get all the bugs out of window management, make installers rock solid .... I mean the list of things that we need to do in order to reach that target just boggles my mind. I'm also a tiny bit concerned that the site seems to blur its focus a bit - it seems to be positioned as a replacement for the appdb, despite the fact that it's CrossOver specific: I think there's enough forkage between CX Office and Wine now to make them basically separate products. For instance, on the front page, there is this paragraph: Up to this point, the perception has been that Wine only runs a limited number of Windows applications. For instance, CodeWeavers' CrossOver Office only officially supports about a dozen applications. However, the truth is that CrossOver runs many Windows applications quite well, although they may not be officially supported. Now, we're raising the bar. We are confident that Wine has matured to the point that CrossOver will run 95% of all Windows applications by the end of 2005. This Compatibility Center has been established in order to document that progress as Wine makes the next great leap forward. This piece of text seems to use the names Wine and CrossOver interchangably, when they are clearly different. As for the database itself, well, it seems that it duplicates a lot of stuff needlessly - take "Alone in the dark". In the appdb there is only one comment which is basically "Works great!", but there is no indication the game works in C4. There's also no indication in either database whether it actually works as of Jan 2004. Worst of all, there's no way to verify this except for a Wine developer buying a copy of the game, checking it, and possibly fixing regressions. So I'm not sure that an appdb type thing is even a good idea - a dedicated application maintainer who brings the app up to scratch, periodically checks it still works and so on is easily more valuable than a hundred appdb entries saying "This app doesn't work June 1998" or whatever, even if you have far fewer of them. The idea of advocates is a turn off for me. It sounds like a revival of the old application owners idea, except that (again) it's crossover specific. It also feels a bit misleading. I think we'd all agree that the following phrases: "Here at the Compatibility Center, we're looking for similarly talented individuals who have a passion to see their favorite Windows applications running on Linux under CrossOver." "Volunteer your time to get an application working." ... makes it sound like all you have to do to get foo-app working is download CXO nightlies and report back the results. We already have this in effect, it's called bugzilla, and we all know that getting tester feedback of sufficiently high quality to fix the bug is while not rare, not the expected outcome. Bugzilla and the appdb are littered with comments like, "The app starts but then I get a message about flat scrollbars which crashes wine". Is the CrossOver team going to trawl through C4 looking for feedback from the Advocates fixing bugs given (at best) a stack trace and a logfile? It'd be nice but the incoming workload scales much better than the workforce does. Possibly there's something I'm missing here, like CXTest. Something like that sounds invaluable for tracking regressions if it works well, and maybe it's the secret sauce. I'm not sure. Finally (sorry guys! :) the FAQ lists the first advantage of C4 over the appdb as the fact that it's maintained, but the cynic in me can't help noting that if you're capable of maintaining C4 you'd be capable of doing the same for the appdb ;) I know I'm giving you a hard time here, and while I really appreciate all you're doing I thought I'd better air my concerns. thanks -mike

Jan. 20, 2004

Re: DPA_Create/Search may be missing

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > I think that we need to switch to using Wine import libraries for MinGW > compiled tests. I sent a patch for that, but it was rejected. Alexandre, > taking into account the stance of MinGW maintainers probably it's time > to refuse to use (broken) MinGW import libs? No, I still think there is value in building the tests with different import libs to spot problems. We'll just need to work around the broken comctl32. -- Alexandre Julliard julliard(a)winehq.com

Jan. 20, 2004

WINMM problem with Half-Life

by Mike McCormack

Hi Eric, After implementing the ICCVID codec, the intro AVI in Half-Life plays nicely, however when it finishes, WinMM gets stuck in a loop while cleaning up in MCIAVI_mciPlay. I think it's trying to wait for the sound to finish, however I'm not sure how to fix the problem. The patch below makes it work, but I'm not sure what bad side effects it will have... Any ideas? Mike Index: dlls/winmm/mciavi/mciavi.c =================================================================== RCS file: /cvstrees/crossover/office/wine/dlls/winmm/mciavi/mciavi.c,v retrieving revision 1.1.1.10 diff -u -r1.1.1.10 mciavi.c --- dlls/winmm/mciavi/mciavi.c 10 Jan 2004 00:11:58 -0000 1.1.1.10 +++ dlls/winmm/mciavi/mciavi.c 20 Jan 2004 16:22:23 -0000 @@ -503,12 +503,14 @@ } if (wma->lpWaveFormat) { +#if 0 while (wma->dwEventCount != nHdr - 1) { LeaveCriticalSection(&wma->cs); Sleep(100); EnterCriticalSection(&wma->cs); } +#endif /* just to get rid of some race conditions between play, stop and pause */ waveOutReset(wma->hWave);

Jan. 20, 2004

Re: DPA_Create/Search may be missing

by Dmitry Timoshkov

"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > It is all a matter of crosscompiling conformance tests with mingw. I think that we need to switch to using Wine import libraries for MinGW compiled tests. I sent a patch for that, but it was rejected. Alexandre, taking into account the stance of MinGW maintainers probably it's time to refuse to use (broken) MinGW import libs? -- Dmitry.

Jan. 20, 2004

Re: DPA_Create/Search may be missing

by Jakob Eriksson

Dmitry Timoshkov wrote: >>>By pushing the limits on "clean room" development of the w32api, we >>>jeopardise not only the mingw project but also other projects - cygwin, >>>Watcom - that seek to provide tools mainly for ordinary developers (who >>>get no value from having DPA_Clone and friends exposed in the import >>>lib). >>> >>> > >Thanks. That's just another proof for ReactOS guys to make use of Wine >headers and libraries instead of ones provided by MinGW. > > > It is all a matter of crosscompiling conformance tests with mingw. /Jakob

Jan. 20, 2004

Re: winapi_test chokes on TITLEBARINFO

by Francois Gouget

On Tue, 20 Jan 2004, Hans Leidekker wrote: [...] > That code is mixing up the use of a variable holding a string > and a variable holding a reference. Put otherwise it forget's > to dereference a scalar ref (similar to a C pointer variable) > before using it. Patch below fixes it. Arg. Spoke a bit too quick in my previous email. This patch introduces a new problem. When verifying the generated.c files I see a lot of diffs of the form: - TEST_FIELD(BITMAPINFO, RGBQUAD[1], bmiColors, 40, 4, 1); + TEST_FIELD(BITMAPINFO, RGBQUAD[1], bmiColors, 40, 4, SCALAR(0x844a5c8)); So it looks like something is not deferenced right somewhere... I'm still as lost as before. Do you know where the bug is? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Jan. 20, 2004

Re: winapi_test chokes on TITLEBARINFO

by Francois Gouget

On Tue, 20 Jan 2004, Hans Leidekker wrote: > On Tuesday 20 January 2004 14:09, Francois Gouget wrote: > > > include/winuser.h: DWORD[CCHILDREN_TITLEBAR+1]: can't parse type > > ('DWORD') ('CCHILDREN_TITLEBAR+1') > > Can't use string ("4") as a SCALAR ref while "strict refs" in use at > > tools/winapi/c_type.pm line 283. > > That code is mixing up the use of a variable holding a string > and a variable holding a reference. Put otherwise it forget's > to dereference a scalar ref (similar to a C pointer variable) > before using it. Patch below fixes it. Yep, fixed the problem here. Thanks! -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

Jan. 20, 2004

Re: wine cvs notes and proposed keyboard detection fix.

by Dmitry Timoshkov

"Fabian Cenedese" <Cenedese(a)indel.ch> wrote: > Ahmm... I don't have keyboard problems, just out of curiosity: Would it speed > up wine starting if the keyboard was configured fixed and wine wouldn't have > to test all possible layouts? You could try it by leaving only single layout in the global table of keyboard layouts. But I doubt that it will change too much. -- Dmitry.

Jan. 20, 2004