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

WineHQ: email trouble

by Dimitrie O. Paun

Folks, Whazzup with winehq.org? I get duplicated emails, and more importantly the latency on the wine-*(a)winehq.org mailing lists is measured in (many) hours instead of seconds. What gives? -- Dimi.

April 30, 2003

Callbacks while app is looping

by Mark Westcott

Hi all, I've been working on fixing the crash in 'Gens' when trying to reassign keys. The app basically does a: while (1) { IDIRECTINPUTINTERFACE::GetDeviceState(); } Until it notices a key has been pressed. DirectInput hooks onto system keyboard events with SetWindowsHookEx(WH_KEYBOARD_LL........), but while the app is doing its nasty while(1) loop, DirectInput's callback procedure never gets called. This is as far as I can get (new to wine) - any ideas anyone? I threw a test case app that illustrates the problem (btw, the WH_KEYBOARD_LL hook has the note 'should use SendMessage instead', but I don't get what this means or know if using SendMessage instead would have anything to do with fixing this problem) -------- Mark Westcott

April 30, 2003

Native ms progs and mybe wine 1.1

by hatky

I opened a metabug that I hope some of you will like where I try to "Get native windows programs working" bug 1424 Think of it: dxdiag is a great test case for the directX part (direct draw,direct 3d, sound, music, direct play...) ftp,telnet,ping,tracert can show who good the network code is defrag will mybe show who great low level hardware accses is ? what will it do with a non fat paritation? do I hear a challange? I don't know what the rest of you think, but a big bug tree looks cool to me becouse you know you can fix something little and to how many other things it helps so this tree may get a bit big.... I don't hear no objections :) I hope some of you will help with it a bit and I think it can be a nice start for the wine 1.1 guildlines hoping to get excited responces Hatky. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

April 30, 2003

Re: WINE flag

by Shachar Shemesh

KK singh wrote: >hi, > >I have a win32 application that plays some hashing >tricks with HWND while running on win98 and uses the >fact that on win98 HWND is always 16bit. > >This application is crashing on wine configured as >win98 because HWND is something bigger than 16bit on >wine. > >Now Can I Check from inside my application code, >whether the application is running on linux or win98 >If yes then I might be able to avoid those hashing >tricks and solve the crash > > I think the last time the subject came up, the consensus was that the existance of HKLM/Programs/Wine is the best way to check whether you are running on Wine. A different matter (and one which I am not qualified to attest to) is whether it is smart for wine to be 100% win98 compatible in that regard, and whether it is smart on your program's side to do those tricks. >Regards >kks > > > Hope this helps. Shachar

April 30, 2003

Winevdm eats first parameter

by Sylvain Petreolle

Trying to run a dos program with parameters, the first parameter is eaten by winevdm. at wcmd prompt, i run : dos32a d2demo.exe and dos32a answers : syntax is DOS32A <execname.xxx> which never happened before. A small asm tutorial program about dos psp shows this problem. (attached) run "wine winevdm.exe psp.com 1 2 3 4" , it will say : Les param?tres suivants ont ?t? transmis : 2 3 4 ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 30, 2003

Re: Wine Regression

by Rein Klazes

On Wed, 30 Apr 2003 00:53:40 -0400, you wrote: > With the current cvs tree parts of the Agent news reader are broken. > > I don't know the exact date it last worked but it wasn't that long ago. > > When double clicking on a group that is empty, the dialog you would normally > see that asks if youw ant to download x headers, or all available headers, > etc displays, but only the border and title bar are drawn and then wine > crashes. Agent crashes here as well, but long before that, at startup before the splash screen is drawn. My problem is fixed by Gerald Pfeifers patch at http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/archives/2003-04/… Rein. -- Rein Klazes rklazes(a)xs4all.nl

April 30, 2003

Cygwin building part 2

by Steven Edwards

We have 5 bugs that are preventing building on cygwin. Not that it will work after it builds but lets get it to build first and then worry about running. Some of these seem like they are simple while others like the kernel32 building are very complex. I will see if I can fix the winsock bug tonight. 1. We cannot build kernel32 with the current CVS http://www.winehq.org/hypermail/wine-devel/2003/04/0765.html 2. when building wininet on cygwin we get this: internet.o(.text+0x1365): In function `InternetCloseHandle': /cygdrive/g/src/wine-dev/wine/dlls/wininet/internet.c:670: undefined reference t o `___wine_exception_handler' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 3. With winsock we are getting this: gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -D__WINESRC__ -DUSE _WS_PREFIX -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o socket.o socket.c socket.c:286: `IP_HDRINCL' undeclared here (not in a function) socket.c:286: initializer element is not constant socket.c:286: (near initialization for `ws_ip_map[6][1]') socket.c:286: initializer element is not constant socket.c:286: (near initialization for `ws_ip_map[6]') socket.c:287: initializer element is not constant socket.c:287: (near initialization for `ws_ip_map[7]') socket.c:288: initializer element is not constant socket.c:288: (near initialization for `ws_ip_map[8]') socket.c:289: initializer element is not constant socket.c:289: (near initialization for `ws_ip_map[9]') make[1]: *** [socket.o] Error 1 4. miscemu fails to build main.c:34: warning: implicit declaration of function `exit' gcc -o wine main.o -L../libs/wine -lwine -L../libs/port -lwine_port main.o(.text+0x51): In function `main': /cygdrive/g/src/wine-dev/wine/miscemu/main.c:32: undefined reference to `_wine_i nit' collect2: ld returned 1 exit status 5. There is no get/set_thread_context support. This patch by David Fraser stubs it. Index: context_i386.c =================================================================== RCS file: /home/wine/wine/server/context_i386.c,v retrieving revision 1.28 diff -u -r1.28 context_i386.c --- context_i386.c 22 Mar 2003 21:00:09 -0000 1.28 +++ context_i386.c 30 Apr 2003 16:39:35 -0000 @@ -78,7 +78,26 @@ #define PTRACE_SETDBREGS PT_SETDBREGS #endif -#ifdef linux +#if defined(__CYGWIN__) + +/* retrieve a thread context */ +static void get_thread_context( struct thread *thread, unsigned int +flags, CONTEXT *context ) +{ + /* FIXME: implement this */ + file_set_error(); +} + + +/* set a thread context */ +static void set_thread_context( struct thread *thread, unsigned int +flags, const CONTEXT *context ) +{ + /* FIXME: implement this */ + file_set_error(); +} + +#elif defined(linux) #ifdef HAVE_SYS_USER_H # include <sys/user.h> #endif

April 30, 2003

Re: iphlpapi.dll implementation

by Dimitrie O. Paun

On Wed, 30 Apr 2003, Juan Lang wrote: > Email me if interested. No, it's not vaporware, it's > just not as well tested as I'd like. Just send it over to wine-devel for comments, or wine-patches for inclusion into the tree. -- Dimi.

April 30, 2003

dxdiag gui regression

by Robert Reif

I am having problems with the gui in dxdiag.exe with the latest cvs. It appears to be coming up in the spanish language and the tab labels are all set to the first one. It worked ok with a cvs from a few days ago. Here are the errors: wine dxdiag.exe err:wave:OSS_WaveOutInit /dev/mixer1: not found! err:wave:OSS_WaveInInit /dev/mixer1: not found! fixme:ole:CoCreateInstance no classfactory created for CLSID {4590f811-1d3a-11d0-891f-00aa004b2e24}, hres is 0x80040154 err:module:BUILTIN32_LoadLibraryExA loaded .so but dll user.exe still not found - 16-bit dll or version conflict. err:module:BUILTIN32_LoadLibraryExA loaded .so but dll user.exe still not found - 16-bit dll or version conflict. err:ver:VerQueryValueW called on NE resource! fixme:global:GlobalMemoryStatusEx we should emulate the 4GB bug here, as per MSDN fixme:dsound:IKsPropertySetImpl_Get unsupported property: {f2957840-260c-11d1-a4d8-00c04fc28aca} fixme:system:EnumDisplayDevicesW ((nil),0,0x40711968,0x00000000), stub! fixme:system:EnumDisplayDevicesW (0x4071196c,0,0x4071120c,0x00000000), stub! fixme:dsound:IKsPropertySetImpl_Get unsupported property: {1aeaa606-35f0-11d1-b161-00c04fc28aca} This is a unicode program and it has a lot of problems related to that. Did it just happen to work before and some of the recent changes changed that behavior? The strange thing is that it worked properly when I tried to trace it to see what was happening. Any ideas before I start digging into this deeper? Thanks, Bob.

April 30, 2003

Re: Avoid non-portable signal(SIGCHLD, SIG_IGN)

by Joerg Wunsch

As Gerald Pfeifer wrote: > assertion "libc_sigaction" failed: file "../../scheduler/pthread.c", > line 661 > #3 0x5c16c404 in sigaction (signum=12, act=0xbfbfdce0, oldact=0xbfbfdcc8) at ../../scheduler/pthread.c:661 Signal #12 is SIGSYS (Illegal system call). That should not be related to the SIGCHLD manipulations. > #4 0x5c074f09 in getcwd () from /usr/lib/libc.so.4 Is getcwd() supposed to cause a SIGSYS at all? OTOH, that failing dlsym() syscall could be related to all this... I don't know why that complicated dlsym() is used, but maybe since sigaction() is now invoked directly before, the run-time loader has already loaded it from libc.so before. Maybe Alexandre can shed some light on how that's supposed to work. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)

April 30, 2003

Re: WINE flag

by Uwe Bonnes

>>>>> "KK" == KK singh <kk_singh(a)yahoo.com> writes: KK> hi, I have a win32 application that plays some hashing tricks with KK> HWND while running on win98 and uses the fact that on win98 HWND is KK> always 16bit. KK> This application is crashing on wine configured as win98 because KK> HWND is something bigger than 16bit on wine. KK> Now Can I Check from inside my application code, whether the KK> application is running on linux or win98 If yes then I might be able KK> to avoid those hashing tricks and solve the crash First question: - Can we change Wine behaviour with regard to the HWND handling? That would be best in m.h.O. - If not, check for the wine specific DLL entries e.g. in ntdll Hope this helps -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 30, 2003

Re: Avoid non-portable signal(SIGCHLD, SIG_IGN)

by Gerald Pfeifer

On Fri, 25 Apr 2003, Joerg Wunsch wrote: > I didn't test that yet, but i think that should work. If SA_NOCLDWAIT > is set (in a call for SIGCHLD), sa_handler ought to be ignored anyway. I'm note sure whether that's related (in it's, unfortunately, beyond my knowledge of threads and/or Wine to debug this), but... With current CVS sources of Wine, every single Windows program I try fails with the following error: assertion "libc_sigaction" failed: file "../../scheduler/pthread.c", line 661 which stems from the following snippet of code: int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact) { if (!libc_sigaction) { libc_sigaction = dlsym( RTLD_NEXT, "sigaction" ); assert( libc_sigaction ); } return libc_sigaction(signum, act, oldact); } The backtrace looks as follows: (gdb) bt #0 0x5c06cbac in kill () from /usr/lib/libc.so.4 #1 0x5c0ae152 in abort () from /usr/lib/libc.so.4 #2 0x5c08a14f in __assert () from /usr/lib/libc.so.4 #3 0x5c16c404 in sigaction (signum=12, act=0xbfbfdce0, oldact=0xbfbfdcc8) at ../../scheduler/pthread.c:661 #4 0x5c074f09 in getcwd () from /usr/lib/libc.so.4 #5 0x5c167400 in CLIENT_InitServer () at ../../scheduler/client.c:618 #6 0x5c1685ab in process_init (argv=0xbfbff2e4) at ../../scheduler/process.c:414 #7 0x5c1689e1 in __wine_process_init (argc=2, argv=0xbfbff2e4) at ../../scheduler/process.c:585 #8 0x5c02130b in wine_init (argc=2, argv=0xbfbff2e4, error=0xbfbfee90 "", error_size=1024) at loader.c:429 #9 0x3c000569 in main (argc=2, argv=0xbfbff2e4) at main.c:32 #10 0x3c0004ae in _start () Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

April 30, 2003

Re: WINE flag

by Mike Hearn

Why can't you just avoid the hashing tricks entirely? That sounds like it might break on W2K/XP as well. On Wed, 2003-04-30 at 10:06, KK singh wrote: > hi, > > I have a win32 application that plays some hashing > tricks with HWND while running on win98 and uses the > fact that on win98 HWND is always 16bit. > > This application is crashing on wine configured as > win98 because HWND is something bigger than 16bit on > wine. > > Now Can I Check from inside my application code, > whether the application is running on linux or win98 > If yes then I might be able to avoid those hashing > tricks and solve the crash > > Regards > kks > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 30, 2003

WINE flag

by KK singh

hi, I have a win32 application that plays some hashing tricks with HWND while running on win98 and uses the fact that on win98 HWND is always 16bit. This application is crashing on wine configured as win98 because HWND is something bigger than 16bit on wine. Now Can I Check from inside my application code, whether the application is running on linux or win98 If yes then I might be able to avoid those hashing tricks and solve the crash Regards kks __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

April 30, 2003

iphlpapi.dll implementation

by Juan Lang

Folks, in case anyone's looking, I've implemented most of the Get* functions of ip helper API included in Windows NT4 or Windows 98. I'm not planning to implement functions added in Win2K or XP at this time. Email me if interested. No, it's not vaporware, it's just not as well tested as I'd like. I'm hoping to tackle reducing code duplication in this DLL, wsock32, and netapi, and also remove wsock32's dependency on the UNIX socket includes. This has all been discussed before here in this thread: http://www.winehq.com/hypermail/wine-devel/2001/09/0042.html For interface enumeration and address (IP and MAC) getting, I use ioctls. This should aid portability (I've tested the ioctls on Linux, FreeBSD, and Solaris). Stats I still read from /proc. All this stuff is in its own file to keep less-portable code together. Cheers, --Juan __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

April 30, 2003

Wine Regression

by Steven Tower

