September 2002 - Wine-devel

Printing with CUPS
by Mason Kidd 27 Sep '02

27 Sep '02

I'm having trouble printing using CUPS. When I try and print in notepad I get a dialog saying: Cannot print the Untitled file. Be sure that your printer is connected properly and use Control Panel to verify that the printer is configured properly. My setup is Redhat 7.3 with the following CUPS packages: cups-libs-1.1.14-15 cups-drivers-hpijs-1.1-0.20020313.3 cups-devel-1.1.14-15 cups-drivers-pnm2ppa-1.1-0.20020313.3 cups-1.1.14-15 cups-drivers-1.1-0.20020313.3 I am printing to a HP Laserjet 1100 using the "HP LaserJet 1100, Foomatic + gimp-print" driver. This is setup to print using IPP to a print server that is also running CUPS(same version). I have not modified any of the printing or fonts options in the wine config file, since the instructions say it is automatic. I am printing from Notepad. Doing a trace of the PSDRV, it reads all of the AFM files and detects the fonts ok. Also, during ParsePPD it finds all of the paper sizes correctly. But then I get a message: trace:psdrv:PSDRV_FindPrinterInfo No 'Paper Size' for printer 'hplj1100' trace:psdrv:PSDRV_FindPrinterInfo No 'FontSubTable' for printer 'hplj1100' And then when it tries to print: trace:psdrv:PSDRV_CreateDC (WINEPS hplj1100 LPT1: (nil)) trace:psdrv:PSDRV_UpdateDevCaps ImageableArea = 0,0 - 0,0: PageSize = 0x0 trace:psdrv:PSDRV_UpdateDevCaps devcaps: horzSize = -2147483648mm, vertSize = -2147483648mm, horzRes = 0, vertRes = 0 Which doesn't seem right. It then selects the pen and brush, and looks like it will print, and the it calls DeleteDC. I have attached the full trace, with +psdrv and +commdlg. It really seems like it is almost working, but something is wrong with the paper size. How can I find why it sets everything up and then deletes the DC? Anyone have any ideas? Mason Kidd

1 0

Re: dx8 submission
by Sylvain Petreolle 27 Sep '02

27 Sep '02

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

4 6

interprocess messages
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

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.

2 1

How to tell winemaker and winebuild what I want to tell it
by Bill Medland 27 Sep '02

27 Sep '02

Anyone able to tell me what I am doing wrong here before I spend days trying to figure it out? My winelib wrapper wants to call MultiByteToWideChar and DOSFS_GetFullName. As far as I am aware they are available from ntdll.dll (ntdll.dll.so) So I want to to get the build to "link" to ntdll.dll I thought it should simply require "-intdll" in the argument to winemaker, but during the link I still get complaints about not finding those two functions. What am I doing wrong? Bill p.s. Thanks to Francois for the fixes to Winemaker

2 5

patch to MZ_Exec() PE executables
by chrismorgan＠rcn.com 27 Sep '02

27 Sep '02

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 */

1 0

InitThreadInput16
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

OK, This DLL stuff is a bit confusing. In dlls/user/user32.spec we have 409 pascal16 InitThreadInput(word word) InitThreadInput16 so the exported name is InitThreadInput, right? Then how come in ./dlls/x11drv/desktop.c we call it like so: win->hmemTaskQ = InitThreadInput16( 0, 0 ); Shouldn't this yield an error? -- Dimi.

2 5

WM_STYLECHANG{ING/ED}
by Dimitrie O. Paun 27 Sep '02

27 Sep '02

Hi folks, In my relentless quest for speed :), I discovered that we don't send a WM_STYLECHANGED message when we flip the WS_VISIBLE, or WS_VSCROLL, and maybe a bunch of others, I haven't checked. Shouldn't we send such a message, when we touch *any* WS_[EX_]* bits? -- Dimi.

2 3

-gstabs and '#warning "8 as alignment is not supported"'
by Greg Turner 27 Sep '02

27 Sep '02

OK, I did this: Index: configure =================================================================== RCS file: /home/wine/wine/configure,v retrieving revision 1.341 diff -u -r1.341 configure --- configure 25 Sep 2002 03:29:55 -0000 1.341 +++ configure 27 Sep 2002 15:20:40 -0000 @@ -1998,7 +1998,7 @@ CFLAGS=$ac_save_CFLAGS elif test $ac_cv_prog_cc_g = yes; then if test "$GCC" = yes; then - CFLAGS="-g -O2" + CFLAGS="-gstabs -O2" else CFLAGS="-g" fi and sure enough, debug symbols loaded for me. The only remaining annoyance: winedbg doesn't automagically find the sources like gdb. Presumably, I can fix this by issuing "dir" commands to winedbg. So I'm happy (although it'd be nice to not have to issue those "dir" commands). Thanks! Can anyone think of a reason not to submit this as a patch? I tried -gstabs in gcc 2.96 (the only other gcc readily available to me) and it was happy, so presumably its pretty portable, and it looks like the configure change above would only apply to gcc, which seems like precisely the right thing to me. Now one other question for y'all wine gurus out there: I was looking for the alignment issue I mentioned before, and it turns out not to be an "-malign=" problem like I was suspecting. Instead, I was seeing "8 as alignment is not supported" warnings from include/pshpack8.h: # if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) || defined(_MSC_VER) # pragma pack(8) # warning "8 as alignment is not supported" # elif !defined(RC_INVOKED) # error "Adjusting the alignment is not supported with this compiler" # endif I don't understand, if the alignment isn't supported, why the #pragma pack(8) is there...? Anyhow, since it looks like everybody using gcc gets the same warning, it's probably not a gcc3.2 bug... but I was wondering if anyone could clarify what's going on, and whether this indicates a problem in crypt32.dll.so (the affected wine dll). Thanks for your patience and help, -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

1 0

Re: winemaker: wineapploader changes
by Alexandre Julliard 27 Sep '02

27 Sep '02

Francois Gouget <fgouget(a)codeweavers.com> writes: > However, looking for wine in bindir does not make sense: > * I don't install the Winelib applications I compile using Winelib. So > * I leave prefix to the default value: /usr/local > > * I always build my application using a Wine source tree. This means > * that there is strictly nothing of interest in /usr/local/bin. > > * configure.ac goes to great length to figure out where wrc, winebuild > * and *wine* are located. So at the end of configure.ac we know very > * well what the path to wine is. It's '$WINE'. There seems to be some confusion here. We have two very different problems: one is how to make things work on the build machine, and one is how to make things work when installed. configure can only detect where things are on the build machine, but in general that's not the right paths to put in the installed binaries. The installed stuff goes in $(prefix), and I think it makes sense to expect that Wine itself will be installed there too. Note that in Wine wineapploader is only used for make install; running from inside the tree is a different problem and is done by a different script. I think winemaker should do the same thing. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winedbg is not finding debug symbols, anybody know what I'm doing wrong?
by Greg Turner 27 Sep '02

27 Sep '02

Eric POUECH wrote... > but I assume you double checked that more likely, aren't you using gcc 3.2 > by any chance ? if so, you need to force ELF symbol emission, not > Dwarf II which became default in 3.2 Bingo. Guilty as charged. Thank you SO MUCH for this, I should have figured gcc3.2 was the culprit, that thing is feisty! I'll take a look at whether I can find a generic solution to this and post a patch. Now that you mention it, I think gcc3.2 has some other interesting warnings, something about some alignment thingys not supported anymore (probably I just change "-m$X" to "-f$X" to fix), I'll see about those too, could well be important... -gmt -- "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

2 1