September 2002 - Wine-Devel

Re: dx8 submission

by Dimitrie O. Paun

On September 27, 2002 03:19 pm, Ann and Jason Edmeades wrote: > Actually it wasnt as bad as I thought, use the attached patch on top of the > one I've submitted to make it work. Unified diff, pretty please... -- Dimi.

Sept. 27, 2002

patch to MZ_Exec() PE executables

by chrismorgan＠rcn.com

Look reasonable to all of the experts? ;-) dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Add PE support to MZ_Exec(). Index: module.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.21 diff -u -r1.21 module.c --- module.c 30 Aug 2002 00:03:25 -0000 1.21 +++ module.c 27 Sep 2002 18:33:58 -0000 @@ -342,14 +342,54 @@ */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { + DWORD binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + /* this may only be called from existing DOS processes * (i.e. one DOS app spawning another) */ - /* FIXME: do we want to check binary type first, to check - * whether it's a NE/PE executable? */ HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + if(!GetBinaryTypeA(filename, &binType)) /* determine what kind of binary this is */ + { + return FALSE; /* binary is not an executable */ + } + if (hFile == INVALID_HANDLE_VALUE) return FALSE; + + /* handle PE executables */ + if(binType == SCS_32BIT_BINARY) + { + if(func == 0) /* load and execute */ + { + BYTE fullCmdLine[512]; + LPBYTE psp_start = (LPBYTE)((DWORD)DOSVM_psp << 4); + PDB16 *psp = (PDB16 *)psp_start; + ExecBlock *blk = (ExecBlock *)paramblk; + LPBYTE cmdline = PTR_REAL_TO_LIN(SELECTOROF(blk->cmdline),OFFSETOF(blk->cmdline)); + LPBYTE envblock = PTR_REAL_TO_LIN(psp->environment, 0); + + cmdline[strlen(cmdline) - 1] = 0; /* remove the \r at the end */ + cmdline++; /* the first character contains the length of the command line */ + + snprintf(fullCmdLine, sizeof(fullCmdLine), "%s %s", filename, cmdline); /* build the full command line */ + + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, fullCmdLine, NULL, NULL, TRUE, + 0, envblock, NULL, &st, &pe); + return TRUE; + } else + { + FIXME("EXEC type of %d not implemented for PE executables\n", func); + return FALSE; + } + } /* if(binType == SCS_32BIT_BINARY) */ + + /* handle dos executables */ switch (func) { case 0: /* load and execute */ case 1: /* load but don't execute */

Sept. 27, 2002

Re: dlls/ completion nit

by Michael Stefaniuc

On Fri, Sep 27, 2002 at 02:55:45PM -0400, Dimitrie O. Paun wrote: > You'll probably think I'm crazy, but here it goes :) : Nah, we think only you have to much spare time :) > I work a *lot* from the the command line, and I depend quite > a bit on completion. Problem is, all those xxx.dll.so links > in dlls/ are screwing with it sometimes, as is the case for > avifile.dll.so, etc. Even when the dir name is a proper > prefix of the link, it's still annoying as I don't get the / > completed automatically, then I hesitate whether to add > it or not, and so on. > > So my small proposal: what about creating them in a sub dir, > say dlls/lib or something like that? I'd be willing to cook up > a patch, if people are OK with the idea. ;) I would like it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Sept. 27, 2002

RE: dx8 submission

by Ann and Jason Edmeades

>> wine_gl.h: No such file or directory >> wine_gl.h was first included from d3d8_private.h:9 >> d3d8_private.h was first included from d3d8_main.c:25 >> >> Where could I find this file ? I have latest CVS and didn't find it. > >Alexandre removed it yesterday in his 'tsx11' commits :-) > Actually it wasnt as bad as I thought, use the attached patch on top of the one I've submitted to make it work.

Sept. 27, 2002

RE: dx8 submission

by Ann and Jason Edmeades

>> wine_gl.h: No such file or directory >> wine_gl.h was first included from d3d8_private.h:9 >> d3d8_private.h was first included from d3d8_main.c:25 >> >> Where could I find this file ? I have latest CVS and didn't find it. > >Alexandre removed it yesterday in his 'tsx11' commits :-) Now I knew I'd break someone, just not that quickly! And to think I refreshed my cvs not long before then as well... Browsing the cvs tree it looks like the contents of that file were moved inline into ddraw/mesa_private.h, and the locks dynamically loaded at startup which would be d3d8_main.c, so I guess do the same and see what happens.: Alexander - do you want me to resubmit or can you do the same changes as you did to ddraw? Jason