With the current cvs tree parts of the Agent news reader are broken. I don't know the exact date it last worked but it wasn't that long ago. When double clicking on a group that is empty, the dialog you would normally see that asks if youw ant to download x headers, or all available headers, etc displays, but only the border and title bar are drawn and then wine crashes. The bug does not occur in Crossover Office 2.0.0. Steven Here is the debug output. tower(a)towerpc Agent $ wine ./agent.exe Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TT" err:font:ReadFontDir Can't open directory "/usr/share/fonts/TT" err:wave:OSS_WaveOutInit /dev/mixer1: not found! err:wave:OSS_WaveInInit /dev/mixer1: not found! fixme:file:SetFileAttributesW (L"C:\\Program Files\\Agent\\"):2000 attribute(s) not implemented. fixme:ras:RasEnumConnectionsA (0x41923188,0x406b1ca8,0x41c925c8),stub! fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:ras:RasEnumConnectionsA (0x41922e48,0x406b24d0,0x406b2518),stub! fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:ras:RasEnumConnectionsA (0x41923188,0x406b1ca8,0x41c925c8),stub! fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:ras:RasEnumConnectionsA (0x419225d8,0x406b252c,0x406b2574),stub! fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program to use LAN connection/winsock instead! wine: Unhandled exception, starting debugger... Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: WineDbg starting on pid 8 Loaded debug information from ELF 'wine' ((nil)) Breakpoint 1 at 0x4000b330 (_end+0x4009c34) Loaded debug information from ELF '/usr/local/lib/libwine.so.1' (0x40025000) No debug information in ELF '/lib/libc.so.6' (0x4003e000) No debug information in ELF '/lib/libdl.so.2' (0x40169000) No debug information in ELF '/lib/libm.so.6' (0x4016c000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' (0x4018e000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' (0x4028d000) No debug information in ELF '/lib/libnss_compat.so.2' (0x4036e000) No debug information in ELF '/lib/libnsl.so.1' (0x40379000) Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' (0x406c3000) Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' (0x40785000) Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x408c8000) Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' (0x4094d000) Loaded debug information from ELF '/usr/local/lib/wine/version.dll.so' (0x4097c000) Loaded debug information from ELF '/usr/local/lib/wine/lz32.dll.so' (0x40996000) Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' (0x409ac000) Loaded debug information from ELF '/usr/local/lib/wine/rpcrt4.dll.so' (0x40a29000) Loaded debug information from ELF '/usr/local/lib/wine/winmm.dll.so' (0x40a74000) Loaded debug information from ELF '/usr/local/lib/wine/shell32.dll.so' (0x40ae2000) Loaded debug information from ELF '/usr/local/lib/wine/shlwapi.dll.so' (0x40b6d000) Loaded debug information from ELF '/usr/local/lib/wine/comctl32.dll.so' (0x40bc0000) Loaded debug information from ELF '/usr/local/lib/wine/comdlg32.dll.so' (0x40c73000) Loaded debug information from ELF '/usr/local/lib/wine/winspool.drv.so' (0x40cf2000) No debug information in ELF '/usr/lib/libfreetype.so.6' (0x40d28000) No debug information in ELF '/usr/lib/libz.so.1' (0x40d7d000) Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40d8b000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40014000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40dfa000) No debug information in ELF '/usr/X11R6/lib/libXxf86dga.so.1' (0x40e11000) No debug information in ELF '/usr/X11R6/lib/libXxf86vm.so.1' (0x40e17000) No debug information in ELF '/usr/X11R6/lib/libXv.so.1' (0x40e1d000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40e22000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40e32000) No debug information in ELF '/usr/lib/libGL.so.1' (0x40f11000) No debug information in ELF '/usr/lib/libGLcore.so.1' (0x40f78000) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x414c5000) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x414cf000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x4001d000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x41530000) Loaded debug information from ELF '/usr/local/lib/wine/wineoss.drv.so' (0x4154d000) Loaded debug information from ELF '/usr/local/lib/wine/msacm.drv.so' (0x4158f000) Loaded debug information from ELF '/usr/local/lib/wine/msacm32.dll.so' (0x415a7000) Loaded debug information from ELF '/usr/local/lib/wine/midimap.drv.so' (0x416e0000) No debug information in ELF '/lib/libnss_files.so.2' (0x416f5000) Loaded debug information from ELF '/usr/local/lib/wine/rasapi32.dll.so' (0x41840000) Loaded debug information from ELF '/usr/local/lib/wine/wsock32.dll.so' (0x4185c000) Loaded debug information from ELF '/usr/local/lib/wine/ws2_32.dll.so' (0x41879000) Loaded debug information from ELF '/usr/local/lib/wine/mapi32.dll.so' (0x41e90000) No debug information in ELF '/lib/libnss_dns.so.2' (0x40021000) No debug information in ELF '/lib/libresolv.so.2' (0x41b2c000) No debug information in 32bit DLL 'C:\Program Files\Agent\agent.exe' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x401c0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40960000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x408e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x407b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\LZ32.DLL' (0x409a0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VERSION.DLL' (0x40980000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40a40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x409d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40a80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40b80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40bd0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x40b00000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40d00000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMDLG32.DLL' (0x40c80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40da0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x41560000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x415b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x415a0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x416f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RASAPI32.DLL' (0x41850000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WS2_32.DLL' (0x41880000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WSOCK32.DLL' (0x41860000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MAPI32.DLL' (0x41ea0000) Unhandled exception: page fault on read access to 0x04092336 in 32-bit code (0x005995ce). In 32-bit mode. 0x005995ce (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x4820 in C:\Program Files\Agent\agent.exe): movl 0x7a(%esi),%esi -- BACKTRACE -- Wine-dbg>back Backtrace: =>0 0x005995ce (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x4820 in C:\Program Files\Agent\agent.exe) (ebp=406b235c) 1 0x004dc759 (agent.exe.(a)DisableWnds$qp6HWND__p9TEnumInfo+0xd65 in C:\Program Files\Agent\agent.exe) (ebp=406b2384) 2 0x004303cf (agent.exe.(a)TPrinterAbortProc$qp5HDC__i+0x1c7ef in C:\Program Files\Agent\agent.exe) (ebp=406b23f0) 3 0x004dad54 (agent.exe.(a)PropdlgKbdProc$qiuil+0x2625c in C:\Program Files\Agent\agent.exe) (ebp=406b2400) 4 0x0040f365 (agent.exe.__GetExceptDLLinfo+0xe2f7 in C:\Program Files\Agent\agent.exe) (ebp=406b241c) 5 0x004db4ae (agent.exe.(a)PropdlgKbdProc$qiuil+0x269b6 in C:\Program Files\Agent\agent.exe) (ebp=406b2470) 6 0x004dbb81 (agent.exe.(a)DisableWnds$qp6HWND__p9TEnumInfo+0x18d in C:\Program Files\Agent\agent.exe) (ebp=406b24bc) 7 0x004a6150 (agent.exe.(a)ENUMERATEACTIVEWNDS$QP6HWND__P9TENUMINFO+0x72580 in C:\Program Files\Agent\agent.exe) (ebp=406b24d8) 8 0x0041f465 (agent.exe.(a)TPrinterAbortProc$qp5HDC__i+0xb885 in C:\Program Files\Agent\agent.exe) (ebp=406b2510) 9 0x00420bf7 (agent.exe.(a)TPrinterAbortProc$qp5HDC__i+0xd017 in C:\Program Files\Agent\agent.exe) (ebp=406b2668) 10 0x0041fa0a (agent.exe.(a)TPrinterAbortProc$qp5HDC__i+0xbe2a in C:\Program Files\Agent\agent.exe) (ebp=406b2680) 11 0x00437fbb (agent.exe.(a)ENUMERATEACTIVEWNDS$QP6HWND__P9TENUMINFO+0x43eb in C:\Program Files\Agent\agent.exe) (ebp=406b26a4) 12 0x00436836 (agent.exe.(a)ENUMERATEACTIVEWNDS$QP6HWND__P9TENUMINFO+0x2c66 in C:\Program Files\Agent\agent.exe) (ebp=406b26c0) 13 0x0058e830 (agent.exe.(a)WinTimerStatics@Func$qp6HWND__uiuiul+0xe5c8 in C:\Program Files\Agent\agent.exe) (ebp=406b26dc) 14 0x00531d64 (agent.exe.(a)MyDdeCallback$quiuip7HCONV__p5HSZ__t4p10HDDEDATA__ulul+0x17d5c in C:\Program Files\Agent\agent.exe) (ebp=406b272c) 15 0x00597d21 (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x2f73 in C:\Program Files\Agent\agent.exe) (ebp=406b2778) 16 0x00598499 (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x36eb in C:\Program Files\Agent\agent.exe) (ebp=406b27d0) 17 0x005985a0 (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x37f2 in C:\Program Files\Agent\agent.exe) (ebp=406b2804) 18 0x0059865f (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x38b1 in C:\Program Files\Agent\agent.exe) (ebp=406b284c) 19 0x005985c8 (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x381a in C:\Program Files\Agent\agent.exe) (ebp=406b2864) 20 0x4082a627 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406b2888) 21 0x4082a6a3 (WINPROC_CallWndProc+0x73(proc=0x418253e8, hwnd=0x1003a, msg=0x203, wParam=0x1, lParam=0x10c00d7) [winproc.c:184] in user32.dll.so) (ebp=406b28c4) 22 0x40830d2f (CallWindowProcA+0x14f(func=0x41520a88, hwnd=0x1003a, msg=0x203, wParam=0x1, lParam=0x10c00d7) [winproc.c:2812] in user32.dll.so) (ebp=406b28f8) 23 0x4080c09b (DispatchMessageA+0xbb(msg=0x406b2964) [message.c:792] in user32.dll.so) (ebp=406b292c) 24 0x004db200 (agent.exe.(a)PropdlgKbdProc$qiuil+0x26708 in C:\Program Files\Agent\agent.exe) (ebp=406b2980) 25 0x004db4c3 (agent.exe.(a)PropdlgKbdProc$qiuil+0x269cb in C:\Program Files\Agent\agent.exe) (ebp=406b29d0) 26 0x004dadbb (agent.exe.(a)PropdlgKbdProc$qiuil+0x262c3 in C:\Program Files\Agent\agent.exe) (ebp=406b2a38) 27 0x0040fd3b (agent.exe.__GetExceptDLLinfo+0xeccd in C:\Program Files\Agent\agent.exe) (ebp=406b2dfc) 28 0x005a54d4 (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x10726 in C:\Program Files\Agent\agent.exe) (ebp=406b2e40) 29 0x005b40b5 (agent.exe.(a)InitWndProc$qp6HWND__uiuil+0x1f307 in C:\Program Files\Agent\agent.exe) (ebp=406b2e70)

April 30, 2003

Re: $(RC) portability

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Now that we have rc, wrc, and windres command line compatible, > I thought we could abstract things a bit so we could use other > resource compilers to process resource files. > > ChangeLog > Make it easy to use something other than wrc to compile resources. You can't remove the -o options, wrc cannot guess where the output file should go. -- Alexandre Julliard julliard(a)winehq.com

April 30, 2003

Re: PATCH: aliasing problems in ole32

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Changelog: > Fixed some warnings from newer gccs in regards to > pointer aliasing problems by using unions instead of > using (void**)&ptr constructs. All these unions are ugly IMO, it would be better to use an intermediate pointer instead, something like: void *ptr; ISomething *iface; IUnknown_QueryInterface(...,&ptr); iface = ptr; -- Alexandre Julliard julliard(a)winehq.com

April 29, 2003

Re: Fix oleaut32/olepicture

by Alexandre Julliard

Maxime Bellengé <maxime.bellenge(a)laposte.net> writes: > + bits = HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY, > + (jd.output_height+1)*(jd.output_width+jd.output_width%sizeof(DWORD))*jd.output_components); > samprow=HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,jd.output_width*jd.output_components); > + > + oldbits = bits; > + oldsamprow = samprow; > + padding = jd.output_width%sizeof(DWORD); The computations of the total width and of the padding are wrong, "width % sizeof(DWORD)" doesn't yield the result you want. -- Alexandre Julliard julliard(a)winehq.com

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Steven Edwards

Dimitrie O. Paun wrote: >There's some confusion. I thought you guys are working on doing an >Explorer-the-file-browser clone, not an IE clone. Yes, we already >have khtml and gecko, it would be crazy/silly to start yet another >one. > We are doing work on a explorer clone. I thought you had jumped to discussing the WebBrowser interface. The guy that wrote our bootloader and task-manager is supposed to be working on our explorer clone. At some point the explorer clone is going to have to interface with a web-browser. In any case I want to see this OLE to GTK or bonobo integration support you are talking about. The more these applications can get along the better chance we have of moving people off of Windows on to Linux, ReactOS or anything else that comes along and does GNU. There are a 2 things I think WINE needs now before we will see a good WIDE. 1. Implement Xdnd to OLE support. Corel did some work on this but it never made it in to the main winehq tree. This would really help anyone porting a Windows application to Linux seeing as how everything on Windows uses OLE and KDE and GNOME both support Xdnd now. I thinking if it is done right then you could even have it both ways and build it as a dll under Mingw and use it with either kde-cygwin/gnome-cygwin or libw11 ported applications. (If anyone has a snapshot of the corel-wine CVS I would like to look at this) 2. Cleanup Ole*. Everything depends on OLE and it either doesn’t implement everything or calls way to many non-standard APIs. Now that codeweavers has started to fix the need for M$ dlls in crossover maybe it will get fixed. We cannot make much use of most of the WINE code until we can build working ole32 support. There are way to many win16isms, and 9xisms.

April 29, 2003

Re: Patch to get Borland's bcc 5.5 (free beer compiler) to work

by Ulrich Weigand

Troy Rollo wrote: > And yes, it should be configurable, or perhaps Wine should be capable of > detecting which apps can deal with a 3GB user address space (as apparently > executables can be marked to declare this), but as long as it's not > configurable, and Wine's not capable of detecting this, it seems to me that > the 2GB limit applicable to the desktop operating systems is the correct one. Well, this depends on what you mean by "desktop operating systems" ;-) The Win95 based OSes all have a 3GB user space, and in fact *require* it if you want to use native DLLs, because the system DLLs need to be located at > 2GB ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

April 29, 2003

Re: Excessive Swap with MSVC++ and Wine

by Phil Thompson

On Tuesday 29 April 2003 5:22 am, Alexandre Julliard wrote: > hatky <hatkyinc(a)yahoo.com> writes: > > sounds like a memory leak in the code sould be > > addressed to wine-devel(a)winehq.com and you should > > probably open a bug on this ..... > > > > wine-devel, can someone comment/help on that? (I think > > there wore more details on the original message) > > This may be fixed in current CVS, give it a try. The current CVS gives me other problems... Running Python gives... Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x1e04e00f). In 32-bit mode. 0x1e04e00f (PYTHON22.DLL.Py_VaBuildValue+0x46f in C:\WINDOWS\SYSTEM\PYTHON22.DLL): repne scasb %es:(%edi) Running cl gives... Command line error D2029 : cannot execute 'D:\Program Files\Microsoft Visual Studio\vc98\Bin\c1xx.dll' out of environment memory ...which looks like a configuration error on my part but I haven't found anything yet that tells me how to fix it. Both of these work fine under Crossover Office 2.0. Phil

April 29, 2003

Re: slovene keyboard without dead keys

by Shachar Shemesh

