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

Re: help me with WIN95 value of version16()
by Gerard Patel Aug. 27, 2001

Aug. 27, 2001

At 08:34 PM 26/08/2001 -0700, you wrote: >> The return value of GetVersion16() for win95 changed recently from 0x5f03 to >> 0x304 in misc/version.c (patch 1.43 -> 1.44). The version of "real" win95 I use >> (Czech, win95 2nd ed) gives 0x5f03 while "wine --winver win95" gives 0x304. >> As I do not have the US version of win95 I am not able to determine the right >> value. > > I would like to help you and I have a Win95 system around. But I >don't have a Win16 compiler as these things are getting quite rare. I can compile and run 16 bits apps, on win3.1 if needed (it's a pain because it's old hardware I hardly use otherwise) GetVersion 16 bits must be a special case, returns 3.95, while 32 bits apps get 4.00 Gerard

2 1

propably simple
by Ibrahim Hamouda Aug. 27, 2001

Aug. 27, 2001

I'm sorry for posting to the developers group, although I'm not one. I just have a simple question and the other news group is not helping. for three days now I'm trying to get an application connects to a MSSQL database on a windows box. I'm running the following: Mandrake 8.0 wine 20010731 windows 98 partition and sql server is installed on it My application is built in Powerbuilder 6.0. it comes up with the user name and password box which should be authenticated through the database. when I submit the user name and password I get the following error: [Microsoft][ODBC SQL SERVER DRIVER][TCP?IP SOCKET]General network error on the linux box I've already setup the MSSQL alias in the client connectivity utility of the sql server. I just want to know if I'm configuring the native and builtin wrong in my conf file or what I'm trying to do is not doable at all. I'll appreciate an answer so I can get some sleep, I'm literaly working on that for three days. Ibrahim Hamouda Internode Networks

2 1

keyboard problem
by Stefan Leichter Aug. 27, 2001

Aug. 27, 2001