Sept. 27, 2002

interprocess messages

by Dimitrie O. Paun

Hi folks, As I was browsing aimlessly (not quite, but for the purpose of the story, it'll do :)) through windows/win.c, I run into this: /******************************************************************* * GetWindowTextW (USER32.@) */ INT WINAPI GetWindowTextW( HWND hwnd, LPWSTR lpString, INT nMaxCount ) { if (WIN_IsCurrentProcess( hwnd )) return (INT)SendMessageW( hwnd, WM_GETTEXT, nMaxCount, (LPARAM)lpString ); /* when window belongs to other process, don't send a message */ if (nMaxCount <= 0) return 0; get_server_window_text( hwnd, lpString, nMaxCount ); return strlenW(lpString); } My question is: shouldn't we alwas call WM_GETTEXT here, and do the switch between current process/other process in the lower levels? What if the application sends the WM_GETTEXT message, and bypasses the GetWindowTextW? Then it wouldn't work, right? Just curious how all these are gonna play out... -- Dimi.

Sept. 27, 2002

Re: dx8 submission

by Lionel Ulmer

> wine_gl.h: No such file or directory > wine_gl.h was first included from d3d8_private.h:9 > d3d8_private.h was first included from d3d8_main.c:25 > > Where could I find this file ? I have latest CVS and didn't find it. Alexandre removed it yesterday in his 'tsx11' commits :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 27, 2002

dlls/ completion nit

by Dimitrie O. Paun

Hi guys, You'll probably think I'm crazy, but here it goes :) : I work a *lot* from the the command line, and I depend quite a bit on completion. Problem is, all those xxx.dll.so links in dlls/ are screwing with it sometimes, as is the case for avifile.dll.so, etc. Even when the dir name is a proper prefix of the link, it's still annoying as I don't get the / completed automatically, then I hesitate whether to add it or not, and so on. So my small proposal: what about creating them in a sub dir, say dlls/lib or something like that? I'd be willing to cook up a patch, if people are OK with the idea. ;) -- Dimi.

Sept. 27, 2002

Re: dx8 submission

by Sylvain Petreolle

Hi Jason, I tried to compile your directx8 code.(try 3) For now it doesn't compile, complaining about wine_gl.h. Relevant part of 'make depend' log : make[2]: Entre dans le répertoire `/home/wine/dlls/d3d8' ../../tools/makedep -I. -I. -I../../include -I../../include -C. d3d8_main.c directx.c device.c resource.c vertexbuffer.c indexbuffer.c volume.c swapchain.c surface.c basetexture.c texture.c cubetexture.c volumetexture.c wine_gl.h: No such file or directory wine_gl.h was first included from d3d8_private.h:9 d3d8_private.h was first included from d3d8_main.c:25 Where could I find this file ? I have latest CVS and didn't find it. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Sept. 27, 2002

Re: How to tell winemaker and winebuild what I want to tell it

by Bill Medland

----- Original Message ----- From: "Alexandre Julliard" <julliard(a)winehq.com> To: "Bill Medland" <billmedland(a)look.ca> Cc: "wine-devel" <wine-devel(a)winehq.org> Sent: Friday, September 27, 2002 9:56 AM Subject: Re: How to tell winemaker and winebuild what I want to tell it > "Bill Medland" <billmedland(a)look.ca> writes: > > > So I guess I am doing something dangerous in adding -lntdll.dll to the link > > (which does the trick very nicely). > > Yes, this is asking for trouble. It happens to work now but this will > likely change in the near future. Agreed. (I suddenly realised it only works because there is the libntdll.dll.so link and I don't even know if that is just lying around from the past). And of course wine_get_unix_file_name obviates the need for the MultiByteToWideChar. A propos. Why is wine_get_unix_file_name nice and exposed (e.g. it is in winbase.h) yet the wine_dlopen etc aren't? Are there any other useful wine_* functions that are particularly useful and ought to be mentioned in the winelib manual? Bill

Sept. 27, 2002