Dmitry Timoshkov wrote: >"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > > > >>>>Also important is an ability by the system to change keyboards. One such >>>>requirement is for BiDi text editing, where the algorithm includes, >>>>among other things, instances where it is necessary to change the >>>>current keyboard layout. >>>> >>>> >>>> >>>> >>>I'm not sure XFree86 supports this feature. Without support from X we couldn't >>>implement keyboard layout changes on application request. >>> >>> >>> >>Can't you set the current group? How are you planning on implementing >>"INPUTLANGCHANGEREQUEST" otherwise? >> >> > >Just reflect the change on the X notification event and inform the app about it. > That's just INPUTLANGCHANGE, not the REQUEST. Let's hope it doesn't matter. I don't think many applications use this message to actually forbit a keyboard switch. >>We use it today for comparing the keyboards. >> >> > >If you mean X11DRV_KEYBOARD_DetectLayout, then we don't. > > Ok. I'l shut up until I collect further info. >I'm afraid we can't change anything in that path. > > Again. I'll do my homework and call in again. >There is a patch in CX Office which supports UTF-8 encoded keyboard input >(in the case of UTF-8 locale of X Input Method) and makes it possible to avoid >conversion to current locale code page and back to unicode. If Alexandre considers >it clean enough he will certainly merge it into WineHQ tree. > > An improvement, and no doubt. >I'm not an expert on right-to-left layouts and can't comment on this. If you >(or somebody else) feel to be a motivated enough to learn how it supposed to >work under real Windows and implement this behaviour in Wine taking into account >X peculiarities that would be great. > > We'll see how this problem resolves in X. It may just be that the X keyboard is going to have the keys pre-reveresed, and we can get away with simply defining a new keyboard and having is done with. Shachar

April 29, 2003

Re: Patch to get Borland's bcc 5.5 (free beer compiler) to work

by Dimitrie O. Paun

On Tue, 29 Apr 2003, Troy Rollo wrote: > On Mon, 28 Apr 2003 14:23, Dimitrie O. Paun wrote: > > Few questions: > > * Do you build on Windows? > > Until now, I have developed on Windows, but I will be continuing to target > Windows from Linux using Wine to support the build environment, and possibly > for testing of the application itself, together with plex86 or Bochs VMs as > needed for testing under the target OS. Sorry, I misunderstood you. I thought you were building *Wine* with bcc, and I did not understand how you managed to get a running binary. :) -- Dimi.

April 29, 2003

Dupes again, was: Re: Winword, StorageImpl_Commit

by Uwe Bonnes

Hallo, I am seeing duplicated messages like: Bye ------- start of forwarded message ------- Return-Path: <wine-devel-admin(a)winehq.com> Received: from mailserver2.hrz.tu-darmstadt.de (mailserver2.hrz.tu-darmstadt.de [130.83.22.129]) by elektron.ikp.physik.tu-darmstadt.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id h3TGAqj31573 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Tue, 29 Apr 2003 18:10:52 +0200 Received: from localhost.localdomain ([198.144.4.3]) by mailserver2.hrz.tu-darmstadt.de (8.12.9/8.12.8) with ESMTP id h3TGA6l3015786 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Tue, 29 Apr 2003 18:10:06 +0200 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h3TFv1Kp018851; Tue, 29 Apr 2003 10:57:01 -0500 Received: from ouse.qinetiq.com (ouse.qinetiq.com [192.102.214.3]) by localhost.localdomain (8.12.8/8.12.8) with SMTP id h3TFu2Kp018786 for <wine-devel(a)winehq.com>; Tue, 29 Apr 2003 10:56:02 -0500 Received: (qmail 10428 invoked from network); 29 Apr 2003 16:56:22 +0100 Received: from unknown (HELO dart.qinetiq.com) (10.0.5.21) by ouse.qinetiq.com with SMTP; 29 Apr 2003 16:56:22 +0100 Received: from allen.qinetiq.com (Not Verified[10.0.20.10]) by dart.qinetiq.com) id <B00054c995>; Tue, 29 Apr 2003 16:56:02 +0100 Received: from unknown (HELO signal.dra.hmg.gb) (10.184.84.139) by allen.qinetiq.com with SMTP; 29 Apr 2003 16:56:02 +0100 Received: from pershore.dra.hmg.gb (pershore.dra.hmg.gb [192.35.94.42]) by signal.dra.hmg.gb (8.9.3/) with ESMTP id RAA01224; Tue, 29 Apr 2003 17:02:17 GMT Received: from littlegreen.dra.hmg.gb by pershore.dra.hmg.gb (8.8.8+Sun/SMI-SVR4) id QAA27906; Tue, 29 Apr 2003 16:57:11 +0100 (BST) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 29, 2003

Re: Winword, StorageImpl_Commit, Crossover and Wine

by Mike McCormack

Hi Mike, Yeah, I think Windows implements transacted mode by doing something like this: open or commit: mv x x.old cp x.old x close, no commit: mv x.old x I haven't tried to implement that yet, but it shouldn't be too difficult. Mike Mike Hearn wrote: > I might as well point out that StorageImpl_Commit is a NOP for direct > mode storage objects. Wine doesn't implement transacted mode, which > seems to be a basic optimization, so we can ignore this stub for now, I > don't think it's important.

April 29, 2003

Re: Winword, StorageImpl_Commit, Crossover and Wine

by Mike Hearn

I might as well point out that StorageImpl_Commit is a NOP for direct mode storage objects. Wine doesn't implement transacted mode, which seems to be a basic optimization, so we can ignore this stub for now, I don't think it's important. On Tue, 2003-04-29 at 04:22, Mike McCormack wrote: > Hi Uwe, > > I have implemented WriteFmtUserTypeStg and ReadFmtUserTypeStg in > Crossover's Wine... I'm trying to gradually ween us off native DLLs. > Alexandre should start merging shortly... > > Mike > > Uwe Bonnes wrote: > > Hallo, > > > > running MS Word 2000 with builtin dlls doesn't allow to write files, because > > of at least StorageImpl_Commit and WriteFmtUserTypeStg still stubs? Does > > Crosover Office still require the native OLE dlls or has it some > > implementation? > > > > Bye > > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

RE: Wine, WIDE & Unix (was: Support for pkgconfig)

by Mike Hearn

> Ah OK. Minor problem. :-( > > Why can't they make Qt/Win32 GPL:ed as well with the exception of the > drawing primitives that have to become LGPL:ed. > > They released Qt/X11 under the GPL, since the GPL according to their > interpretation will protect them from "free commercial use". > > Why not release Qt/Win32 under the GPL as well? Not sure, might be worth asking, but I expect it's because they believe they would lose a lot of customers writing internal corporate software for Win32 - if the software is for internal use only, you could just make it GPLd and not pay TT anything. Restricting the free version to a display protocol not well supported on Win32 allows them to make more money. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

Re: A little Xlib adventure

by Dimitrie O. Paun

On April 29, 2003 09:16 am, Mike Hearn wrote: > Are you sure? It looks like that in Evo if I just view it in the normal > view, but if I maximize the window, it becomes unwrapped (ie evo does > the word wrapping on view rather than on send) My bad -- KMail is playing tricks on me. I've recently upgraded to RH9, and KMail change slightly some of its behaviors, and I'm yet to get used to it. :) -- Dimi.

April 29, 2003

Re: A little Xlib adventure

by Mike Hearn

Are you sure? It looks like that in Evo if I just view it in the normal view, but if I maximize the window, it becomes unwrapped (ie evo does the word wrapping on view rather than on send) I attached it as a plain text doc as well, which has always worked fine before. Or was there something in that cup of tea I just drank? On Tue, 2003-04-29 at 14:14, Dimitrie O. Paun wrote: > On April 29, 2003 08:59 am, Mike Hearn wrote: > > + /* set the pid. together, these properties are needed so the window > > manager can kill us if we freeze */ > > Wrapped patch alert! :) -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

Re: A little Xlib adventure

by Dimitrie O. Paun

On April 29, 2003 08:59 am, Mike Hearn wrote: > + /* set the pid. together, these properties are needed so the window > manager can kill us if we freeze */ Wrapped patch alert! :) -- Dimi.

April 29, 2003

RE: Wine, WIDE & Unix (was: Support for pkgconfig)

by Patrik Stridvall

> > Well, the point is that i'm pretty sure that both Trolltech (and the > > KDE project) would very much like to Qt themed Wine in order to > > compete in the desktop market so I'm sure it would be possible to > > get some sort of "deal" somehow. > > > > Perhaps just releasing the Qt drawing primatives implementation > > under the LGPL would be a solution that would be acceptable > > to all parties. I can't see Trolltech losing very much from > doing that. > > > > No work at all (except convincing Trolltech to do that). > > Hehehe, yeah, that's the hard part, especially as the > difference between > Qt/X11 and Qt/Win32 is mostly the drawing primitives/window creation > code. Ah OK. Minor problem. :-( Why can't they make Qt/Win32 GPL:ed as well with the exception of the drawing primitives that have to become LGPL:ed. They released Qt/X11 under the GPL, since the GPL according to their interpretation will protect them from "free commercial use". Why not release Qt/Win32 under the GPL as well? > Bah. This is stupid. Before we start adding theming to Wine, I think > somebody should at least make an attempt at a unified theming > standard. > Otherwise we're just going to end up with huge amounts of bloat and > duplication in Wine already. A standard system would be much > better. No, > I don't have time for that :( Agreed. This is a post 1.0 issue IMHO.

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Mike Hearn

> Is this in the context of the IWebBrowser interface? That is, how we go > about providing an implementation for that interface? Well if so, I think > it would be nice if we could have both khtml and gecko as backends for > it. In fact, I think it'd be easier to have mozilla as a backend as they > already implement the IWebBrowser interface. But that's just me talking, > I should give this a try -- but after the 0.9 release! :) A gecko backend would be handy for apps that use MSHTML just as a convenience for browsing the web yeah, for apps that actually use the various quirks of IE and such we'd need to be able to control our own fork. Not sure how we'd detect which one to use. > Yes, I agree on this one -- I've said multiple times that implementing the > theming API is the way forward. In fact, separating the drawing code will > cleanup the controls I think, as we'll have a better separation between the > presentation and logic layers. Moreover, it will allow us to have a cleaner > solution for the win311, win95, win98, winxp looks. > > But again, this looks like a post 1.0 project. We need to fix a lot of > things in the controls for the 1.0 release anyway. I think it's more > important to the a working set of controls, rather than a themable set > of broken controls :). Agreed. Theming and WebBrowser implementation is cool, but there's still way too much work to do just to let people install things reliably etc first. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

RE: Wine, WIDE & Unix (was: Support for pkgconfig)

by Mike Hearn

> Well, the point is that i'm pretty sure that both Trolltech (and the > KDE project) would very much like to Qt themed Wine in order to > compete in the desktop market so I'm sure it would be possible to > get some sort of "deal" somehow. > > Perhaps just releasing the Qt drawing primatives implementation > under the LGPL would be a solution that would be acceptable > to all parties. I can't see Trolltech losing very much from doing that. > > No work at all (except convincing Trolltech to do that). Hehehe, yeah, that's the hard part, especially as the difference between Qt/X11 and Qt/Win32 is mostly the drawing primitives/window creation code. Bah. This is stupid. Before we start adding theming to Wine, I think somebody should at least make an attempt at a unified theming standard. Otherwise we're just going to end up with huge amounts of bloat and duplication in Wine already. A standard system would be much better. No, I don't have time for that :( -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 29, 2003 02:46 am, Gregory M. Turner wrote: > 3) (the original thread I believe?) what are the prospects of using wine as > a window manager? Man, am I misunderstood or what? :) No, I've never suggested we use wine as a window manager. In fact, I explicitly said I don't what to needlessly duplicate code. Using the gnome panel & window manager, and what have you is good enough for me. > As for the browser issue, it's been discussed on the list ad infinitum and > the consensus was that we should lean towards konq integration. Is this in the context of the IWebBrowser interface? That is, how we go about providing an implementation for that interface? Well if so, I think it would be nice if we could have both khtml and gecko as backends for it. In fact, I think it'd be easier to have mozilla as a backend as they already implement the IWebBrowser interface. But that's just me talking, I should give this a try -- but after the 0.9 release! :) > If you ask me, we should look to implement the (undocumented?) XP skinning > API's -- with a deliberite sprinkling of internal extensions to clean up > some of the messy parts if they are too slow for "built in" wine skins. Yes, I agree on this one -- I've said multiple times that implementing the theming API is the way forward. In fact, separating the drawing code will cleanup the controls I think, as we'll have a better separation between the presentation and logic layers. Moreover, it will allow us to have a cleaner solution for the win311, win95, win98, winxp looks. But again, this looks like a post 1.0 project. We need to fix a lot of things in the controls for the 1.0 release anyway. I think it's more important to the a working set of controls, rather than a themable set of broken controls :). -- Dimi.

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 29, 2003 07:50 am, Patrik Stridvall wrote: > Well, the point is that i'm pretty sure that both Trolltech (and the > KDE project) would very much like to Qt themed Wine in order to > compete in the desktop market so I'm sure it would be possible to > get some sort of "deal" somehow. That'd be great -- do you mind getting in touch with them on this issue? They do have an incentive go give us such a permission, it will be an interesting experiment. -- Dimi.

April 29, 2003

RE: Wine, WIDE & Unix (was: Support for pkgconfig)

by Patrik Stridvall

> > Well, I can't see why Trolltech (the owners of Qt) would object. > > > > Presumably the main reason that you would want a Qt skin for > > Windows application running under Wine is that you run several > > other Unix applications using Qt... > > > > So I can't see why they wouldn't give us special permission > > if we for some reason would need it... > > I'm not sure it's quite that simple though. IIRC Qt/KDE themes use the > Qt drawing primitives (like gtk skins do with gdk). Unfortunately, > Qt/Win32 is not free software, so we'd have to stub out Qt with Win32 > equivalents in order to allow Qt skins to draw correctly. As GDK is > already ported to Win32 though, that'd be easier to use. > > I'm sure if somebody was motivated enough they could do so, and we may > need to stub out Qt anyway for KHTML at some point. But it's a lot of > work. Well, the point is that i'm pretty sure that both Trolltech (and the KDE project) would very much like to Qt themed Wine in order to compete in the desktop market so I'm sure it would be possible to get some sort of "deal" somehow. Perhaps just releasing the Qt drawing primatives implementation under the LGPL would be a solution that would be acceptable to all parties. I can't see Trolltech losing very much from doing that. No work at all (except convincing Trolltech to do that).

April 29, 2003

bugs.winehq.com

by hatky

Hi all, I am not sure if this is the place to disscuse it but I have mailed bugs(a)winehq.com and web-admin(a)winehq.org and have yet to get a replay So my question is: "Am I the only one who can not retrive his password?" I mean it's saying mail sent and stuff but I am not getting it. I tried it a few times doing the last few days and I do not get any mail. I think it can be becouse of some configuration on the new server or it can be my sf.net filltering (it claimed to have one when I first registered a long time ago but with no details).... Hatky. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

April 29, 2003

Re: Fix loading icon from resource

by Maxime Bellengé

yes but you have to use my olepicture patch that I sent to wine-patches. It is not yet in cvs ( Alexandre, is there a problem with it ?) . a+ Max On Tue, 2003-04-29 at 11:52, BiGgUn wrote: > Hi > > Did you successfully load the splashscreen of emule ? I got a strange > biased image instead of a clean one :-\ > > Stephan -- Maxime Bellengé <maxime.bellenge(a)laposte.net>

April 29, 2003

RE: Wine, WIDE & Unix (was: Support for pkgconfig)

by Mike Hearn