Hello all, after a long time of debugging (because of my little experience with windows programing and debugging), i found the problem that breaks the keyboard input of my favorite game "You Don't Know Jack" (demos of newer versions downloadable at http://www.take2.de/downloads/demos.php) The problem is that the game is waiting for keyboard input by checking for the messages WM_KEYDOWN, WM_CHAR and WM_KEYUP at least for the keys 1-0 and a-z. But wine generates the messages WM_SYSKEYDOWN, WM_SYSCHAR? and WM_SYSKEYUP. The problem is in the file "windows/message.c" in the methode "process_raw_keyboard_message" in the line 383: if (msg->message < WM_SYSKEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; For some reason i do not understand the message becomes changed. If i remove this line the game recognize the keyboard input and is playable (somehow). An other option(untested) for the game is to change the line to something like this: if (msg->message < WM_KEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; Does anyone know why the message becomes changed? Or does anyone know a better fix for the problem? Is there a program the need the line as it is? Tschüß Stefan PS: I am not subscriped to this mailing list, but i'm reading the newsgroup wine.devel. So it will take some time to see my answers to your questions in the mailing list

3 3

Re: keyboard problem
by Gerard Patel Aug. 27, 2001

Aug. 27, 2001

At 05:49 PM 26/08/2001 -0700, you (Daniel Sabo) wrote: <snip> >As far as i can see the function is ok, maybe GetFocus is bugged? > >static BOOL process_raw_keyboard_message( MSG *msg, ULONG_PTR extra_info ) >{ > if (!(msg->hwnd = GetFocus())) > { > /* Send the message to the active window instead, */ > /* translating messages to their WM_SYS equivalent */ > msg->hwnd = GetActiveWindow(); > if (msg->message < WM_SYSKEYDOWN) msg->message += WM_SYSKEYDOWN - WM_KEYDOWN; > } >... I doubt GetFocus is bugged. What is quite probable is that the focus/active window handling is not behaving like Windows does (if there is really *one* behaviour in the different versions of Windows, that is). Another possibility (less probable in this case) could be that the Ms doc about WM_SYS* messages is inaccurate or incomplete. Gerard

1 0

undefined symbol send
by lawson_whitney＠juno.com Aug. 25, 2001

Aug. 25, 2001

Good day! I just got a new binutils about a year ago (well, maybe it was 2) to keep up with y'all. Is my as dragging again? make[1]: Entering directory `/oof/Wine-20010824/loader/dos' gcc -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boun dary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o dosmod ./dosmod.c /tmp/cc1rBlP7.s: Assembler messages: /tmp/cc1rBlP7.s:1355: Error: undefined symbol send in operation /tmp/cc1rBlP7.s:1355: Error: undefined symbol signal in operation make[1]: *** [dosmod] Error 1 make[1]: Leaving directory `/oof/Wine-20010824/loader/dos' make: *** [loader/dos/dosmod] Error 2 [whit(a)giftie Wine-20010824]$ as --version GNU assembler 2.10.90 Copyright 2000 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i586-mandrake-linux'. Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 1

__ws_select
by Robert Lunnon Aug. 25, 2001

Aug. 25, 2001

I'm trying to hack on wine to get it working properly on Solaris X86. Now that the basic things are working on Solaris, I have run into a problem with networking. The Network apps block on a read operation. Here is a debug trace of ftp for example bash-2.03$ wine ftp -debugmsg +winsock,+thread -managed trace:winsock:WSOCK32_LibMain 0xdf630000 0x1 1 trace:winsock:WSAStartup verReq=101 trace:winsock:WSAStartup succeeded trace:winsock:WSOCK32_getservbyname 'ftp', 'tcp' fixme:console:SetConsoleCtrlHandler (1001dc5,1) - no error checking or testing yet ftp> o ftp.cdrom.com trace:winsock:WSOCK32_gethostbyname ftp.cdrom.com trace:winsock:WSOCK32_socket af=2 type=1 protocol=0 trace:winsock:WSOCK32_socket created 0030 trace:winsock:WSOCK32_bind socket 0030, ptr 1008700, length 16 trace:winsock:WSOCK32_setsockopt socket 0030, lev 65535, opt 0x8, ptr df7666d4, len 4 trace:winsock:WSOCK32_connect socket 0030, ptr 1008700, length 16 trace:winsock:WSOCK32_getsockname socket: 0030, ptr 1008760, ptr 10 Connected to wcarchive.cdrom.com. trace:winsock:__ws_select read df766570, write 0, excp 0 trace:winsock:fd_set_unimport Connection closed by remote host. ftp> Can anyone give me a starting point, I only have basic tcp knowledge Thanks in advance Bob

1 0

ICQ 2000b
by Daniel Walker Aug. 24, 2001

Aug. 24, 2001

ICQ appears to get in some kind of loop. It eventually crashes with a stack overflow, but there are 16000+ lines in the backtrace so .... The sequence below repeats over and over in the backtrace .. Wine did load this application at one time, right? Or has someone seen this before? Daniel Walker 16429 0x406eb4ac (SendMessageA+0x38(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5858) [message.c:1588] in libuser32.so) (ebp=405b57bc) 16430 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b5858) [winpos.c:856] in libx11drv.so) (ebp=405b5840) 16431 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b5874) 16432 0x408f561b (SHAppBarMessage+0x147(msg=0x9, data=0x405b58d0) [shell32_main.c:537] in libshell32.so) (ebp=405b58b4) 16433 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5904) 16434 0x2194c273 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x9d0 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5998) 16435 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b59b8) 16436 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a18) 16437 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a34) 16438 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5a60) 16439 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b5a84) 16440 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b5c4c) [winproc.c:171] in libuser32.so) (ebp=405b5ab0) 16441 0x4074db5e (CallWindowProcA+0x3a(func=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b5c4c) [winproc.c:2656] in libuser32.so) (ebp=405b5ad8) 16442 0x406ea6d6 (call_window_proc+0xc2(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405b5b24) 16443 0x406eb333 (SendMessageTimeoutA+0xcf(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c, flags=0x0, timeout=0xffffffff, res_ptr=0x405b5bac, hwnd=0x2a0) [message.c:1566] in libuser32.so) (ebp=405b5b7c) 16444 0x406eb4ac (SendMessageA+0x38(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b5c4c) [message.c:1588] in libuser32.so) (ebp=405b5bb0) 16445 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b5c4c) [winpos.c:856] in libx11drv.so) (ebp=405b5c34) 16446 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b5c68) 16447 0x408f561b (SHAppBarMessage+0x147(msg=0x9, data=0x405b5cc4) [shell32_main.c:537] in libshell32.so) (ebp=405b5ca8) 16448 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5cf8) 16449 0x2194c273 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x9d0 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b5d8c) 16450 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5dac) 16451 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e0c) 16452 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e28) 16453 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b5e54) 16454 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b5e78) 16455 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b6040) [winproc.c:171] in libuser32.so) (ebp=405b5ea4) 16456 0x4074db5e (CallWindowProcA+0x3a(func=0x5f401b81, hwnd=0x2a0, msg=0x47, wParam=0x0, lParam=0x405b6040) [winproc.c:2656] in libuser32.so) (ebp=405b5ecc) 16457 0x406ea6d6 (call_window_proc+0xc2(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b6040, unicode=0x0) [message.c:1112] in libuser32.so) (ebp=405b5f18) 16458 0x406eb333 (SendMessageTimeoutA+0xcf(hwnd=0x2a0, msg=0x47, wparam=0x0, lparam=0x405b6040, flags=0x0, timeout=0xffffffff, res_ptr=0x405b5fa0, hwnd=0x2a0) [message.c:1566] in libuser32.so) (ebp=405b5f70) [Here is the very begining, this doesn't repeat.] 16460 0x40a7add6 (X11DRV_SetWindowPos+0x632(winpos=0x405b6040) [winpos.c:856] in libx11drv.so) (ebp=405b6028) 16461 0x40747a3c (SetWindowPos+0x50(hwnd=0x2a0, hwndInsertAfter=0x0, x=0x0, y=0x0, cx=0x0, cy=0x0, flags=0x40) [winpos.c:1840] in libuser32.so) (ebp=405b605c) 16462 0x408f561b (SHAppBarMessage+0x147(msg=0x0, data=0x405b60b8) [shell32_main.c:537] in libshell32.so) (ebp=405b609c) 16463 0x2194bca6 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x403 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b60ec) 16464 0x2194c1e9 (ICQCORE.DLL.?AlwaysCheckBounds(a)BCDbListCtrl@@UAE_NXZ+0x946 in C:\PROGRAM FILES\ICQ\ICQCORE.DLL) (ebp=405b6118) 16465 0x5f401f1b (MFC42.DLL.5163+0x20f in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6194) 16466 0x5f401cea (MFC42.DLL.6374+0x22 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b61b4) 16467 0x5f401c73 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6214) 16468 0x5f401bfb (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6230) 16469 0x5f401bba (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b625c) 16470 0x40748037 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405b6280) 16471 0x407480b9 (WINPROC_CallWndProc+0x75(proc=0x5f401b81, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x403b09d4) [winproc.c:171] in libuser32.so) (ebp=405b62ac) 16472 0x4074d76d (WINPROC_CallProc32WTo32A+0x85(func=0x5f401b81, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x403b09d4) [winproc.c:2441] in libuser32.so) (ebp=405b62d4) 16473 0x4074dca7 (CallWindowProcW+0x93(func=0x41030b41, hwnd=0x2a0, msg=0x1, wParam=0x0, lParam=0x405b66b4) [winproc.c:2692] in libuser32.so) (ebp=405b62fc) 16474 0x406ea6b1 (call_window_proc+0x9d(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=405b6348) 16475 0x406eb1f4 (SendMessageTimeoutW+0xc8(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4, flags=0x0, timeout=0xffffffff, res_ptr=0x405b63cc) [message.c:1508] in libuser32.so) (ebp=405b639c) 16476 0x406eb460 (SendMessageW+0x38(hwnd=0x2a0, msg=0x1, wparam=0x0, lparam=0x405b66b4) [message.c:1577] in libuser32.so) (ebp=405b63d0) 16477 0x40a79215 (X11DRV_CreateWindow+0x2dd(hwnd=0x2a0, cs=0x405b66b4, unicode=0x1) [window.c:927] in libx11drv.so) (ebp=405b6418) 16478 0x40741a00 (WIN_CreateWindowEx+0x6d4(cs=0x405b66b4, classAtom=0x8002, type=0x3) [win.c:812] in libuser32.so) (ebp=405b6490) 16479 0x40741fe8 (CreateWindowExW+0x14c(exStyle=0x10080, className=0x8002, windowName=0x21a5e00e, style=0x80cc0044, x=0x0, y=0x0, width=0xad, height=0x10a, parent=0x0, menu=0x0, instance=0x21880000, data=0x0) [win.c:1039] in libuser32.so) (ebp=405b66e4) 16480 0x40723989 (DIALOG_CreateIndirect+0x3ad(hInst=0x21880000, dlgTemplate=0x21a5e034, win32Template=0x1, owner=0x0, dlgProc=0x5f408e75, param=0x0, procType=0x2, modal=0x0) [dialog.c:833] in libuser32.so) (ebp=405b678c) 16481 0x40723dbc (CreateDialogIndirectParamA+0x30(hInst=0x21880000, dlgTemplate=0x21a5dff0, owner=0x0, dlgProc=0x5f408e75, param=0x0) [dialog.c:1006] in libuser32.so) (ebp=405b67c0) 16482 0x5f40a1a1 (MFC42.DLL.2147+0xc9 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6828) 16483 0x5f40a35e (MFC42.DLL.2168+0x27 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6cec) 16484 0x00401555 (Icq.exe..text+0x555 in C:\Program Files\ICQ\Icq.exe) (ebp=405b6e0c) 16485 0x5f40b4f3 (MFC42.DLL.1576+0x47 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=405b6ecc) 16486 0x400d005d (start_process+0x195 [process.c:390] in libntdll.so) (ebp=405b6f30) 16487 0x400d394c (SYSDEPS_DoCallOnStack+0x20(func=0x400cfec8, arg=0x0) [sysdeps.c:183] in libntdll.so) (ebp=405b6ff0) 16488 0x400d39f3 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff89c) 16489 0x400d3aa0 (SYSDEPS_SwitchToThreadStack+0x94(func=0x400cfec8) [sysdeps.c:238] in libntdll.so) (ebp=bffff8d8) 16490 0x400d03ee (PROCESS_InitWine+0x1ca(argc=0x5, argv=0xbffff954, win16_exe_name=0x804c620, win16_exe_file=0x804c724) [process.c:522] in libntdll.so) (ebp=bffff8f0) 16491 0x0804b1e6 (Letext [main.c] in wine) (ebp=bffff908) 16492 0x402789cb (__libc_start_main+0xff(main=0x804b1cc, argc=0x5, argv=0xbffff954, init=0x80486d4, fini=0x804b224, rtld_fini=0x4000ae60, stack_end=0xbffff94c) [libc-start.c:92] in libc.so.6) (ebp=bffff928) 16493 0x08049021 (_start+0x21 in wine) (ebp=00000000)

2 2

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > what about winextract ? Seems a bit too generic, google turns up a number of Windows programs with this name already. I guess we should start a naming contest ;-) Maybe winedump? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

Marcus Meissner <marcus(a)jet.franken.de> writes: > Actually for Caldera I am already putting all non-user called programs > (wineserver,winedbg,wineshelllink, and dosmod) into /usr/lib/wine. At least wineserver and winedbg can legitimately be started directly, so I would leave them in /usr/bin. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > I choose the later because I didn't like to have a dump utility > named specmaker... however, we can go back to the former, and go > for another name ;-) I think that may be better. And a name starting in 'wine' would be better than specmaker anyway, this would make sure we don't conflict with other projects. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Wininet vs. winsock.h
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

Francois Gouget <fgouget(a)free.fr> writes: > I recently discovered that xemacs does colorization of diffs when > they have a .diff extension. So I changed the naming convention for my > patches. Also if you modify '/etc/mime.types' to contain 'text/plain txt > text diff' (soon to be the default in Debian) you can read such files > without problem from within pine. If you could convince pine to not encode your patches in base64 that would be even better. It makes my life easier when I can simply pipe the whole mail into patch, instead of having to decode mime stuff first. In fact unless your mailer mangles white space, simply putting the patch inline is better than as an mime attachment. -- Alexandre Julliard julliard(a)winehq.com

1 0

WSAStartup16
by Francois Gouget Aug. 24, 2001

Aug. 24, 2001

WSAStartup16 seems wrong. As I understand it all the Win16 structures have a 1 byte alignment. Thus the WSASTARTUP structure used by WSAStartup16 should have a 1 byte alignment. But WSAStartup16 uses the Win32 structure! Why is this important? Here's why: - the last field, lpVendorInfo, will be misaligned - the structure will be larger than it should (by 2 bytes). And since we do a memcpy of sizeof(WSADATA) to the pointer provided by the application we could have a buffer overflow - this creates a dependency between winsock16.h and winsock.h which greatly bothers me Or did I miss something? Changelog: * include/wine/winsock16.h, dlls/winsock/socket.c Add WSASTARTUP16 a 1 byte alignment version of WSASTARTUP for win16 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

Re: dumping utility
by Eric Pouech Aug. 24, 2001

Aug. 24, 2001

this can be done of course... I think we could start with a bin hex dumper... if has to be checked whether the x86 disassembler from the debugger could be used here... but a bit of tweaking will be required (like taking care of addresses, how opcodes are read, how output is generated...) OTOH binutils' objdump has greatly evolued and now also includes lots of PE facilities... so I think we'd better focus on pure windows areas (IMO resource dumping is perhaps more needed than the disas feature...) than this one A+ > >>>>> "eric" == eric pouech <eric.pouech(a)wanadoo.fr> writes: > > eric> thanks for your effort. I applied your patch and get the > eric> following: > >> > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > eric> this has to be called with ./pedump -x -d > eric> /dosd/cae/gcprevue/gcprevue.exe as the Usage lines (almost) > eric> mention ;-) > > That looks better with the -d. > > Is pedumper expected to get a disassembler too? > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: dumping utility
by Uwe Bonnes Aug. 24, 2001

Aug. 24, 2001

eric pouech writes: > this is a first shot at the PE-dump utility for wine > since, lots of code could/will be shared with specmaker (PE image file > browsing, symbol demangling...), I decided to turn specmaker into a > multi-mode utility > > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still > need to be written (like resources or typelib information) > Hallo Eric, thanks for your effort. I applied your patch and get the following: > wine/tools/specmaker> ./pedump -x /dosd/cae/gcprevue/gcprevue.exe > Unrecognized option > Usage: > -h Display this help message > -d <dll> Use dll for input file and generate implementation code > -C Turns on symbol demangling > -f Dumps file header information > -j sect_name Dumps only the content of section sect_name (import, export, debug) > -x Dumps everything Do I do something wrong? Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

2 2

Re: dumping utility
by Alexandre Julliard Aug. 24, 2001

Aug. 24, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > the executable made out of the sources in specmaker dir can now be > launched under 3 different names: > - specmaker: you keep all the old features of specmaker (except -S > option) > - winedemangle: this replaces the -S option of specmaker > - pedump: PE (and .DBG) file dumping utility... lots of PE dir dumping > still This seems to duplicate a lot of code that is in cvdump. Are there still things that cvdump does that your pedump doesn't support, or should I remove cvdump completely? Also I'm not convinced we need a separate winedemangle binary, we are already installing a bit too many things in /usr/bin. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: _CheckNotSysLevel()
by Alexandre Julliard Aug. 23, 2001

Aug. 23, 2001

Daniel Walker <diwalker(a)earthlink.net> writes: > It seems Wise installers break inside _CheckNotSysLevel() . I think > every Wise installer I've tried breaks .. The cuteftp package was one of > them .. How about posting a backtrace? -- Alexandre Julliard julliard(a)winehq.com

3 4

Re: ReadFile and other issues
by Alexandre Julliard Aug. 23, 2001

Aug. 23, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > anyway, I'd like to get back to simple vs complex consoles if I got > you right, a simple console handle should be in fact nothing more > than a regular file handle which unix fd is set to either 0 or 1 it > means that no enhanced mode is used, nothing but the standard libc > line editing facilities of the input stream so the use would > adequate for a simple program that just uses equivalent of puts/gets > (and associated) functions Exactly yes. > however, I find this very limiting for people who want to use a CUI > exe in a pure unix console mode (either when X11 isn't started, or a > session done over IP in telnet for example) that's why I was > wondering if wineconsole shouldn't also support a (n)curse like > interface (in addition to the USER32 one) to help in this area Sure, once the architecture is in place we can have different implementations of wineconsole, including curses support. The important thing is that this is in a separate application, so that ReadConsole doesn't need to know about things like xterm escape sequences. > last but not least, recent exchanges made a simple < 1kloc patch a more > serious project of several kloc :-/ I can do the wineserver part if you like. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ReadFile and other issues
by Alexandre Julliard Aug. 23, 2001

Aug. 23, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, the issue here is that, even in line editing mode, ReadConsole > and ReadConsoleInput can be used. the former drops all non keyboard > events and produces a string, whereas the later returns the available > input records... > so, to implement what you propose, the wineconsole would have to know > in advance which one of the two functions will be called next: > - in case of ReadConsole, it has to keep all incoming input records, and > release just the string when it's done editing the line > - in case of ReadConsoleInput, all generated input records must be > available in the server to the calling app OK I see what you mean. Yes this implies that we must be able to tell the server to only return input events to the thread doing the ReadConsole. If I get this right, it also means line editing has to be done in ReadConsole, and that you can't see what you type when the app is not reading. Very annoying, but I guess it's more Windows-like... -- Alexandre Julliard julliard(a)winehq.com

2 1

_CheckNotSysLevel()
by Daniel Walker Aug. 22, 2001

Aug. 22, 2001

It seems Wise installers break inside _CheckNotSysLevel() . I think every Wise installer I've tried breaks .. The cuteftp package was one of them .. Daniel Walker

1 0

Re: ReadFile and other issues
by Alexandre Julliard Aug. 22, 2001

Aug. 22, 2001

eric pouech <eric.pouech(a)wanadoo.fr> writes: > fairly acceptable ;-) except that in line editing mode we need to lock > the input buffer on a single thread (that's the way the queue is > handled, > at least, on NT 2000 - didn't check the others) (the granularity for > getting access to the queue is not the input record, but the line (up to > '\n')) I guess line editing could be done by wineconsole, and the input records would only be sent to the server once we have a complete line. Or do we need more locking than this? > I was thinking of either a anonmymous file or an anonymous mapping for > the content of the screen buffer... with an array attribute and char > may be some additional info on each row to indicate the rendering > program about the rows which have been modified... The problem with a shared buffer is that you need to lock against simultaneous access, which means a hung thread can hang the whole console. I'd prefer to have the server simply report to wineconsole the bounding rect of the screen buffer area that has been modified, and have wineconsole use ReadConsoleOutput to retrieve the buffer contents from the server. It's only a few Kbytes to copy at most so performance should be acceptable. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ReadFile and other issues
by Alexandre Julliard Aug. 22, 2001

Aug. 22, 2001

"Eric Pouech"<eric.pouech(a)voila.fr> writes: > if we want to go into this, there are a few points to agree on first: > - since console handles can be inherited, the Wine console window should > be run in a different process than the one which uses the console (and > add communication means between the first process, and the process > rendering the console) > - how should we know a program needs either a simple or a complex > console (we could use a registry key in the per process area) We need a separate process yes. I was thinking of something like a 'wineconsole' Winelib app. Then if you want to run an app with a separate console you use wineconsole instead of wine to start it. A new wineconsole could also be launched when the app does an AllocConsole, or some other function that requires a complex console. The communication with the console can probably go through the server. Input events can simply be put in the queue by wineconsole using WriteConsoleInput. Output should probably go to a server screen buffer object, which would then signal wineconsole that its contents changed. -- Alexandre Julliard julliard(a)winehq.com

2 1

custom CFLAGS
by mdew Aug. 22, 2001

Aug. 22, 2001

too my previous subject... err:module:map_image Could not map section .data, file probably truncated the problem was my custom CFLAGS, which havent caused me too many problems...till lately ...(using wine) export CFLAGS="-O3 -ffast-math -fthread-jumps -fcse-follow-jumps -mpentiumpro -march=pentiumpro -mcpu=i686 -malign-loops=2" err:module:map_image Could not map section .data, file probably truncated /usr/local/bin/wine: can't exec './xxx.exe': error=21 gcc 2.95.4-6 (Debian Sid) I havent tried gcc-3.0.1 yet, i trust gcc-2.95.4 still...give it another few versions before i'll look at gcc3. in paticular is the use of -O3 over -O2, -O2 will work, -O3 will fail..why is that? -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

2 3

Re: ReadFile and other issues
by Eric Pouech Aug. 22, 2001

Aug. 22, 2001

> I'm not sure we should be converting xterm input into INPUT_RECORD. It > may be better to have two modes, a simple console that returns an fd > to ReadFile and no input records (and then ReadConsoleInput could > generate them on the fly if necessary), and a complex console that > supports all the features but that doesn't have an associated fd at > all. > > IMO the current xterm-based console support is a ugly hack; we should > do a proper Windows console using a normal Wine window with a message > loop to retrieve input events. And usage of stdin/stdout should be > limited to programs that don't need special console features, and > should only support ReadFile/WriteFile. if we want to go into this, there are a few points to agree on first: - since console handles can be inherited, the Wine console window should be run in a different process than the one which uses the console (and add communication means between the first process, and the process rendering the console) - how should we know a program needs either a simple or a complex console (we could use a registry key in the per process area) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: (no subject)
by Alexandre Julliard Aug. 21, 2001

Aug. 21, 2001

Mike McCormack <mike_mccormack(a)start.com.au> writes: > How about returning a function pointer instead of an id? > > When the file handle is registered with the wine-server, we would also > send function pointers for the read and write operations. This way we > could have seperate implementations of ReadFile or WriteFile for > different types of handles... You can't do that. The ReadFile can be done from another process, and the pointer won't be valid there. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Mike McCormack Aug. 21, 2001

Aug. 21, 2001

Hi Eric, How about returning a function pointer instead of an id? When the file handle is registered with the wine-server, we would also send function pointers for the read and write operations. This way we could have seperate implementations of ReadFile or WriteFile for different types of handles... Mike > - extend the get_handle_fd to also return an id corresponding > to the type fd being used. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0