> Well, I can't see why Trolltech (the owners of Qt) would object. > > Presumably the main reason that you would want a Qt skin for > Windows application running under Wine is that you run several > other Unix applications using Qt... > > So I can't see why they wouldn't give us special permission > if we for some reason would need it... I'm not sure it's quite that simple though. IIRC Qt/KDE themes use the Qt drawing primitives (like gtk skins do with gdk). Unfortunately, Qt/Win32 is not free software, so we'd have to stub out Qt with Win32 equivalents in order to allow Qt skins to draw correctly. As GDK is already ported to Win32 though, that'd be easier to use. I'm sure if somebody was motivated enough they could do so, and we may need to stub out Qt anyway for KHTML at some point. But it's a lot of work. > The alternative a GTK skinned only Wine would not benefit them > at all, quite the opposite. > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

Re: Fix loading icon from resource

by BiGgUn

Hi Did you successfully load the splashscreen of emule ? I got a strange biased image instead of a clean one :-\ Stephan

April 29, 2003

RE: Wine, WIDE & Unix (was: Support for pkgconfig)

by Patrik Stridvall

> > Once you have a skinning API, you just implement a 'gnome > compat' and 'kde > > compat' skin (or even just an automagical one that does > both) the thing would > > "just work", right? Why, it shouldn't take more than a > couple of hours ;) > > (WARNING: that last part was a joke, if you set your watch > by this you very > > well may miss work for several years). > > I don't think we could do KDE skins, as (surprise) they depend on Qt > which is GPLd. Well, I can't see why Trolltech (the owners of Qt) would object. Presumably the main reason that you would want a Qt skin for Windows application running under Wine is that you run several other Unix applications using Qt... So I can't see why they wouldn't give us special permission if we for some reason would need it... The alternative a GTK skinned only Wine would not benefit them at all, quite the opposite.

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Mike Hearn

> If you ask me, we should look to implement the (undocumented?) XP skinning > API's -- with a deliberite sprinkling of internal extensions to clean up some > of the messy parts if they are too slow for "built in" wine skins. I think they are fairly well documented from looking at them a few months ago. > It's probably not /that/ difficult to figure out, especially if one is armed > with something like WindowBlinds to hack on. After all, they figured it out > at StarDock, (although they might have the "top secret" special sauce from MS > for all I know...) and some of it is probably out there on the net. WindowBlinds uses extensive hooking from what I recall - it made Windows (98) rather unstable. XP theming is different, it's actually built into the common controls library. > Once you have a skinning API, you just implement a 'gnome compat' and 'kde > compat' skin (or even just an automagical one that does both) the thing would > "just work", right? Why, it shouldn't take more than a couple of hours ;) > (WARNING: that last part was a joke, if you set your watch by this you very > well may miss work for several years). I don't think we could do KDE skins, as (surprise) they depend on Qt which is GPLd. Most projects out there (mozilla, openoffice) use GTK theming engines. > Might be harder than some other approach to this problem, but IMO it would be > a waste to expend labor building "skins" into wine using some other > architecture which might be non-orthagonal to that used by MS operating > systems. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Gregory M. Turner

On Tuesday 29 April 2003 01:46 am, Gregory M. Turner wrote: > architecture which might be non-orthagonal to that used by MS operating hrmph, s/non-//r. I will shut up and try to do some real wine work soon, I promise ;) -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Gregory M. Turner

On Monday 28 April 2003 01:07 am, Dimitrie O. Paun wrote: > On April 27, 2003 05:32 pm, Francois Gouget wrote: > > So the situation will remain the same: we will haev KDE applications and > > WIDE applications and they will not be interoperable. I.e. it won't be > > possible to insert an Excel spreadsheet in a KWord document. > > No, it will be better: you will be able to have deep integration between > Win32 apps and Gnome apps, no small feat. > > > Does that include interoperability with OLE/COM/DCOM or just the look > > and feel integration? > > Well, the OLE/COM/DCOM bit is the interesting one, the look and feel > is simple and has other solutions, as we discussed. > > > I believe where we differ is on the method: > > * I think we should work on Wine to make that possible (though > > there may be some work to do in Gnome and KDE). a few issues are being conflated here perhaps: 1) what browser? 2) how can we get wine apps to have a consistient look-and-feel on gnome and kde (and other) desktops? 3) (the original thread I believe?) what are the prospects of using wine as a window manager? The third may be beyond my ability to answer, but 1) and 2) seem easy to me... As for the browser issue, it's been discussed on the list ad infinitum and the consensus was that we should lean towards konq integration. OTOH, if someone had a well-done, LGPL, working base of completely original code, or magical code to get mozilla or opera or lynx or what-have-you to do everything wine needs -- I would be surprised if it wouldn't find its way into wine (or at least into my tree at home !!! ;)) So he who codes first wins the debate, as usual ;) There is no reason, I think, that we theoretically couldn't accomidate different browsers via run-time configs -- some people really, really need/want their favorite browser -- the debate is therefore unwinnable, we need them all :P As for the look-and-feel thing, I have stronger opinions, so I will try to say less -- I imagine that I will fail ;) First, I should note that there do exist some efforts to do this already in wine, like "icon tray" support, cut-and-paste, etc... so it's not like there's no precedent for what you propose, Dimi... (except maybe the WM thing I guess). If you ask me, we should look to implement the (undocumented?) XP skinning API's -- with a deliberite sprinkling of internal extensions to clean up some of the messy parts if they are too slow for "built in" wine skins. It's probably not /that/ difficult to figure out, especially if one is armed with something like WindowBlinds to hack on. After all, they figured it out at StarDock, (although they might have the "top secret" special sauce from MS for all I know...) and some of it is probably out there on the net. Once you have a skinning API, you just implement a 'gnome compat' and 'kde compat' skin (or even just an automagical one that does both) the thing would "just work", right? Why, it shouldn't take more than a couple of hours ;) (WARNING: that last part was a joke, if you set your watch by this you very well may miss work for several years). Might be harder than some other approach to this problem, but IMO it would be a waste to expend labor building "skins" into wine using some other architecture which might be non-orthagonal to that used by MS operating systems. -- "Security is mostly superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure. Life is either a daring adventure, or nothing. To keep our faces toward change and behave like free spirits in the presence of fate is strength undefeatable." --Helen Keller gmt

April 29, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 28, 2003 12:29 pm, Steven Edwards wrote: > I think you are forgetting the one beast/API/toolkit to bind them all. > Mozilla. It is my hope that ReactOS will be able to use either khtml as > it is LGPL or use the Gecko. There's some confusion. I thought you guys are working on doing an Explorer-the-file-browser clone, not an IE clone. Yes, we already have khtml and gecko, it would be crazy/silly to start yet another one. -- Dimi.

April 29, 2003

Re: Excessive Swap with MSVC++ and Wine

by Alexandre Julliard

hatky <hatkyinc(a)yahoo.com> writes: > sounds like a memory leak in the code sould be > addressed to wine-devel(a)winehq.com and you should > probably open a bug on this ..... > > wine-devel, can someone comment/help on that? (I think > there wore more details on the original message) This may be fixed in current CVS, give it a try. -- Alexandre Julliard julliard(a)winehq.com

April 29, 2003

Re: FindWindow timeouts

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > After chatting to some people on IRC about windows message handling, I > remembered a bug I hit where a frozen window could kill everything > because FindWindow sends a message to every window with no timeout (to > get the window text). > > Is this right? Wouldn't it be better to make FindWindow more robust by > sending messages with a timeout so if one window in an app (or anothe > process) has frozen, it doesn't kill the caller? FindWindow doesn't send messages to other processes, exactly for that reason. It does send them to other threads inside the same process, so it can hang if a thread is not responding. That's the way it's supposed to work according to MSDN. -- Alexandre Julliard julliard(a)winehq.com

April 29, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Dan Kegel

That did it. And yes, the workaround was needed in EndPaint, too; I tried Mike's patch first, and added the EndPaint workaround myself before I noticed Dmitry's patch. The app isn't very functional, but at least it doesn't crash. I encourage anyone who is working on Visual Basic compatibility to give http://www.servicesoftware.com/sams/SAMSINDEX.exe a spin. (And look at all the pretty fixme's :-) Thanks, Dan Dmitry Timoshkov wrote: > "Dan Kegel" <dank(a)kegel.com> wrote: > > >>Backtrace: >>=>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) [painting.c:200] in user32.dll.so) (ebp=40892bc4) > > > Attached patch should help a bit. > > > > ------------------------------------------------------------------------ > > Protect BeginPaint and EndPaint from lps being NULL. > > --- cvs/hq/wine/dlls/user/painting.c Thu Jan 09 03:41:30 2003 > +++ painting.c Mon Apr 28 10:15:46 2003 > @@ -159,6 +159,8 @@ > HWND full_handle; > WND *wndPtr; > > + if (!lps) return 0; > + > if (!(full_handle = WIN_IsCurrentThread( hwnd ))) > { > if (IsWindow(hwnd)) > @@ -239,6 +241,8 @@ > */ > BOOL WINAPI EndPaint( HWND hwnd, const PAINTSTRUCT *lps ) > { > + if (!lps) return FALSE; > + > ReleaseDC( hwnd, lps->hdc ); > ShowCaret( hwnd ); > return TRUE; -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

April 29, 2003

Re: Winword, StorageImpl_Commit, Crossover and Wine

by Mike McCormack

Hi Uwe, I have implemented WriteFmtUserTypeStg and ReadFmtUserTypeStg in Crossover's Wine... I'm trying to gradually ween us off native DLLs. Alexandre should start merging shortly... Mike Uwe Bonnes wrote: > Hallo, > > running MS Word 2000 with builtin dlls doesn't allow to write files, because > of at least StorageImpl_Commit and WriteFmtUserTypeStg still stubs? Does > Crosover Office still require the native OLE dlls or has it some > implementation? > > Bye

April 29, 2003

No console output?

by Juan Lang

I'm trying to run a console program with wineconsole, and I see fixme output from the DLL I'm working on, but no output from my program. Any patches I should be applying? Wine20030408 on RH "phoebe" (8.1-ne-9 beta). FWIW, I'm working on iphlpapi.dll. I might take a crack at consolidating some duplicated code in netapi32, winsock, and wsock32 if I have time. Thanks, --Juan __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

April 29, 2003

Re: Patch to get Borland's bcc 5.5 (free beer compiler) to work

by Troy Rollo

>What version did you specify in ~/.wine/config [windows] version? win2k >I guess you ran in non NT mode. And I guess your change will do havoc to >programs needing NT mode (like Xilix ISE). Probably the limit has to be set >in dependance of the version emulated. The limit doesn't depend on version, at least not in terms of what you probably mean by version. Windows only offers a 3GB user address space on its "higher end" editions, such as Advanced Server. Some applications can't deal with this. Yes, technically this is a bug in the application, but it's a bug that would not be triggered when running on a genuine Microsoft workstation operating system. And yes, it should be configurable, or perhaps Wine should be capable of detecting which apps can deal with a 3GB user address space (as apparently executables can be marked to declare this), but as long as it's not configurable, and Wine's not capable of detecting this, it seems to me that the 2GB limit applicable to the desktop operating systems is the correct one.

April 29, 2003

Re: Patch to get Borland's bcc 5.5 (free beer compiler) to work

by Troy Rollo

On Mon, 28 Apr 2003 14:23, Dimitrie O. Paun wrote: > Few questions: > * Do you build on Windows? Until now, I have developed on Windows, but I will be continuing to target Windows from Linux using Wine to support the build environment, and possibly for testing of the application itself, together with plex86 or Bochs VMs as needed for testing under the target OS. > * Could we run bcc in Wine on Linux to build on Linux using bcc? Yes, this is what I'm doing. > * How far do you get? Do you actually get an executable? Yes. It produced (among others) an executable of 9402368 bytes (not including debugging information which is in a separate file) from 948 object files (not including libraries). > * Does it run? Not only does it run, it appears to work OK in wine. > * What are the steps you need to take? A concise list of > instructions would be nice :) I can post it on the Fun > page, so other can play with it was well. The setup of the Borland C compiler was quite straight-forward - I copied it over from an existing Windows installation. This was necessary rather than a full install because we use modified header files, but it appears the installation from the self-extracting executable won't run, so copying over from a copy installed on native Windows is necessary. Then I put it in the PATH, checked out the code and built using exactly the same procedure I used to use under Windows.

April 29, 2003

Re: slovene keyboard without dead keys

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > >>Also important is an ability by the system to change keyboards. One such > >>requirement is for BiDi text editing, where the algorithm includes, > >>among other things, instances where it is necessary to change the > >>current keyboard layout. > >> > >> > >I'm not sure XFree86 supports this feature. Without support from X we couldn't > >implement keyboard layout changes on application request. > > > Can't you set the current group? How are you planning on implementing > "INPUTLANGCHANGEREQUEST" otherwise? Just reflect the change on the X notification event and inform the app about it. > > Also I don't know > >whether XFree has a layout enumeration facility. > > > > > We use it today for comparing the keyboards. If you mean X11DRV_KEYBOARD_DetectLayout, then we don't. > I feel really bad about this, especially as I cannot perform any useful > task myself at the moment, but there is one more question. Can we > shorten the current path each key takes? > Current path: > > 1. User presses key. > 2. X sends virtual key to app (wine) > 3. Wine translates virtual key to ascii. > 4. Wine looks up the ascii in the currently selected keymap. > 5. Wine translates ascii to virtual key > 6. Virtual key is sent to Windows application, which translates it > back to ascii (usually). I'm afraid we can't change anything in that path. > This is broken on two very hurting points. > > 1. If the current locale doesn't allow for the ascii for the key > pressed, it will not pass on to the application, even if the app > is a UNICODE app. > 1. In particular - if the locale codepage is UTF-8, I cannot > type any non-latin key, as the keyboard layouts are in ANSI > codepages. > 2. There is no chance in hell in supporting a English+Hebrew+Russian > application, as the last two languages use two distinct codepages, > which cannot, technically, be loaded simultaniously (see 1.1 above > for why UTF-8 will not work). There is a patch in CX Office which supports UTF-8 encoded keyboard input (in the case of UTF-8 locale of X Input Method) and makes it possible to avoid conversion to current locale code page and back to unicode. If Alexandre considers it clean enough he will certainly merge it into WineHQ tree. > Last, there is a problem that does not hurt so much, but is still a problem > > 3. There is great uncertanty regarding the matter of whose > responsibility it is to mirror characters on right to left > language keyboards. Mirroring is the process of emiting "(" when > shift-0 is pressed, despite it being the character opposite the > one engravd on the keyboard, and trusting the BiDi display to > mirror it back. Some say the X keyboard layout should do it, while > others say the infrastructure should do it. I'm not an expert on right-to-left layouts and can't comment on this. If you (or somebody else) feel to be a motivated enough to learn how it supposed to work under real Windows and implement this behaviour in Wine taking into account X peculiarities that would be great. -- Dmitry.

April 29, 2003

Re: Excessive Swap with MSVC++ and Wine

by hatky

Hi sounds like a memory leak in the code sould be addressed to wine-devel(a)winehq.com and you should probably open a bug on this ..... wine-devel, can someone comment/help on that? (I think there wore more details on the original message) Hatky. --- Stephen Mollett <molletts(a)yahoo.com> wrote: > On Sunday 27 Apr 2003 14:51, Phil Thompson wrote: > > The problem is the amount of memory used by > link.exe. At the moment, with > > 256M of real memory and 1G of swap I quickly run > out. Under Windows2000, on > > the same machine, the link takes a long time > (30mins - 1 hour) but does > > complete. > > That sounds very similar to a problem I used to have > with another program. I > used to run NewsXpress under Wine (quite a nice, and > somewhat non-traditional > in design, newsreader) but I found that, even with > 1GB of RAM, I had to add > lots of swap in order to download large numbers of > headers. When I used to > run it on Windows, I was able to get tens or > hundreds of thousands of headers > in 128MB RAM without even approaching the point > where swapping would be > needed. > > I think it may be some inefficiency in Wine's memory > allocation subsystem - > perhaps it consistently allocates too much which > mounts up each time the > program requests more. (When I exited NewsXpress, > only about half of the > memory it had claimed was freed; the rest had to be > reclaimed with 'killall > wine'.) > > Doesn't help you very much, but perhaps it might > help someone to track down > the problem. > > Stephen > _______________________________________________ > wine-users mailing list > wine-users(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-users ===== Hatky ��: http://www.hatky.myz.info __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

April 28, 2003

FindWindow timeouts

by Mike Hearn

Hi, After chatting to some people on IRC about windows message handling, I remembered a bug I hit where a frozen window could kill everything because FindWindow sends a message to every window with no timeout (to get the window text). Is this right? Wouldn't it be better to make FindWindow more robust by sending messages with a timeout so if one window in an app (or anothe process) has frozen, it doesn't kill the caller? thanks -mike

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Bill Medland

On April 28, 2003 11:59 am, Mike Hearn wrote: > > Putting in a test would be even better than simply commenting that the > > behaviour is known for e.g. Win95; it might point out version differences > > and certainly will catch when we accidentally break the code. > > If we add a test for every micro-detail of the APIs, the test cases > would probably be larger than Wine itself. I think sanity checking input > parameters in this way is pretty obvious, for cases where it's not clear > a comment in the code is probably more useful than another test case. Sorry but I have to disagree. "The obvious" is frequently not obvious. As I asked before (but in slightly different words), is the Microsoft behaviour to return this special value when passed a null pointer, or is it to catch a segv and return the special value? And does the special value returned vary between systems? It seems to me that half of what we are doing in Wine is figuring out the facts that are not in MSDN but are important. A test is a good way of documenting what we discover to be important, in a way that allows us to check our conformance. And what's the problem with a large test suite anyway? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Mike Hearn

> Putting in a test would be even better than simply commenting that the > behaviour is known for e.g. Win95; it might point out version differences and > certainly will catch when we accidentally break the code. If we add a test for every micro-detail of the APIs, the test cases would probably be larger than Wine itself. I think sanity checking input parameters in this way is pretty obvious, for cases where it's not clear a comment in the code is probably more useful than another test case.

April 28, 2003

Winword, StorageImpl_Commit, Crossover and Wine

by Uwe Bonnes

Hallo, running MS Word 2000 with builtin dlls doesn't allow to write files, because of at least StorageImpl_Commit and WriteFmtUserTypeStg still stubs? Does Crosover Office still require the native OLE dlls or has it some implementation? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 28, 2003

Re: WineHQ: different pages with same content

by hatky

Hi Stefan Leichter, Real Explanation: it's a translation of the wwwoffle program a website server can define a default file witch means users asks for www.winehq.com give him him /index.php which comes to www.winehq.com/index.php if you ask for say www.winehq.com/test it would actually try to send you www.winehq.com/test/index.php Short one: in short it's exactly the same link and if you try pointing you browser to http://www.winehq.com/index.php?page=cvs and click on any link you will see that your are getting all the links the same way you have your off line content p.s. It has nothing to do with wine/winehq p.s.s. The same goes for ever site on the net Hatky. --- Stefan Leichter <Stefan.Leichter(a)camLine.com> wrote: > Hello, > > during browsing WineHQ offline (via wwwoffle) i > noticed that the links in the > left column of the current WWN are different to the > links on the main page > and some other (have not tested all) e.g. > > in the development section of the WWN the CVS link > is: > http://www.winehq.com/index.php?page=cvs > > on the main page (and other) the link is > http://www.winehq.com/?page=cvs > > Any reason for this? > > Bye Stefan > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

April 28, 2003

Re: Patch to get Borland's bcc 5.5 (free beer compiler) to work

by Uwe Bonnes

>>>>> "Troy" == Troy Rollo <wine(a)troy.rollo.name> writes: Troy> The only problem in the head code appears to be in the linker, Troy> which it turns out has a problem when it's told there's 3GB of Troy> user address space. Since Windows only offers a 3GB user address Troy> space in what passes for Microsoft's high end server editions of Troy> the operating system, it is unlikely that this is necessary. My Troy> solution is to drop the user address space to 2GB - if 3GB is Troy> desired, it probably should be a configurable option rather than Troy> hard coded as is the case now. Troy> I dealt with a related FIXME along the way. Troy> diff -u -r1.4 virtual.c --- dlls/ntdll/virtual.c 7 Jan 2003 Troy> 20:36:28 -0000 1.4 +++ dlls/ntdll/virtual.c 28 Apr 2003 00:05:58 Troy> -0000 @@ -102,7 +102,8 @@ # define page_mask 0xfff # define Troy> page_shift 12 # define page_size 0x1000 -# define What version did you specify in ~/.wine/config [windows] version? I guess you ran in non NT mode. And I guess your change will do havoc to programs needing NT mode (like Xilix ISE). Probably the limit has to be set in dependance of the version emulated. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Bill Medland

On April 28, 2003 07:13 am, Dmitry Timoshkov wrote: > "Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > > Dmitry> I've tested it before I sent the patch. Win2k just returns 0 > > for Dmitry> both APIs without a crash. > > > > Ah, that's fine! > > > > Is your test perhaps integrable in our testsuite? > > I don't think that every trivial change to the code requires a test suite. This is one of my pet peeves. Wine is imperfect. (What isn't!) To me it is frequently unclear whether a line of code is present because it is needed to emulate (possibly weird) Microsoft behaviour or because we want our code to be better than Microsoft's or because of brainfade on the part of the programmer or ... That is why I like to see facts stated twice. Knowing which functions are supposed to handle null pointers is, to me, not trivial. (For example expand the question; is the function handling a null pointer or is it handling all segvs as Windows strlen does?) Putting in a test would be even better than simply commenting that the behaviour is known for e.g. Win95; it might point out version differences and certainly will catch when we accidentally break the code. -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

April 28, 2003

Re: Mac OS X Support (patch with diff -u)

by Pierre d'Herbemont

On Sunday, April 27, 2003, at 10:09 PM, Pierre d'Herbemont wrote: > Hi, > Here is a patch which mostly enables compilation on Mac OS X. The > support is not full as there is still some makefiles issues on which I > can't find a *clean* correction and a new issue I discovered in this > cvs version related to the libwine_port and the getopt function. > I am sorry but there is still a lot of brokent things in this patch, it is only partially working on Mac OS X. I'll provide an other which will be better so, don't loose time while looking at this one... Sorry. Pierre

April 28, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Steven Edwards

Dimitrie O. Paun wrote: >This should answer your Nautilus/Konqueror/Explorer. I have to religious >affiliation to Nautilus or Konqueror. If the ReactOS people build a better >(and free) browser, it goes in as the default browser. Apps should compete >on features and user experience, not on irrelevant implementation details. > > > I think you are forgetting the one beast/API/toolkit to bind them all. Mozilla. It is my hope that ReactOS will be able to use either khtml as it is LGPL or use the Gecko. If you are talking about getting WINE/WIDE and GTK to play nice together then your and our time will be better spent on mozilla with explorer. Thanks Steven

April 28, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Brian Vincent (C)

> Wide doesn't change that. In fact, being based on Wine, it will implicitly > benefit from all the integration work we do on the Wine side. But at that > point, people will ask: what is the difference between Wide, and just Wine > running in Gnome? I think the problems you're going to run into immediately are: 1) Wine still isn't that far along to support something like this, bigger problems need to be solved first. Not the least of which is just good integration with the existing distributions (which will solve 90% of the problems you'll run into creating your own desktop.) 2) Finding people to do the work. Right now there seems to be a problem finding someone to work on the config tool, let alone a full blown desktop with multiple integrated apps. 3) Documentation.. it's never been one of the strong points of the project and a whole desktop environment needs a lot of it. 4) API.. Alexandre made an excellent point that promoting an API designed by MS puts the ball in their court. Pretty hard to compete on even terms with a company that has a lot of talented, motivated people and a war chest bigger than the GNP of a lot of nations. I think the proper thing to do is write it up an outline of it and put it on the "Fun Projects" page. Maybe someone will find the time to work on it. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

April 28, 2003

Re: Mac OS X Support (patch with diff -u)

by Pierre d'Herbemont

On Sunday, April 27, 2003, at 10:59 PM, Marcus Meissner wrote: > On Sun, Apr 27, 2003 at 10:09:43PM +0200, Pierre d'Herbemont wrote: >> Hi, >> Here is a patch which mostly enables compilation on Mac OS X. The >> support is not full as there is still some makefiles issues on which I >> can't find a *clean* correction and a new issue I discovered in this >> cvs version related to the libwine_port and the getopt function. >> >> Sorry for the -u option, I thought it was enabled by default :( > > The PPC assembly stuff appears correct to me :) > Hum... I dont understand on which assembler part you refer :( . (sorry but you know my english is... ;) If you were asking why did I had a #ifdef __darwin__ on the PPC asm, it was because it seems that Mac OS X linker doesn't like the mnemonics syntax used (dunno why, but...). For example it wants 'r1' instead of '1', and for gcc there was some register preservation we must use (r0 with lwarx)... That is why there is those corrections. But if you were just saying its ok, then, hum... ok :) Thanks, Pierre

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Dmitry> I've tested it before I sent the patch. Win2k just returns 0 for > Dmitry> both APIs without a crash. > > Ah, that's fine! > > Is your test perhaps integrable in our testsuite? I don't think that every trivial change to the code requires a test suite. -- Dmitry.

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Dmitry Timoshkov

"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Is lps==NULL an argument that BeginPaint() and EndPaint() should cope with or > is it a result for errors hidden deeper? I've tested it before I sent the patch. Win2k just returns 0 for both APIs without a crash. -- Dmitry.

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Uwe Bonnes

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> "Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >> Is lps==NULL an argument that BeginPaint() and EndPaint() should cope >> with or is it a result for errors hidden deeper? Dmitry> I've tested it before I sent the patch. Win2k just returns 0 for Dmitry> both APIs without a crash. Ah, that's fine! Is your test perhaps integrable in our testsuite? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Mike Hearn

> Is lps==NULL an argument that BeginPaint() and EndPaint() should cope with or > is it a result for errors hidden deeper? MSDN doesn't indicate any behaviour for when this is null. It just says the functions should fill out the struct that it points to. So passing NULL here is an error, that we have to protect ourselves against (clearly MS does) -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Uwe Bonnes

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> "Dan Kegel" <dank(a)kegel.com> wrote: >> Backtrace: =>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) >> [painting.c:200] in user32.dll.so) (ebp=40892bc4) Dmitry> Attached patch should help a bit. Dmitry> -- Dmitry. Protect BeginPaint and EndPaint from lps being NULL. Dmitry> --- cvs/hq/wine/dlls/user/painting.c Thu Jan 09 03:41:30 2003 Dmitry> +++ painting.c Mon Apr 28 10:15:46 2003 @@ -159,6 +159,8 @@ HWND Dmitry> full_handle; WND *wndPtr; Dmitry> + if (!lps) return 0; + if (!(full_handle = WIN_IsCurrentThread( Dmitry> hwnd ))) { if (IsWindow(hwnd)) @@ -239,6 +241,8 @@ */ BOOL Dmitry> WINAPI EndPaint( HWND hwnd, const PAINTSTRUCT *lps ) { + if Dmitry> (!lps) return FALSE; + ReleaseDC( hwnd, lps->hdc ); ShowCaret( Dmitry> hwnd ); return TRUE; Is lps==NULL an argument that BeginPaint() and EndPaint() should cope with or is it a result for errors hidden deeper? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 28, 2003

Re: slovene keyboard without dead keys

by Shachar Shemesh

Dmitry Timoshkov wrote: >Yes, that's one of the cases when our current scheme doesn't work. But one >excuse for us is that XFree86 4.3.0 is fairly new. > > All I was saying was that we NEED to support it. We can no longer hide behind X's inability to do so, as it now does. The new X keyboard layouts make much more sense, and making people effectively revert to the old one is an incorrect solution, IMHO. >>Excellent. Please bear in mind, however, that sometimes it is >>desireable, and even crucial, to have more than one layout and switch. >> >> > >That should be fairly easy to implement, since under XFree86 4.3 every international >layout is not mixed with any other, even with an en_US one. > > I was meaning for X 4.3.0. I have no problem that people working with earlier versions will register under wine as having two keyboards (i.e. - US+another one). >>Also, the keyboard switching messages are crucial to some BiDi applications. >> >> >Do you mean WM_INPUTLANGCHANGEREQUEST and WM_INPUTLANGCHANGE messages? > > That's what I mean. >>Also important is an ability by the system to change keyboards. One such >>requirement is for BiDi text editing, where the algorithm includes, >>among other things, instances where it is necessary to change the >>current keyboard layout. >> >> >I'm not sure XFree86 supports this feature. Without support from X we couldn't >implement keyboard layout changes on application request. > Can't you set the current group? How are you planning on implementing "INPUTLANGCHANGEREQUEST" otherwise? > Also I don't know >whether XFree has a layout enumeration facility. > > We use it today for comparing the keyboards. >Windows knows nothing about a KOI8-R based locale. 20866 is just one of >the code page numbers. Of course in order to support it we may introduce >new, Wine specific LCID with SUBLANG_RUSSIAN_KOI8R. > > We may have to. I feel really bad about this, especially as I cannot perform any useful task myself at the moment, but there is one more question. Can we shorten the current path each key takes? Current path: 1. User presses key. 2. X sends virtual key to app (wine) 3. Wine translates virtual key to ascii. 4. Wine looks up the ascii in the currently selected keymap. 5. Wine translates ascii to virtual key 6. Virtual key is sent to Windows application, which translates it back to ascii (usually). This is broken on two very hurting points. 1. If the current locale doesn't allow for the ascii for the key pressed, it will not pass on to the application, even if the app is a UNICODE app. 1. In particular - if the locale codepage is UTF-8, I cannot type any non-latin key, as the keyboard layouts are in ANSI codepages. 2. There is no chance in hell in supporting a English+Hebrew+Russian application, as the last two languages use two distinct codepages, which cannot, technically, be loaded simultaniously (see 1.1 above for why UTF-8 will not work). Last, there is a problem that does not hurt so much, but is still a problem 3. There is great uncertanty regarding the matter of whose responsibility it is to mirror characters on right to left language keyboards. Mirroring is the process of emiting "(" when shift-0 is pressed, despite it being the character opposite the one engravd on the keyboard, and trusting the BiDi display to mirror it back. Some say the X keyboard layout should do it, while others say the infrastructure should do it. What I suggest (and what I was planning on doing myself, should I ever have any free time again) was to leave the current keyboard detection routine as is (seperating the different keyboards, of course), but not translate the VKey to ascii, but send it on as is. When the application asks to translate, then we look it up in what we know to be the current keyboard. This way, if the keyboard layout has ( and ) non-switched, we will switch them ourselves. This means that Wine has a different keyboard than the rest of X, but that's on purpose. Shachar

April 28, 2003

New patch for WINE support in valgrind uploaded to sourceforge

by Adam Gundy

A new version of the patch to valgrind needed to support WINE has been uploaded to Sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… It should apply cleanly to current valgrind CVS. This version of the patch will now work with an unmodified WINE CVS version. This is because it now _fully_ implements clone() support - ie it really does create system level threads. Currently only one thread can run at a time, so there are no locking issues in the main valgrind code. To use with WINE, you need to get a CVS checkout of valgrind, then apply the patch using: export CVSROOT=:pserver:anonymous(a)cvs.sourceforge.net:/cvsroot/valgrind cvs login cvs co valgrind patch -p0 < valgrind-wine.patch.13 then build and install valgrind: autogen.sh ./configure make install Get a CVS checkout of WINE by following the instructions at: http://www.winehq.com/?page=cvs then configure (for debugging) and build: CFLAGS=-g ./configure make depend && make install now you can start looking for bugs in WINE, and bugs in your own (debug) Windows code. Copy any DLLs/EXEs to somewhere WINE can get to them, plus copy any .PDB files that go with them into the same directory. Run WINE under valgrind using eg: valgrind --num-callers=30 --workaround-gcc296-bugs=yes wine notepad.exe or even: valgrind --num-callers=30 --workaround-gcc296-bugs=yes --gdb-attach=yes wine notepad.exe enjoy. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Mike Hearn

Try this patch: --- painting.c.old 2003-04-28 10:44:52.000000000 +0100 +++ painting.c 2003-04-28 10:44:55.000000000 +0100 @@ -159,6 +159,9 @@ HWND full_handle; WND *wndPtr; + /* sanity check */ + if (!lps) return 0; + if (!(full_handle = WIN_IsCurrentThread( hwnd ))) { if (IsWindow(hwnd)) On Mon, 2003-04-28 at 07:26, Dan Kegel wrote: > Wine is coming along! It can *almost* run a real world VB app > I downloaded tonight. I'm trying to fix an old TV, and I wanted > to see if Sams has a manual for it, so I downloaded their > index program (http://www.servicesoftware.com/sams/) > and was happy to discover it installed properly under a > recent Wine (once I copied in the msiexec stuff, stdole2.tlb, etc.). > > However, it didn't quite run properly. Here's what I got running > it under wine-20030408: > > Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x409e5873). > In 32-bit mode. > 0x409e5873 (BeginPaint+0x9f [painting.c:200] in user32.dll.so): movl %eax,0x0(%edx) > 203 if (!lps->hdc) > Wine-dbg>bt > Backtrace: > =>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) [painting.c:200] in user32.dll.so) (ebp=40892bc4) > 1 0x52195475 (GRIDX.OCX..text+0x14475 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c18) > 2 0x52194fe0 (GRIDX.OCX..text+0x13fe0 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c40) > 3 0x5218b961 (GRIDX.OCX..text+0xa961 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c88) > 4 0x409cc817 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40892cac) > 5 0x409cc875 (WINPROC_CallWndProc+0x55(proc=0x41855438, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:185] in user32.dll.so) (ebp=40892cd8) > 6 0x409d1535 (CallWindowProcA+0xf9(func=0x40df0908, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2812] in user32.dll.so) (ebp=40892d0c) > 7 0x409b5a3e (DispatchMessageA+0x96(msg=0x40892d68) [message.c:794] in user32.dll.so) (ebp=40892d50) > 8 0x66014979 (MSVBVM60.DLL.__vbaInStr+0x3b7 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892d90) > 9 0x660148b2 (MSVBVM60.DLL.__vbaInStr+0x2f0 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892dd4) > 10 0x66014790 (MSVBVM60.DLL.__vbaInStr+0x1ce in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=6601a360) > 11 0x66010e00 (MSVBVM60.DLL.BASIC_CLASS_QueryInterface+0x17 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=660d3526) > 12 0x0c2474ff (SAMSINDX.exe..rsrc+0xbe334ff) (ebp=0424448b) > *** Invalid address 0x0424448b (SAMSINDX.exe..rsrc+0x3e3048b) > > I can run this app under real Windows, but this is such a juicy little > testcase I bet someone will want to take a look at it :-) > - Dan -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 28, 2003

Re: slovene keyboard without dead keys

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > >I don't see why explicitly adding a "us" keyboard layout would hurt people, > >since before 4.3.0 release en_US was a mandatory layout existing whether > >the user wanted it or not. > > > > > Ok, how about this. A Russian immegrant to Israel (and there are lots of > those), would want his keyboard settings to be "us,il,ru". Windows > supports this. X now supports this. Why shouldn't Wine? Yes, that's one of the cases when our current scheme doesn't work. But one excuse for us is that XFree86 4.3.0 is fairly new. > >Actually I have a plan to implement support for keyboard layout Win32 APIs > >and that anyway requires rewrite of big chunks of the existing keyboard code > >in x11drv, and as a part of that rewrite I'm going to decouple all existing > >keyboard layout tables with a US English one and build new tables with LCID > >and a layout id, > > > Excellent. Please bear in mind, however, that sometimes it is > desireable, and even crucial, to have more than one layout and switch. That should be fairly easy to implement, since under XFree86 4.3 every international layout is not mixed with any other, even with an en_US one. > Also, the keyboard switching messages are crucial to some BiDi applications. Do you mean WM_INPUTLANGCHANGEREQUEST and WM_INPUTLANGCHANGE messages? > Also important is an ability by the system to change keyboards. One such > requirement is for BiDi text editing, where the algorithm includes, > among other things, instances where it is necessary to change the > current keyboard layout. I'm not sure XFree86 supports this feature. Without support from X we couldn't implement keyboard layout changes on application request. Also I don't know whether XFree has a layout enumeration facility. > > but so far I don't know how to support several layouts for > >single locale but with different code pages (for instance for Russian locale > >we need to support 20866 (KOI8-R) and 1251 code pages). > > > > > Don't they have different sub-langs? How does Win32 hadle this? Windows knows nothing about a KOI8-R based locale. 20866 is just one of the code page numbers. Of course in order to support it we may introduce new, Wine specific LCID with SUBLANG_RUSSIAN_KOI8R. -- Dmitry.

April 28, 2003

WineHQ: different pages with same content

by Stefan Leichter

Hello, during browsing WineHQ offline (via wwwoffle) i noticed that the links in the left column of the current WWN are different to the links on the main page and some other (have not tested all) e.g. in the development section of the WWN the CVS link is: http://www.winehq.com/index.php?page=cvs on the main page (and other) the link is http://www.winehq.com/?page=cvs Any reason for this? Bye Stefan

April 28, 2003

Crash in BeginPaint running Sams Photofact index, a free VB app

by Dan Kegel

Wine is coming along! It can *almost* run a real world VB app I downloaded tonight. I'm trying to fix an old TV, and I wanted to see if Sams has a manual for it, so I downloaded their index program (http://www.servicesoftware.com/sams/) and was happy to discover it installed properly under a recent Wine (once I copied in the msiexec stuff, stdole2.tlb, etc.). However, it didn't quite run properly. Here's what I got running it under wine-20030408: Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x409e5873). In 32-bit mode. 0x409e5873 (BeginPaint+0x9f [painting.c:200] in user32.dll.so): movl %eax,0x0(%edx) 203 if (!lps->hdc) Wine-dbg>bt Backtrace: =>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) [painting.c:200] in user32.dll.so) (ebp=40892bc4) 1 0x52195475 (GRIDX.OCX..text+0x14475 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c18) 2 0x52194fe0 (GRIDX.OCX..text+0x13fe0 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c40) 3 0x5218b961 (GRIDX.OCX..text+0xa961 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c88) 4 0x409cc817 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40892cac) 5 0x409cc875 (WINPROC_CallWndProc+0x55(proc=0x41855438, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:185] in user32.dll.so) (ebp=40892cd8) 6 0x409d1535 (CallWindowProcA+0xf9(func=0x40df0908, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2812] in user32.dll.so) (ebp=40892d0c) 7 0x409b5a3e (DispatchMessageA+0x96(msg=0x40892d68) [message.c:794] in user32.dll.so) (ebp=40892d50) 8 0x66014979 (MSVBVM60.DLL.__vbaInStr+0x3b7 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892d90) 9 0x660148b2 (MSVBVM60.DLL.__vbaInStr+0x2f0 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892dd4) 10 0x66014790 (MSVBVM60.DLL.__vbaInStr+0x1ce in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=6601a360) 11 0x66010e00 (MSVBVM60.DLL.BASIC_CLASS_QueryInterface+0x17 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=660d3526) 12 0x0c2474ff (SAMSINDX.exe..rsrc+0xbe334ff) (ebp=0424448b) *** Invalid address 0x0424448b (SAMSINDX.exe..rsrc+0x3e3048b) I can run this app under real Windows, but this is such a juicy little testcase I bet someone will want to take a look at it :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

April 28, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 27, 2003 05:32 pm, Francois Gouget wrote: > Bah, I don't really care. Maybe because I use neither Gnome nor KDE. > I see your point but I can't help but think that it's a bit of a stretch > to say Trolltech could become another monopoly when there is a GPL > implementation available, which is why I said the above. I really don't understand you. It seems to me obviously clear that a GPLed platform is as useful as a GPLed Wine. This is not something minor, and it's no stretch -- the Trolls would have the monopoly over all commercial apps, which is where the money is. You may not use either, but that's no solution. People will have to choose one or the other, they can't go back to Xaw or Motif. > Now if you think WIDE is portable, tell us how. Well, we do have Winelib working on non-i386 platforms, don't we? But bottom line, people worried about portability should program to the Gnome/Gtk API, I haven't suggested for a moment we drop Gtk and code everything to the Win32 API. For people like the emule guys that like to code to the Win32 API, they can continue to do so if they so wish. > So the situation will remain the same: we will haev KDE applications and > WIDE applications and they will not be interoperable. I.e. it won't be > possible to insert an Excel spreadsheet in a KWord document. No, it will be better: you will be able to have deep integration between Win32 apps and Gnome apps, no small feat. > Does that include interoperability with OLE/COM/DCOM or just the look > and feel integration? Well, the OLE/COM/DCOM bit is the interesting one, the look and feel is simple and has other solutions, as we discussed. > I believe where we differ is on the method: > * I think we should work on Wine to make that possible (though > there may be some work to do in Gnome and KDE). For sure. But this will work for things like L&F. The difficult things aren't even considered by anyone at this point. So no, we are quite in violent agreement here. > * You think that it is mostly Gnome that must be modified to use the > Wine APIs and you are ready to drop/ignore KDE. I believe you also > proposed to replace Nautilus/Konqueror with Explorer, and to develop > a new window manager. No, I'm not dropping/ignoring KDE. It's just that right now we're talking about some deep integration issues that no one even considered before. Right now, integration is used to describe L&F. It's fairly clear we need to be able to integrate with things like BlueCurve so Wine integrates as much as possible in both Gnome and KDE. Wide doesn't change that. In fact, being based on Wine, it will implicitly benefit from all the integration work we do on the Wine side. But at that point, people will ask: what is the difference between Wide, and just Wine running in Gnome? And it's a good question. Part of the answer is that Wide may choose to use Wine's OLE implementation to integrate Bonobo/Win32/OpenOffice apps. But that's really wishfull thinking, I'm not even sure that's at all possible. The real answer is that Wide is just like Gnome, but with a different set of mentalities. Instead of picking the default apps only based on religious things like 'is it using Gtk?', I propose we choose the default apps from the set of all Gnome and free Win32 apps (and any other platform that integrates nicely). I am sorry I can't include KDE here as well, but it's because their platform is not free enough, not because I don't like the Qt framework. If tomorrow we have a LGPL Qt implementation, they would be added to the pool of possible apps. This should answer your Nautilus/Konqueror/Explorer. I have to religious affiliation to Nautilus or Konqueror. If the ReactOS people build a better (and free) browser, it goes in as the default browser. Apps should compete on features and user experience, not on irrelevant implementation details. -- Dimi.

April 28, 2003

Re: slovene keyboard without dead keys

by Shachar Shemesh

Dmitry Timoshkov wrote: >I don't see why explicitly adding a "us" keyboard layout would hurt people, >since before 4.3.0 release en_US was a mandatory layout existing whether >the user wanted it or not. > > Ok, how about this. A Russian immegrant to Israel (and there are lots of those), would want his keyboard settings to be "us,il,ru". Windows supports this. X now supports this. Why shouldn't Wine? >>I would volunteer to do it, except I'm unusually busy of late. I know >>that you have messed around with the keyboard code at some time. If you >>have time, I recommend you look at it. >> >> > >Actually I have a plan to implement support for keyboard layout Win32 APIs >and that anyway requires rewrite of big chunks of the existing keyboard code >in x11drv, and as a part of that rewrite I'm going to decouple all existing >keyboard layout tables with a US English one and build new tables with LCID >and a layout id, > Excellent. Please bear in mind, however, that sometimes it is desireable, and even crucial, to have more than one layout and switch. Also, the keyboard switching messages are crucial to some BiDi applications. Also important is an ability by the system to change keyboards. One such requirement is for BiDi text editing, where the algorithm includes, among other things, instances where it is necessary to change the current keyboard layout. > but so far I don't know how to support several layouts for >single locale but with different code pages (for instance for Russian locale >we need to support 20866 (KOI8-R) and 1251 code pages). > > Don't they have different sub-langs? How does Win32 hadle this? Shachar

April 28, 2003

Re: Patch to get Borland's bcc 5.5 (free beer compiler) to work

by Dimitrie O. Paun

On April 27, 2003 08:15 pm, Troy Rollo wrote: > The only problem in the head code appears to be in the linker, which it > turns out has a problem when it's told there's 3GB of user address space. This is pretty cool. I've added you to the Fun page: http://63.138.153.104/wine/Wine-Fun.html#source Few questions: * Do you build on Windows? * Could we run bcc in Wine on Linux to build on Linux using bcc? * How far do you get? Do you actually get an executable? * Does it run? * What are the steps you need to take? A concise list of instructions would be nice :) I can post it on the Fun page, so other can play with it was well. -- Dimi.

April 28, 2003

Re: New plans for wintab work.

by Aric Stewart

Hi Rob, Sorry for the delay before. I took friday off and have has a busy weekend. > > If Aric's pach is considered ready to go into CVS, then I can > start working on this in the following areas: > Alexandre makes this call :) > Painter support. > I beleive there are some problems getting Painter to work with > wintab. > This is my priority. This would be awesome. I banged my head against it for a while before moving on, where I am. It looks like it has to do with timing for the button messages and the information in the tablet packets. Under windows we receive a WM_LBUTTONDOWN message significantly before we seen any normal pressure or value in the pkButton field of the packet. Similarly the button up come right when the pressure and pkButton field are cleared. However under X, we get normal pressure until the threshold value before generating the Button event. additionally the button up can occurs while normal pressure is still around. I think this is confusing Painter because it gets caught inside of a IsButtonDown function and often gets very confused if the button is down or not. > > Additional configuration for wintab. > Aric's wintab reqires no configuration. > It is only targeted at Intuos tablets. > > My implementation was to have a zero config default > for the intuos2 tablet, similar to Aric's. > Config could be provided where necessary to > modify how an intuos tablet is seen by wintab, > or to allow other tablet types to be used by wintab. > > I could merge this work into Aric's implementation. > This would require significant re-factoring of Aric's > data structs to match the more generic data structs I > implemented. I tried to keep the data structures as generic as possible. They are all taken directly from the wintab 1.1 api specification on the web. I tried the fill most of the structures as generically as possible based on information I can gleed from the drv_wacom.o implementation for XFree86-4 The areas where i had questions i did comparisons with the windows programs with the same intuos2 tablet i was working on under linux. So those areas may be a bit more specific. I am pretty sure that most any other wacom tablets would work. I do not know if anyone has tested any other wintab devices but I would be very curious how they would work. Sort of the biggest trick i had to play was with the cursor ID numbering. If you look at these faqs i wrote up for CrossOver Office 2.0 you can see. http://crossover.codeweavers.com/docs/office/html/troubleshooting.html#PHOT… I was tempted to make the cursor IDs a value in a config file but thought it would just be best to try to avoid having to do much work in the config file. > > I may not have too much time to do work for the next 3 weeks, > but I'd hope to make some progress on the painter side. > That would be great. I also hope that you find it works well for you and photoshop. Other areas that are "less than perfect" *) None of the manager functions are there. *) All contexts are basically CXO_SYSTEM contexts. this means that the applications always get the mouse moves and button events for the tablet. This is find for Photoshop and painter because they both want CXO_SYSTEM contexts. But under windows you can have contexts where the application does not get the mouse events for the tablet. only the tablet messages. *) nothing is implemented for relative mode packets. All the data is presented in absolute mode. *) a number of things are not implemented such as tangent pressure, and other axis that the intous tablet does not have. *) I am not particularly happy with the way that the packet data is communicated from the x11drv layer to the wintab32 layer. Also i think the way i handle the packet queues is sort of fast and sloppy. Sorry again for the lack of communication before, I look forward to the improvements you can make. thanks -aric

April 28, 2003

Re: slovene keyboard without dead keys

by Dmitry Timoshkov

"Rok Mandeljc" <rokmandeljc(a)hotmail.com> wrote: > Thanks for help, but that doesn't work for me. If I do Option "XkbLayout" > "us,si" my keyboard is properly detected, but dead keys (alt+something) are > screwed up both in wine and linux (in both us and si). That's a completely different problem and very likely caused by missing proper environment variables controlling locale needed by Wine. -- Dmitry.

April 27, 2003

Re: X11DRV_DIB_CreateDIBSection

by Ulrich Weigand

Robert Lunnon wrote: > Under Solaris I have a problem with this function.which appears to protect a > section of the DIB giving a portion of it no access at all and when the > application tries to blit from it later, a segfault results. That's how it is supposed to be. The segfault handler should then call the handler installed by the X11 driver (via VIRTUAL_HandleFault), which should mark the DIB as user-accessed, mark the DIB memory as readable, and return to the app. If this doesn't work correctly, there is most likely a problem with the sparc segfault handler not calling VIRTUAL_HandleFault properly (i.e. not called at all, called with incorrect fault address, ...). Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Francois Gouget

On Sun, 27 Apr 2003, Dimitrie O. Paun wrote: > On April 27, 2003 12:47 am, Francois Gouget wrote: > > > Only as far as commercial companies are concerned. Under the GPL > > license, anyone can fork QT. > > And you think this is any way acceptable? Bah, I don't really care. Maybe because I use neither Gnome nor KDE. I see your point but I can't help but think that it's a bit of a stretch to say Trolltech could become another monopoly when there is a GPL implementation available, which is why I said the above. > I am sorry, but an OS that puts commercial development at such a > tremendous disadvantage (that is, subject to the monopolistic whims of > one company) is not a platform. So all the portability issues you > listed don't even start to apply. Because KDE's license is bad it does not matter whether WIDE is portable or not? That does not make sense. Your telling people to ignore a fatal flaw in WIDE just because _one_ of the other frameworks has what you say is another fatal flaw. That's jumping out of the fire and into the pan. Now if you think WIDE is portable, tell us how. > > So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT > > and instead develop using Win32+OLE+COM? > > No! Unfortunately, KDE/QT is in a difficult situation due to the > licensing problem. It is the desktop of choice for most people, > I use it, but I can't see what we can do about it. So the situation will remain the same: we will haev KDE applications and WIDE applications and they will not be interoperable. I.e. it won't be possible to insert an Excel spreadsheet in a KWord document. > > I'm not criticizing, I'm trying > > to clarify because in one of your previous email I had the impression > > that you advocated development against a Win32-based Gtk API. > > Gtk is already ported to Win32. App wouldn't even know what Gdk backend > is used, they would be just the same. Does that include interoperability with OLE/COM/DCOM or just the look and feel integration? > They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot of > free apps (see the top SF downloads for examples) that use the Win32 > API, so it's not something new I'm suggesting? Do you think it's more > moral/ethical to treat these apps as second class citizens in Linux? I don't see the problem. Do you think it's more moral/ethical to treat open-source MacOS/X applications as second class citizens in Linux? What about DOS applications? OS/2 applications? Amiga applications? > > Yes it would be very cool. I am far from being an expert on OLE/DCOM but > > I have been told that it may be feasible. Probably a heck of a lot of > > work though. > > I'm not saying it would be easy. But given that Bonobo was so deeply > inspired by OLE, I'm hoping it can map easily onto an OLE backend, > and maybe that leads to an easier path to integration. I think we agree on most of the goals: we both want to integrate the Wine, Gnome and KDE environments. By 'integrate' I mean, integrate the menus and associations, automatically use the same look and feel, and make it possible to use object components of one in the other and reciprocally. I believe where we differ is on the method: * I think we should work on Wine to make that possible (though there may be some work to do in Gnome and KDE). * You think that it is mostly Gnome that must be modified to use the Wine APIs and you are ready to drop/ignore KDE. I believe you also proposed to replace Nautilus/Konqueror with Explorer, and to develop a new window manager. > > Other questions so I better understand: > > * are you proposing source-level compatibility or binary level > > compatibility? > > Both. We get both with Wine, we should be able to keep that. Of course binary compatibility will only work on the x86 platform. Porting applications to another platform will require recompiling them. This will put commercial applications based on a commercial framework such as MFC and Visual Basic at a big disadvantage. Is it fair to tell people that this is the way to go when it will restrict them to the x86 platform? I think not. Then you would push Gnome/Gtk as the framework of choice for WIDE. But for these developpers, what's the advantage of WIDE compared to the regular Gnome? It seems to me that it only risks to tempt them into using non-portable APIs. > > * how do you propose to handle the issue of drive letters? > > What we do in Wine is just fine. I'm only concerned with GUI apps, > and there I see drive letters as just shorthands to a bunch of > dirs. If you like that, go nuts. I see it as mainly a UI thing, > other than that we'd try to pass Unix paths around as much as > possible. You seem very concerned about look and feel. But drive letters are just as big an issue. You won't have a unified desktop unless this is handled uniformly. Or do you propose that Gnome applications too use drive letters? -- 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

April 27, 2003

Re: Mac OS X Support (patch with diff -u)

by Marcus Meissner

On Sun, Apr 27, 2003 at 10:09:43PM +0200, Pierre d'Herbemont wrote: > Hi, > Here is a patch which mostly enables compilation on Mac OS X. The > support is not full as there is still some makefiles issues on which I > can't find a *clean* correction and a new issue I discovered in this > cvs version related to the libwine_port and the getopt function. > > Sorry for the -u option, I thought it was enabled by default :( The PPC assembly stuff appears correct to me :) Ciao, Marcus

April 27, 2003

Wine on cygwin

by Steven Edwards

It seems kernel and ntdll are not seperated properly as I can build ntdll.dll on cygwin now with no problems but when it gets to dlls/kernel it is failing with this error. If I include the ntdll files wine/memory/* wine/loaders/* and others in kernel32 then it will build. Thanks Steven dllwrap -k --def kernel32.spec.def -o kernel32.dll kernel.res.o ../../ole/ole2nl s.o change.o comm.o computername.o console.o debugger.o editline.o format_msg.o kernel_main.o lcformat.o locale.o stress.o string.o sync.o thunk.o time.o toolhe lp.o utthunk.o win87em.o windebug.o wowthunk.o kernel32.dll.dbg.o --entry _MAIN _KernelInit -L../../dlls -lntdll -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lm Warning: resolving _MAIN_KernelInit by linking to _MAIN_KernelInit(a)12 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups comm.o(.text+0x10f5): In function `EscapeCommFunction': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:593: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x15b2): In function `PurgeComm': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:710: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x1761): In function `ClearCommError': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:751: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x1939): In function `SetupComm': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:815: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x1e12): In function `SetCommState': /cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:910: undefined reference to `_F ILE_GetUnixHandle' comm.o(.text+0x25fc):/cygdrive/g/src/wine-dev/wine/dlls/kernel/comm.c:1255: more undefined references to `_FILE_GetUnixHandle' follow computername.o(.text+0x5e4): In function `COMPUTERNAME_Init': /cygdrive/g/src/wine-dev/wine/dlls/kernel/computername.c:219: undefined referenc e to `_PROFILE_GetWineIniBool' computername.o(.text+0x161c): In function `SetComputerNameW': /cygdrive/g/src/wine-dev/wine/dlls/kernel/computername.c:542: undefined referenc e to `_PROFILE_GetWineIniBool' kernel_main.o(.text+0x86): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main.c:75: undefined reference to `_FILE_umask' kernel_main.o(.text+0x98):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main. c:82: undefined reference to `_RELAY_Init' kernel_main.o(.text+0xf3):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main. c:127: undefined reference to `_TASK_CreateMainTask' kernel_main.o(.text+0x13f):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:138: undefined reference to `_main_create_flags' kernel_main.o(.text+0x196):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:141: undefined reference to `_main_create_flags' kernel_main.o(.text+0x1bb):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:95: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x1d5): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/../../include/wine/library.h:186: unde fined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x1ef):/cygdrive/g/src/wine-dev/wine/dlls/kernel/../../inclu de/wine/library.h:187: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x219): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/../../include/wine/winbase16.h:402: un defined reference to `_TASK_InstallTHHook' kernel_main.o(.text+0x225): In function `process_attach': /cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main.c:110: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x249):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:110: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x260):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:110: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x26c):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:111: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x290):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:111: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x2a7):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:111: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x2b3):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:112: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x2d7):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:112: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x2ee):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:112: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x2fa):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:113: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x31e):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:113: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x335):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:113: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x341):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:114: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x365):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:114: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x37c):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:114: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x388):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:115: undefined reference to `_DOSMEM_MapDosToLinear' kernel_main.o(.text+0x3ac):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:115: undefined reference to `_GLOBAL_CreateBlock' kernel_main.o(.text+0x3c3):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:115: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x3ca):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:116: undefined reference to `_DOSMEM_0000H' kernel_main.o(.text+0x3de):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:116: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x3e5):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:117: undefined reference to `_DOSMEM_BiosSysSeg' kernel_main.o(.text+0x3f9):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:117: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x400):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:118: undefined reference to `_DOSMEM_BiosDataSeg' kernel_main.o(.text+0x414):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:118: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x41b):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:119: undefined reference to `_DOSMEM_BiosSysSeg' kernel_main.o(.text+0x42f):/cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main .c:119: undefined reference to `_NE_SetEntryPoint' kernel_main.o(.text+0x471): In function `MAIN_KernelInit': /cygdrive/g/src/wine-dev/wine/dlls/kernel/kernel_main.c:160: undefined reference to `_WriteOutProfiles16(a)0' locale.o(.text+0x2792): In function `LOCALE_Init': /cygdrive/g/src/wine-dev/wine/dlls/kernel/locale.c:1012: undefined reference to `_CODEPAGE_Init' thunk.o(.text+0x4ab): In function `_loadthunk': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:164: undefined reference to `_ NE_GetOrdinal' thunk.o(.text+0x515): In function `_loadthunk': /cygdrive/g/src/wine-dev/wine/dlls/kernel/../../include/wine/winbase16.h:402: un defined reference to `_NE_GetEntryPointEx' thunk.o(.text+0x1c82): In function `IsPeFormat16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1115: undefined reference to ` _OpenFile16(a)12' thunk.o(.text+0x1ca8):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1117: un defined reference to `__llseek16(a)12' thunk.o(.text+0x1cc2):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1118: un defined reference to `__lread16(a)12' thunk.o(.text+0x1d0b):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1120: un defined reference to `__llseek16(a)12' thunk.o(.text+0x1d28):/cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1121: un defined reference to `__lread16(a)12' thunk.o(.text+0x2531): In function `C16ThkSL': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1368: undefined reference to ` ___wine_call_from_16_thunk' thunk.o(.text+0x2729): In function `C16ThkSL01': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1425: undefined reference to ` ___wine_call_from_16_thunk' thunk.o(.text+0x2b8d): In function `THUNK_AllocLSThunklet': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1592: undefined reference to ` _TASK_GetPtr' thunk.o(.text+0x2c85): In function `THUNK_AllocSLThunklet': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1626: undefined reference to ` _TASK_GetPtr' thunk.o(.text+0x3341): In function `CBClientThunkSL': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1894: undefined reference to ` _CALL32_CBClient' thunk.o(.text+0x33b6): In function `CBClientThunkSLEx': /cygdrive/g/src/wine-dev/wine/dlls/kernel/thunk.c:1910: undefined reference to ` _CALL32_CBClientEx' wowthunk.o(.text+0xc4): In function `K32WOWGetVDMPointer': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:92: undefined reference to `_DOSMEM_MapRealToLinear' wowthunk.o(.text+0x3c4): In function `K32WOWHandle32': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:238: undefined reference to `_TASK_GetPtr' wowthunk.o(.text+0x5b4): In function `K32WOWHandle16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:279: undefined reference to `_THREAD_IdToTEB' wowthunk.o(.text+0x6ec): In function `GetVDMPointer32W16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:341: undefined reference to `_GlobalHandle16(a)4' wowthunk.o(.text+0x6fa):/cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:341 : undefined reference to `_GlobalPageLock16(a)4' wowthunk.o(.text+0x7ac): In function `LoadLibraryEx32W16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:373: undefined reference to `_DIR_SearchPath' wowthunk.o(.text+0x225): In function `K32WOWYield16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:195: undefined reference to `_Yield16(a)0' wowthunk.o(.text+0x23e): In function `K32WOWDirectedYield16': /cygdrive/g/src/wine-dev/wine/dlls/kernel/wowthunk.c:208: undefined reference to `_DirectedYield16(a)4' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [kernel32.dll] Error 1

April 27, 2003

Re: slovene keyboard without dead keys

by Rok Mandeljc

----- Original Message ----- From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> To: "Rok Mandeljc" <rokmandeljc(a)hotmail.com> Cc: <wine-devel(a)winehq.com> Sent: Saturday, April 26, 2003 12:28 PM Subject: Re: slovene keyboard without dead keys > "Rok Mandeljc" <rokmandeljc(a)hotmail.com> wrote: > > > I have problems with XFree86 4.3 and wine's keyboard layout detection > > scheme. It seems that wine can't detect dead keys and use alt, therefore my > > previous slovene layout isn't detected anymore. This one loads perfectly, > > although alt-key combinations don't work. > > I'm strongly against fixing problems with new XFree86 4.3.0 this way and > polluting x11drv with lots of similar keyboard layouts. A way to solve > your problem is to use something like this in your XF86Config: > > Option "XkbLayout" "us,si" > Option "XkbOptions" "grp:ctrl_shift_toggle" > > I.e. explicitly add "us" layout as the first language group and use > Ctrl+Shift to switch between base and alternate keyboard layouts. > > -- > Dmitry. > > > > Thanks for help, but that doesn't work for me. If I do Option "XkbLayout" "us,si" my keyboard is properly detected, but dead keys (alt+something) are screwed up both in wine and linux (in both us and si).

April 27, 2003

New plans for wintab work.

by Robert North

Ok, Here are my plans for wintab work. If Aric's pach is considered ready to go into CVS, then I can start working on this in the following areas: Painter support. I beleive there are some problems getting Painter to work with wintab. This is my priority. Additional configuration for wintab. Aric's wintab reqires no configuration. It is only targeted at Intuos tablets. My implementation was to have a zero config default for the intuos2 tablet, similar to Aric's. Config could be provided where necessary to modify how an intuos tablet is seen by wintab, or to allow other tablet types to be used by wintab. I could merge this work into Aric's implementation. This would require significant re-factoring of Aric's data structs to match the more generic data structs I implemented. I may not have too much time to do work for the next 3 weeks, but I'd hope to make some progress on the painter side. Comments/questions welcome. -Rob.

April 27, 2003

Re: Mac OS X and Wine troubles

by Pierre d'Herbemont

On Saturday, April 26, 2003, at 11:24 PM, Vincent Béron wrote: > Le sam 26/04/2003 à 16:16, Pierre d'Herbemont a écrit : >> Hi, >> >> First of all I have a good news :) : Wine is able to build on Mac OS >> X. >> >> We decided not to follow WineHQ cvs version for early build, in order >> not to be so much disturbed by others wine development and not to >> produce bad patches, but don't worry ;) we are (of course!) planing to >> send patches, I hope they would be integrated... >> >> I had never use Wine before so sorry for the basic questions. >> I ran wineinstall, everything goes well until wineinstall attempts to >> launch regedit. Wine goes wrong, it tells me : >> >> Warning: no valid DOS drive found, check your configuration file. >> Warning: could not find wine config [Drive x] entry for current >> working >> directory /Users/steg/Documents/Programmation/wine; starting in >> windows >> directory. >> /Users/steg/Documents/Programmation/wine/miscemu/wine: cannot find >> './programs/regedit/regedit.exe.so' > > Does MacOSX sets $HOME and/or $PWD? > Yes it does... > Also, from when's your base CVS version? Alexandre commited a patch of > mine related to exactly this a few days ago. > We were using the version 20030219 of wine... (see : http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/darwine/wine/) You may have found what was wrong, thanks ;) I am going to send our modification to the wine cvs tree. >> >> For me the problem comes from somewhere in the reading of the file >> ~/.wine/config, which exists and is parsed, but maybe I missed >> something in wine configuration (like a register file or something)? >> Could someone tell we wether I am wrong or not? > > Actually, durin wineinstall, ~/.wine/config is not used. A temporary > config file is created instead. > >> >> Secondly I manage to copy a windows folder to the root '/' of my disk, >> so I can launch an app with the command "wine notepad.exe". > > You may have problems with this as Wine is not a CPU emulator, so it > won't know what to do with the binary code in notepad.exe. > Yeah, but in this case notepad.exe has been built for PowerPC, so it shouldn't be a problem... >> I added a >> basic Mach-O (Mac OS X binary file format) compatibility to libwine in >> order the file type to be recognized. But now I am getting error like: >> >> wine: could not load 'C:\windows\regedit.exe': dlcompat: dyld: wine >> Undefined symbols: >> _FormatMessageA >> _RegCloseKey >> _RegCreateKeyExA >> _RegDeleteKeyA >> _RegEnumKeyExA >> _RegEnumValueA >> _RegOpenKeyA >> _RegQueryInfoKeyA >> _RegSetValueExA >> >> I suppose that the problem comes from the fact that the dlls are not >> loaded before the notepad.exe, assuming that the problem is still >> related with the ~/.wine/config reading. Do I suppose right? > > Have you installed the Wine libs (dlls) so that wine (or the dynamic > linker) knows where to find them? > I let wineinstall do everything so I assume that they are installed (/usr/local/lib/wine)... Thanks a lot, Pierre

April 27, 2003

Re: cvs hangs

by Ferenc Wagner

Mike Hearn <mike(a)theoretic.com> writes: > Try altering the compression level used with -z, iirc > there is a bug in CVS (some versions) where it'll have the > symptoms you describe when using compression Thanks for the suggestion. Basically, it hangs for every values of -z except 0. Seems like my client has trouble with the new server when compression is enabled. I will upgrade some time or other. Feri.

April 27, 2003

winevdm changes break non-Linux platforms

by Gerald Pfeifer

I'm sorry to bother you, but the following change Moved the functionality of starting Win16 and DOS programs from the common process startup into a separate winevdm application. breaks non-Linux (actually "non-MZ" platforms as far as I can tell): /sw/test/wine/dlls/winedos% make /sw/gcc-3.2.2/bin/gcc -shared -Wl,-Bsymbolic,-z,defs winedos.spec.o devices.o dma.o dosaspi.o dosconf.o dosvm.o fpu.o himem.o int09.o int10.o int11.o int12.o int13.o int15.o int16.o int17.o int19.o int1a.o int20.o int21.o int25.o int26.o int29.o int2a.o int2f.o int31.o int33.o int41.o int4b.o int5c.o int67.o interrupts.o ioports.o module.o relay.o soundblaster.o vga.o xms.o winedos.dll.dbg.o -o winedos.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lm -lc winedos.spec.o: In function `__wine_spec_exports_funcs': winedos.spec.o(.data+0x40): undefined reference to `wine_load_dos_exe' winedos.spec.o: In function `__wine_spec_exp_ordinals': winedos.spec.o(.data+0xd8): undefined reference to `wine_load_dos_exe' winedos.spec.o(.data+0xd1): undefined reference to `wine_load_dos_exe' collect2: ld returned 1 exit status *** Error code 1 Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 27, 2003 12:47 am, Francois Gouget wrote: > Only as far as commercial companies are concerned. Under the GPL > license, anyone can fork QT. And you think this is any way acceptable? I am sorry, but an OS that puts commercial development at such a tremendous disadvantage (that is, subject to the monopolistic whims of one company) is not a platform. So all the portability issues you listed don't even start to apply. > So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT > and instead develop using Win32+OLE+COM? No! Unfortunately, KDE/QT is in a difficult situation due to the licensing problem. It is the desktop of choice for most people, I use it, but I can't see what we can do about it. > I'm not criticizing, I'm trying > to clarify because in one of your previous email I had the impression > that you advocated development against a Win32-based Gtk API. Gtk is already ported to Win32. App wouldn't even know what Gdk backend is used, they would be just the same. > What about graphical applications? In the Windows world most > applications don't use Win32 directly for the GUI. Should we provide an > LGPL implementation of MFC? Implement a replacement for Visual Basic? A > binary compatible one? I am mainly referring to graphical apps. And no, commercial apps provide their own framework just like they do now. It'd be nice to have efforts toward a free MFC implementation, but it's besides the point. It's an orthogonal issue. > What API would open-source developpers use for WIDE applications? They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot of free apps (see the top SF downloads for examples) that use the Win32 API, so it's not something new I'm suggesting? Do you think it's more moral/ethical to treat these apps as second class citizens in Linux? > Yes it would be very cool. I am far from being an expert on OLE/DCOM but > I have been told that it may be feasible. Probably a heck of a lot of > work though. I'm not saying it would be easy. But given that Bonobo was so deeply inspired by OLE, I'm hoping it can map easily onto an OLE backend, and maybe that leads to an easier path to integration. > But AFAICS what's needed is much smaller in scope from what you propose > with WIDE. Hm, it seems I have problems communicating. In fact, it seems to me we have most of the pieces for Wide already. > Other questions so I better understand: > * are you proposing source-level compatibility or binary level > compatibility? Both. We get both with Wine, we should be able to keep that. > * if it is source level, does it mean modifying gcc to support the > Visual C++ COM extensions? It would be nice to have gcc support for those, but this is independent of the Wide effort. Just like we have support for other stuff that was added through the MinGW project. > * how do you propose to handle the issue of drive letters? What we do in Wine is just fine. I'm only concerned with GUI apps, and there I see drive letters as just shorthands to a bunch of dirs. If you like that, go nuts. I see it as mainly a UI thing, other than that we'd try to pass Unix paths around as much as possible. -- Dimi.

April 27, 2003

Re: commctrl: fix indentation

by Dimitrie O. Paun

On April 27, 2003 12:50 am, Francois Gouget wrote: > I noticed the resulting file still uses a mixture of spaces and tabs for > alignment. Maybe some tabs escaped? Tabs really shouldn't be used unless > they are at the beginning of a line. I don't care about tabs vs. spaces. For me a tab is 8 spaces, and that's good enough. This patch is meant to align things so they look nice. If people feel spaces should be used instead of tabs, that's the subject of another patch. :) -- Dimi.

April 27, 2003

X11DRV_DIB_CreateDIBSection

by Robert Lunnon

Under Solaris I have a problem with this function.which appears to protect a section of the DIB giving a portion of it no access at all and when the application tries to blit from it later, a segfault results. Anyone had any similar experiences/know of this problem ? The offending application was little fighter II ntdll.dll.so`VIRTUAL_SetProt() ntdll.dll.so`VirtualProtectEx+0x27() ntdll.dll.so`VirtualProtect+0x23() x11drv.dll.so`X11DRV_DIB_DoProtectDIBSection+0x43() x11drv.dll.so`X11DRV_DIB_CreateDIBSection+0x32d() gdi32.dll.so`DIB_CreateDIBSection+0x4b() ddraw.dll.so`create_dib+0x14e() ddraw.dll.so`DIB_DirectDrawSurface_Construct+0xe3(dd5c2da0, dd5c16c8, dd532648) ddraw.dll.so`DIB_DirectDrawSurface_Create+0x6c() ddraw.dll.so`Main_create_offscreen+0x42() ddraw.dll.so`create_offscreen+0x105() ddraw.dll.so`Main_DirectDraw_CreateSurface+0xed() ddraw.dll.so`IDirectDrawImpl_CreateSurface+0x2f() 0x439a00()

April 27, 2003

Re: commctrl: fix indentation

by Francois Gouget

On Sat, 26 Apr 2003, Dimitrie O. Paun wrote: > > ChangeLog > Indentation fixes. I noticed the resulting file still uses a mixture of spaces and tabs for alignment. Maybe some tabs escaped? Tabs really shouldn't be used unless they are at the beginning of a line. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Francois Gouget

April 27, 2003

Re: wine/ scheduler/process.c programs/Makefile.in ...

by Dimitrie O. Paun

On April 26, 2003 08:47 pm, Alexandre Julliard wrote: > Moved the functionality of starting Win16 and DOS programs from the > common process startup into a separate winevdm application. Wow -- very nice! It almost makes miscemu/main.c wanna move to something like programs/wine ;) This is very cool, the source starts to look better and better every day. Thanks! -- Dimi.

April 27, 2003

Re: slovene keyboard without dead keys

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > At some point we will have no choice but to add support in Wine to this. > I am not a major hurt party, as my layout is going to be us,il even > without the Wine problem, but this is causing people grief. This gets > worse through the fact that the new X behaviour is actually a better > one. We are now officially holding people back from moving a behaviour > that is better for them. I don't see why explicitly adding a "us" keyboard layout would hurt people, since before 4.3.0 release en_US was a mandatory layout existing whether the user wanted it or not. > I would volunteer to do it, except I'm unusually busy of late. I know > that you have messed around with the keyboard code at some time. If you > have time, I recommend you look at it. Actually I have a plan to implement support for keyboard layout Win32 APIs and that anyway requires rewrite of big chunks of the existing keyboard code in x11drv, and as a part of that rewrite I'm going to decouple all existing keyboard layout tables with a US English one and build new tables with LCID and a layout id, but so far I don't know how to support several layouts for single locale but with different code pages (for instance for Russian locale we need to support 20866 (KOI8-R) and 1251 code pages). -- Dmitry.

April 27, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 25, 2003 04:53 pm, Francois Gouget wrote: > > So, can someone please tell me a *single* advantage of having KDE & QT > > as the GUI platform for Linux vs. having WIDE? > > I mentioned many but you seem to be conveniently ignoring them. No, I'm not ignoring anything. You referred to KDE/QT/GNOME/GTK, I argued precisely against KDE/QT. Once again, I think it is unacceptable to have our _platform_ (not apps) covered by the GPL. It sets an uneven playing field. I'll ask again: is this the kind of free OS we want to build? Yes, QT is licensed under QPL as well -- go rea

April 27, 2003

Re: Mac OS X and Wine troubles

by Steven Edwards

Pierre d'Herbemont wrote: > First of all I have a good news :) : Wine is able to build on Mac OS X. > > We decided not to follow WineHQ cvs version for early build, in order > not to be so much disturbed by others wine development and not to > produce bad patches, but don't worry ;) we are (of course!) planing to > send patches, I hope they would be integrated... > > If you have any idea of what could be wrong, or just a thought drop me > a line, it could be very useful :) > Without seeing your changes it is going to be almost impossible for the people here to help you.

April 26, 2003