wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

TCP/IP networking and registry keys
by Alan Chandler 06 Mar '01

06 Mar '01

I spent most of the weekend trying to get Grand Prix Legends GPL to work. I achieved my first goal of getting it to run in server mode. One of the things I needed to get the game to do, was to recognise that there where some interfaces it could talk TCP/IP out of. It took me some time to realise that under windows it was doing this by looking for the key [System\\CurrentControlSet\\Services\\Class\\NetTrans] and was then enumerating the keys under it to establish an IP address ie the following [System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000] "IPAddress"="10.0.10.100" The thought occurred to me that maybe the tool the builds the registry during wine install could actually create these keys - since it is essentially a key part of the system (and other similar keys are also built in the same way). I don't think I have the skills to do it myself yet. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

3 2

Wine Press
by Eric Pouech 05 Mar '01

05 Mar '01

http://linux.cnet.com/linux/0-2136864-7-4961586.html worth the reading, even if Wine gets the lowest ranking my reading of it is that Wine is not yet a product (compared to the two others). I definitively think we should focus more on a release target. It of course means that we have to make choices (do not include some functionnalities), spend pretty much more time on testing... but that's the way to go if we want to have Wine 1.0 around on of these days A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

3 2

Re: RESUBMIT: afm
by Gavriel State 05 Mar '01

05 Mar '01

Back in Febuary, Marcus Meissner wrote: > > Changelog: > fixed one NULL ptr problem > added loading of .afm files from several common locations > (ghostscript, a2ps, enscript, (teTeX), X11) > > Index: afm.c > =================================================================== > RCS file: /home/wine/wine/dlls/wineps/afm.c,v > retrieving revision 1.4 > diff -u -r1.4 afm.c > --- afm.c 2001/01/02 20:30:16 1.4 > +++ afm.c 2001/02/03 18:50:42 > BOOL PSDRV_GetFontMetrics(void) > { > int idx = 0; > char key[256]; > char value[256]; > + char *path; > + DIR *dir; > + > + /* some packages with afm files in that directory */ > + PSDRV_ReadAFMDir("/usr/share/ghostscript/fonts/"); > + PSDRV_ReadAFMDir("/usr/share/a2ps/afm/"); > + PSDRV_ReadAFMDir("/usr/share/enscript/"); > + PSDRV_ReadAFMDir("/usr/X11R6/lib/X11/fonts/Type1/"); We just did an integration with WineHQ, and this code has started to grate on me (mostly because of the fact that the AFM parser spits out a bunch of error messages while trying to parse my AFM files. Rather than hardcoding the paths into the code, could we do this instead: while (PROFILE_EnumWineIniString( "afmdirs", idx++, key, sizeof(key), value, sizeof(value))) PSDRV_ReadAFMDir(value); This has the added benefit of allowing the user to specify only those AFM directories that their rasterizer knows about too. With the above, I get a whole bunch of printer fonts listed as available in wine that I can't actually print if Ghostscript isn't configured to find the font files. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

1 0

[RESEND] Re: faster 8bpp to 24 bit depth conversion in SetImageBits_8
by Vedran Rodic 04 Mar '01

04 Mar '01

On Sun, Mar 04, 2001 at 01:51:16PM +0100, Ove Kaaven wrote: > > > Since this is a 32-bit move (movl), you should use %%eax, not %%ax. The > assembler doesn't complain about this now, but technically it should, and > might someday. > > Since you're converting to 32bpp, not 16bpp, you should multiply "left" by > 4, not by 2, or strange things may happen in some apps. Thanks. Fixed patch attached. I did change left multiplicator from 2 to 4 in my earlier patches, but I forgot to include it in my final patch being 3 AM and so... I'll try to be more careful next time. Vedran

1 1

Re: for loop fixes
by Francois Gouget 04 Mar '01

04 Mar '01

On Sat, 3 Mar 2001, Andreas Mohr wrote: [...] > - changed all terminating ";" of isolated for loops to " ;" to indicate the > loop's isolation. IMHO, for such loops the following would be much clearer: <init_expression>; while (<test_condition>) { <update_expression>; } (ok, you can also put '{' on the next line) > Please do the same for these for loops in the future. ??? > Somebody might want to write a Wine coding guidelines article... $ wg . -E 'for *$' | grep -E '$ *; *$'` | wc -l 96 (wg is my recursive source grep script) Maybe we should ask people to put the for and the instruction it applies to on separate lines. Combined with the suggestion above this would make it easier to check for this kind of bug. > P.S.: I just *knew* that at least one other for loop in Wine would be wrong, > too ;-) Yep, I should have done that myself (if you find a generic bug, always check for other similar bugs). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

4 4

RFC: client side implementation of async I/O
by Michael McCormack 04 Mar '01

04 Mar '01

Hi all, This patch moves responsibility for asynchronous I/O to the client process. i'm posting it to wine-devel because i want to know what other developers here think about the technique i've used to make this work... i've relaxed some of the assumptions wineserver makes about client processes. i think this implementation is more efficient, as it makes fewer server calls and duplicates fewer file descriptors, while maintaining correctness. Mike -- __________________________________________________________________ mailto:Michael.McCormack@alcatel.com.au phone: (+8232) 667 0425 (h) (+8211) 430 0425 (m)

1 0

Re: Add explicit WM_CLOSE processing in the edit control
by Alexandre Julliard 04 Mar '01

04 Mar '01

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Since handler of WM_CLOSE in DefWindowProc calls DestroyWindow, > which eventually sends WM_DESTROY, EDITSTATE gets destroyed before > call to EDIT_UnlockBuffer in the end of processing of WM_CLOSE, > therefore EDIT_UnlockBuffer gets confused. This is not specific to WM_CLOSE, it can happen with other messages too; any time we transfer control back to the application the window can be destroyed. I think it would be better to either unlock the buffer before calling DefWindowProc, or make EDIT_UnlockBuffer cope with a destroyed window. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: erase bkgnd on page scroller control
by Alexandre Julliard 04 Mar '01

04 Mar '01

Susan Farley <susan(a)codeweavers.com> writes: > @@ -720,7 +721,8 @@ > PAGER_INFO *infoPtr; > DWORD dwStyle = GetWindowLongA (hwnd, GWL_STYLE); > > - dwStyle |= WS_CLIPCHILDREN; > + /* background color of the child should be the same as the pager */ > + dwStyle &= ~WS_CLIPCHILDREN; Shouldn't we simply leave WS_CLIPCHILDREN alone and use whatever the app specified when creating the window, instead of forcing it one way or another? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: ListView fix
by François Gouget 03 Mar '01

03 Mar '01

Ok, so now that I've got the patch out, there's a weird problem that I've been having with this piece of code. Apply the following on top of my previous patch and you'll get the weirdest traces: --- cut here --- Index: dlls/comctl32/listview.c =================================================================== RCS file: /home/cvs/wine/wine/dlls/comctl32/listview.c,v retrieving revision 1.99 diff -u -r1.99 listview.c --- dlls/comctl32/listview.c 2001/02/28 05:31:02 1.99 +++ dlls/comctl32/listview.c 2001/03/02 23:45:09 @@ -1542,10 +1545,22 @@ item.stateMask = LVIS_SELECTED; item.state = LVIS_SELECTED; + TRACE("nSelectionMark=%d nItem=%d nFirst=%d nLast=%d\n",infoPtr->nSelectionMark,nItem,nFirst,nLast); +#if 0 + i = nFirst; + while (i <= nLast) + { + TRACE("i=%d\n",i); + LISTVIEW_SetItemState(hwnd,i,&item); + i++; + } +#else for (i = nFirst; i <= nLast; i++); { + TRACE("i=%d\n",i); LISTVIEW_SetItemState(hwnd,i,&item); } +#endif LISTVIEW_SetItemFocus(hwnd, nItem); infoPtr->nSelectionMark = nItem; --- cut here --- Now if I click on item 3 I get the following trace: ... trace:listview:LISTVIEW_AddGroupSelection nSelectionMark=-1 nItem=3 nFirst=3 nLast=3 trace:listview:LISTVIEW_AddGroupSelection i=4 trace:listview:LISTVIEW_WindowProc hwnd=1908 uMsg=1006 wParam=0 lParam=405b6c30 trace:listview:LISTVIEW_AddSelectionRange Add range 4 - 4 ... Now, last I checked (i.e. a few minutes a go), 'for (i=3;i<=3;i++) printf("%d\n",i);' prints 3 and certainly not 4. Also, if I'm not mistaken this code is strictly equivalent to the while loop in the '#if 0' branch. Yet the while loop works fine but not the for loop. In a word this looks like a gcc bug to me! $ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 20000220 (Debian GNU/Linux) How do we normally deal with those? -- François Gouget fgouget(a)codeweavers.com

2 1

WinMM/MMSystem & registry
by Eric Pouech 02 Mar '01

02 Mar '01

I'm currently investigating moving all multimedia setup into the registry as current WINMM/MMSYSTEM implementation is rather close to the WIN3.x/9x model, I started looking at their native implementation. The main goal is to use no longer the hard coded drivers name, but rather get them from the registry basically, it goes like this: /* * The Windows registry settings are as follows: * - the drivers are defined by sets, each set has an index * - the sets are loaded in the set index increasing order * - a set is divided by classes (wave, midi...), and several drivers can be * defined in each class * - the keys are spread into two locations: * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\MEDIA\%idx%\Drivers\%class%\%name% * where %idx% is the set index, * %class% is the class (midi, wave...) * %name% is the name of the device (which can be different from * the actual name of a the driver's filename (even if, * in lots of cases it's the same)) * these keys mainly describe what to load, and in which order * This key shall also contain some configuration options for the driver (if * needed...) * - each entry under the Services\Class has a corresponding entry in another part * of the registry * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaResources\%class%\%namen%<%idx%> * Under this location is stored information regarding how to load the * driver (like if it's enabled, PnP information...) */ there are some other keys (like the PnP devices enumeration) which use the index to refer to the driver implementing this under Wine is not too difficult. The hairy part is the configuration (setting up the keys in the registry) since the first step of the configuration (for this scheme) is to get the first unused index, this can be a bit tricky (especially when a registry exists, and has been copied from a native one) the possible solutions are: A/ implement this mechanism and provide an ad hoc tool for this purpose. The hard part is, in some cases, that the data to add to the registry have to be determined at installation time: the number of DSP available for the wave output, or the list of MIDI playback devices (synthesizer, midi out...) - current WineOSS implementation gets its name from the kernel -. A1/ create a specific (winelib) tool to take care of it A2/ make use of Windows installation capabilities (setup API) and provide a .INF file for each. I'm not quite sure that's feasible with the semantics of the API (mainly for the naming issue described above) B/ do not implement this mechanism B1/ provide a Wine specific easy set of keys B2/ same as above, but upon startup, Wine (or winmm/mmsystem) partially recreates the native keys as needed I'd rather go the A1 or B1. As of today, the only drawback of B1 is that some native DLLs (multimedia control panel, the midi mapper) will not work. I haven't (yet) run against a program using this poorly undocumented set of features (which, of course, will not work on Win2k with WDM in place). any comment is welcome. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

file descriptor problems
by Rein Klazes 02 Mar '01

02 Mar '01

Hi, With today's CVS I get problems with the Agent newsreader after 0.5 to 1 hour of use. Sometimes I get this: > wine client error:0x8063890: no fd received for handle 264 and the wine service tread has exited. In other cases the program shows a message box showing: cannor write <filename>. DOS error 4. and the program goes crazy. Dos error 4 means "too many files open", which seems related to the first message. Rein. -- Rein Klazes rklazes(a)casema.net

1 0

Protocol error
by Andreas Schultz 01 Mar '01

01 Mar '01

Hi, I'm getting repeatable error's with the latest CVS version: Protocol error:0x8066ae0: read : Resource temporarily unavailable The application that is causing is the Gunman Chronicles Dedicated Server. I tried to find out what is going on, but couldn't find anything usefull. Has anybody ales seen a similar behavior? Andreas -- -------------------- professional INTERNET services -------------------- EastLink GmbH Niederlassung Magdeburg voice: +49-180-5432060 Lorenzweg 42 fax: +49-371-4320626 D-39110 Magdeburg http://www.eastlink.de

1 0

New execution behavior
by Duane Clark 28 Feb '01

28 Feb '01

Howdy, Here is a symptom that has crept into the recent version of wine. Since I know how to make things work, this is just a post in case someone is interested. When I recently updated to the Feb 24 CVS version (from the Feb 4 version), I suddenly had the symptom that I could only run one program at a time. In other words, I ran the program schedit (one I use regularly), and it came up and worked fine. But when I then tried to also run symed, it would not come up, but instead gave: err:ntdll:RtlpWaitForCriticalSection Critical section 0x400f9ad0 wait timed out, retrying (60 sec) fs=022f Where the address 0x400f9ad0 is in: disas 0x400f9ad0 0x400f9ad0 (peb_lock [rtl.c]): addb %al,0x0(%eax) 0x400f9ad2 (peb_lock+0x2 [rtl.c]): addb %al,0x0(%eax) 0x400f9ad4 (peb_lock+0x4 [rtl.c]): 0x400f9ad6 (peb_lock+0x6 [rtl.c]): 0x400f9ad8 (peb_lock+0x8 [rtl.c]): addb %al,0x0(%eax) 0x400f9ada (peb_lock+0xa [rtl.c]): addb %al,0x0(%eax) 0x400f9adc (peb_lock+0xc [rtl.c]): addb %al,0x0(%eax) 0x400f9ade (peb_lock+0xe [rtl.c]): addb %al,0x0(%eax) 0x400f9ae0 (peb_lock+0x10 [rtl.c]): cmpb $0,%al 0x400f9ae2 (peb_lock+0x12 [rtl.c]): addb %al,0x0(%eax) Wine-dbg> Trying a couple other programs showed that this affected all of them. In particular, one that is more readily available, Wordview97. For example, I could run one instance of wordview, but not a second. This is running wine along with a Win98 installation. It turns out the for some obscure reason I had the DLLs exactly as in the sample config file, except that I had: "DefaultLoadOrder" = "builtin, native, so" Putting it the (presumably) right way fixed things (except a wordview font problem): "DefaultLoadOrder" = "native, builtin, so" Here is info on the the loading of DLLs. The only differences I see with native first is with ole32 being native instead of builtin, and that rpcrt4 gets loaded much later. Here is with "DefaultLoadOrder" = "native, builtin, so" trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\kernel32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\advapi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\gdi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\user32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\ole32.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\mso97v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\Program Files\WordView\wwint32v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shlwapi.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comctl32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shell32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\winspool.drv' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'krnl386.exe' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'system' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'wprocs' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'GDI.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\wineps.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'USER.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\x11drv.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'display' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comdlg32.dll' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'commdlg.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\rpcrt4.dll' : native And here is with "DefaultLoadOrder" = "builtin, native, so" trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\kernel32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\advapi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\gdi32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\user32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\rpcrt4.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\ole32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\mso97v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\Program Files\WordView\wwint32v.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shlwapi.dll' : native trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comctl32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\shell32.dll' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\winspool.drv' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'krnl386.exe' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'system' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'wprocs' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'GDI.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\wineps.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'USER.EXE' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\WINDOWS\SYSTEM\x11drv.DLL' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'display' : builtin trace:loaddll:MODULE_LoadLibraryExA Loaded module 'C:\windows\system\comdlg32.dll' : builtin trace:loaddll:MODULE_LoadModule16 Loaded module 'commdlg.dll' : builtin And here is a short message from Gerard, regarding a trace I had sent him. Both traces are from running Wordview, where the first one came up ok and the second crashed (the behavior changed when run with these debug messages enabled): Here is what your app (actually, probably rpcrt4 for Win9x) is doing : Call kernel32.193: CreateFileMappingA(ffffffff,00000000,00000004,00000000,00000400,7fbd4a7c "rpcrt4sharedmem") ret=7fb9177b fs=008f Ret kernel32.193: CreateFileMappingA() retval=00000048 ret=7fb9177b fs=008f Call kernel32.419: GetLastError() ret=7fb9178e fs=008f Ret kernel32.419: GetLastError() retval=00000000 ret=7fb9178e fs=008f Call kernel32.632: MapViewOfFile(00000048,00000002,00000000,00000000,00000000) ret=7fb917ac fs=008f Ret kernel32.632: MapViewOfFile() retval=40349000 ret=7fb917ac fs=008f Call kernel32.553: HeapCreate(04000000,00001000,00000000) ret=7fb95c0f fs=008f Ret kernel32.553: HeapCreate() retval=65430000 ret=7fb95c0f fs=008f Call kernel32.551: HeapAlloc(65430000,00000000,00000040) ret=7fb95bf9 fs=008f Ret kernel32.551: HeapAlloc() retval=6543009c ret=7fb95bf9 fs=008f So, we have created a shared memory area and allocated memory at 65430000 Now here is what the next process is doing : Call kernel32.193: CreateFileMappingA(ffffffff,00000000,00000004,00000000,00000400,7fbd4a7c "rpcrt4sharedmem") ret=7fb9177b fs=008f Ret kernel32.193: CreateFileMappingA() retval=00000048 ret=7fb9177b fs=008f Call kernel32.419: GetLastError() ret=7fb9178e fs=008f Ret kernel32.419: GetLastError() retval=000000b7 ret=7fb9178e fs=008f Call kernel32.632: MapViewOfFile(00000048,00000002,00000000,00000000,00000000) ret=7fb917ac fs=008f Ret kernel32.632: MapViewOfFile() retval=40349000 ret=7fb917ac fs=008f Call kernel32.380: GetCurrentProcessId() ret=7fb95d5b fs=008f Ret kernel32.380: GetCurrentProcessId() retval=0808e1b8 ret=7fb95d5b fs=008f Call user32.422: MessageBoxA(00000000,40474ae0 "Unhandled page fault on read access to 0x654300b0 We have opened the shared memory (this is working since GetLastError returns that the file already exists : 000000b7), and tried to access data at 0x654300b0. This is failing it seems (you could try to run with -debugmsg +seh to confirm that an exception is occuring there) Note that the second process has allocated *no memory* at this place; from where is coming this 654300b0 value ? I guess from the shared memory. Duane

1 0

Re: Speeding up wineserver syncronization objects with shared memory
by David Howells 28 Feb '01

28 Feb '01

I've got a lot of the wine support kernel module written now. Its system call latency seems to be down at near half that of Win2000 for mutexes, though there's no guarantee that my benchmark programs produce meaningful numbers. I've also got PE Image mapping done (with pages fixed up on demand and marked as discardable). So if anything, Wine might want to steal that if the module as a whole is not used. This bit requires virtually no changes to the kernel itself, just half a dozen or so extra symbols to be exported. The module image size stands currently at about 30K. Status: PART STATE ====================================== ========================== General object infrastructure done HANDLE infrastructure mostly done Waiting calls partly done Exception handling not done Win32 error handling not done, uses UNIX errno UNICODE handling ignored, all ASCII Security handling ignored Mutex objects done Semaphore objects done Event objects done File objects (synchronous access) mostly done File objects (asynchronous access) not done Shared memory objects mostly done Process objects slightly done Thread objects slightly done Registry objects not done NT Port objects not done NT Token objects not done W2K Job objects not done Net Communications not done userspace access library up to date strace mostly up to date Cheers, David

1 0

PostScript driver demand loading
by Ian Pilcher 27 Feb '01

27 Feb '01

The attached patch removes the explicit load of the PostScript driver from MAIN_GdiInit. Instead, when a function calls DRIVER_FindDriver to get a drivers DC_FUNCTIONS, DRIVER_FindDriver will attempt to load a named driver if it hasn't already registered itself. This appears to work for printing from Lotus Notes. I'd appreciate some feedback from people using other applications, however. Also, any thoughts on the approach in general would be welcome. Thanks! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ======================================================================== --- ../wine-20010226cvs/graphics/driver.c Mon Nov 27 17:54:29 2000 +++ graphics/driver.c Tue Feb 27 18:34:08 2001 @@ -54,15 +54,25 @@ */ const DC_FUNCTIONS *DRIVER_FindDriver( LPCSTR name ) { - GRAPHICS_DRIVER *driver = firstDriver; + GRAPHICS_DRIVER *driver; + HINSTANCE hDriver; TRACE(": %s\n", name); - while (driver && name) - { + + if (!name) return genericDriver ? genericDriver->funcs : NULL; + + for (driver = firstDriver; driver; driver = driver->next) if (!strcasecmp( driver->name, name )) return driver->funcs; - driver = driver->next; - } - return genericDriver ? genericDriver->funcs : NULL; + + if (!(hDriver = LoadLibraryA (name))) return NULL; + + for (driver = firstDriver; driver; driver = driver->next) + if (!strcasecmp( driver->name, name )) return driver->funcs; + + if (!FreeLibrary (hDriver)) + WARN ("FreeLibrary failed with code %li\n", GetLastError ()); + + return NULL; } --- ../wine-20010226cvs/dlls/gdi/gdi_main.c Fri Jan 26 14:43:43 2001 +++ dlls/gdi/gdi_main.c Tue Feb 27 18:19:44 2001 @@ -24,9 +24,6 @@ /* Create the Win16 printer driver */ if (!WIN16DRV_Init()) return FALSE; - /* PSDRV initialization */ - if (!LoadLibraryA( "wineps" )) return FALSE; - return TRUE; }

1 0

Re: winspool.drv initialization problem
by Alexandre Julliard 27 Feb '01

27 Feb '01

Ian Pilcher <pilcher(a)concentric.net> writes: > I've gotten my modified version of the PostScript driver to load, but it > seems to causing/exposing another problem. > > WINPROC_GetPtr is being called befor WINPROC_Init during Wine > initialization. The call to WINPROC_GetPtr results from a call to > LoadLibraryExA ("COMCTL32.DLL" ...); here is the stack: Sounds like importing winspool.drv in wineps creates a circular load dependency (user32->gdi32->wineps->winspool->comctl32->user32). We could probably be a bit more clever about loading wineps only when really necessary; OTOH there is no reason for winspool.drv to require comctl32. Something like this should fix it (completely untested, so it's probably broken): Index: dlls/winspool/info.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/winspool/info.c,v retrieving revision 1.33 diff -u -r1.33 info.c --- dlls/winspool/info.c 2001/02/21 04:00:40 1.33 +++ dlls/winspool/info.c 2001/02/26 23:01:57 @@ -20,23 +20,12 @@ #include "wine/unicode.h" #include "debugtools.h" #include "heap.h" -#include "commctrl.h" #include "winnls.h" DEFAULT_DEBUG_CHANNEL(winspool); -typedef struct _OPENEDPRINTER -{ - LPWSTR lpsPrinterName; - HANDLE hPrinter; -} OPENEDPRINTER, *LPOPENEDPRINTER; - -/* The OpenedPrinter Table dynamic array */ -static HDPA pOpenedPrinterDPA = NULL; - -extern HDPA WINAPI (*WINSPOOL_DPA_CreateEx) (INT, HANDLE); -extern LPVOID WINAPI (*WINSPOOL_DPA_GetPtr) (const HDPA, INT); -extern INT WINAPI (*WINSPOOL_DPA_InsertPtr) (const HDPA, INT, LPVOID); +static LPWSTR *printer_array; +static int nb_printers; static DWORD WINAPI (*GDI_CallDeviceCapabilities16)( LPCSTR lpszDevice, LPCSTR lpszPort, WORD fwCapability, LPSTR lpszOutput, @@ -84,73 +73,42 @@ * WINSPOOL_GetOpenedPrinterEntry * Get the first place empty in the opened printer table */ -static LPOPENEDPRINTER WINSPOOL_GetOpenedPrinterEntry() +static HANDLE WINSPOOL_GetOpenedPrinterEntry( LPCWSTR name ) { int i; - LPOPENEDPRINTER pOpenedPrinter; - /* - * Create the opened printers' handle dynamic array. - */ - if (!pOpenedPrinterDPA) - { - pOpenedPrinterDPA = WINSPOOL_DPA_CreateEx(10, GetProcessHeap()); - for (i = 0; i < 10; i++) - { - pOpenedPrinter = HeapAlloc(GetProcessHeap(), - HEAP_ZERO_MEMORY, - sizeof(OPENEDPRINTER)); - pOpenedPrinter->hPrinter = -1; - WINSPOOL_DPA_InsertPtr(pOpenedPrinterDPA, i, pOpenedPrinter); - } - } + for (i = 0; i < nb_printers; i++) if (!printer_array[i]) break; - /* - * Search for a handle not yet allocated. - */ - for (i = 0; i < pOpenedPrinterDPA->nItemCount; i++) + if (i >= nb_printers) { - pOpenedPrinter = WINSPOOL_DPA_GetPtr(pOpenedPrinterDPA, i); - - if (pOpenedPrinter->hPrinter == -1) - { - pOpenedPrinter->hPrinter = i + 1; - return pOpenedPrinter; - } + LPWSTR *new_array = HeapReAlloc( GetProcessHeap(), 0, printer_array, + (nb_printers + 16) * sizeof(*new_array) ); + if (!new_array) return 0; + printer_array = new_array; + nb_printers += 16; } - /* - * Didn't find one, insert new element in the array. - */ - if (i == pOpenedPrinterDPA->nItemCount) + if ((printer_array[i] = HeapAlloc( GetProcessHeap(), 0, (strlenW(name)+1)*sizeof(WCHAR) ))) { - pOpenedPrinter = HeapAlloc(GetProcessHeap(), - HEAP_ZERO_MEMORY, - sizeof(OPENEDPRINTER)); - pOpenedPrinter->hPrinter = i + 1; - WINSPOOL_DPA_InsertPtr(pOpenedPrinterDPA, i, pOpenedPrinter); - return pOpenedPrinter; + strcpyW( printer_array[i], name ); + return (HANDLE)(i + 1); } - - return NULL; + return 0; } /****************************************************************** * WINSPOOL_GetOpenedPrinter * Get the pointer to the opened printer referred by the handle */ -static LPOPENEDPRINTER WINSPOOL_GetOpenedPrinter(int printerHandle) +static LPCWSTR WINSPOOL_GetOpenedPrinter(HANDLE printerHandle) { - LPOPENEDPRINTER pOpenedPrinter; - - if(!pOpenedPrinterDPA) return NULL; - if((printerHandle <=0) || - (printerHandle > (pOpenedPrinterDPA->nItemCount - 1))) + int idx = (int)printerHandle; + if ((idx <= 0) || (idx > nb_printers)) + { + SetLastError(ERROR_INVALID_HANDLE); return NULL; - - pOpenedPrinter = WINSPOOL_DPA_GetPtr(pOpenedPrinterDPA, printerHandle-1); - - return pOpenedPrinter; + } + return printer_array[idx - 1]; } /****************************************************************** @@ -159,21 +117,20 @@ */ static DWORD WINSPOOL_GetOpenedPrinterRegKey(HANDLE hPrinter, HKEY *phkey) { - LPOPENEDPRINTER lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); + LPCWSTR name = WINSPOOL_GetOpenedPrinter(hPrinter); DWORD ret; HKEY hkeyPrinters; - if(!lpOpenedPrinter) - return ERROR_INVALID_HANDLE; + if(!name) return ERROR_INVALID_HANDLE; if((ret = RegCreateKeyA(HKEY_LOCAL_MACHINE, Printers, &hkeyPrinters)) != ERROR_SUCCESS) return ret; - if(RegOpenKeyW(hkeyPrinters, lpOpenedPrinter->lpsPrinterName, phkey) - != ERROR_SUCCESS) { + if(RegOpenKeyW(hkeyPrinters, name, phkey) != ERROR_SUCCESS) + { ERR("Can't find opened printer %s in registry\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + debugstr_w(name)); RegCloseKey(hkeyPrinters); return ERROR_INVALID_PRINTER_NAME; /* ? */ } @@ -408,7 +365,6 @@ LPSTR pDeviceName, LPDEVMODEA pDevModeOutput, LPDEVMODEA pDevModeInput,DWORD fMode ) { - LPOPENEDPRINTER lpOpenedPrinter; LPSTR lpName = pDeviceName; LONG ret; @@ -417,13 +373,8 @@ ); if(!pDeviceName) { - LPWSTR lpNameW; - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return -1; - } - lpNameW = lpOpenedPrinter->lpsPrinterName; + LPCWSTR lpNameW = WINSPOOL_GetOpenedPrinter(hPrinter); + if(!lpNameW) return -1; lpName = HEAP_strdupWtoA(GetProcessHeap(),0,lpNameW); } @@ -512,7 +463,6 @@ BOOL WINAPI OpenPrinterW(LPWSTR lpPrinterName,HANDLE *phPrinter, LPPRINTER_DEFAULTSW pDefault) { - LPOPENEDPRINTER lpOpenedPrinter; HKEY hkeyPrinters, hkeyPrinter; if (!lpPrinterName) { @@ -545,21 +495,8 @@ if(!phPrinter) /* This seems to be what win95 does anyway */ return TRUE; - /* Get a place in the opened printer buffer*/ - lpOpenedPrinter = WINSPOOL_GetOpenedPrinterEntry(); - if(!lpOpenedPrinter) { - ERR("Can't allocate printer slot\n"); - SetLastError(ERROR_OUTOFMEMORY); - return FALSE; - } - - /* Get the name of the printer */ - lpOpenedPrinter->lpsPrinterName = HeapAlloc( GetProcessHeap(), 0, - (strlenW(lpPrinterName)+1)*sizeof(WCHAR) ); - strcpyW( lpOpenedPrinter->lpsPrinterName, lpPrinterName ); - /* Get the unique handle of the printer*/ - *phPrinter = lpOpenedPrinter->hPrinter; + *phPrinter = WINSPOOL_GetOpenedPrinterEntry( lpPrinterName ); if (pDefault != NULL) FIXME("Not handling pDefault\n"); @@ -915,23 +852,14 @@ */ BOOL WINAPI ClosePrinter(HANDLE hPrinter) { - LPOPENEDPRINTER lpOpenedPrinter; + int i = (int)hPrinter; TRACE("Handle %d\n", hPrinter); - - if (!pOpenedPrinterDPA) - return FALSE; - if ((hPrinter != -1) && (hPrinter < (pOpenedPrinterDPA->nItemCount - 1))) - { - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - HeapFree(GetProcessHeap(), 0, lpOpenedPrinter->lpsPrinterName); - lpOpenedPrinter->lpsPrinterName = NULL; - lpOpenedPrinter->hPrinter = -1; - - return TRUE; - } - return FALSE; + if ((i <= 0) || (i > nb_printers)) return FALSE; + HeapFree( GetProcessHeap(), 0, printer_array[i - 1] ); + printer_array[i - 1] = NULL; + return TRUE; } /***************************************************************************** @@ -957,15 +885,10 @@ */ BOOL WINAPI DeletePrinter(HANDLE hPrinter) { - LPWSTR lpNameW; + LPCWSTR lpNameW = WINSPOOL_GetOpenedPrinter(hPrinter); HKEY hkeyPrinters; - LPOPENEDPRINTER lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return FALSE; - } - lpNameW = lpOpenedPrinter->lpsPrinterName; + if(!lpNameW) return FALSE; if(RegOpenKeyA(HKEY_LOCAL_MACHINE, Printers, &hkeyPrinters) != ERROR_SUCCESS) { ERR("Can't open Printers key\n"); @@ -1410,7 +1333,7 @@ static BOOL WINSPOOL_GetPrinter(HANDLE hPrinter, DWORD Level, LPBYTE pPrinter, DWORD cbBuf, LPDWORD pcbNeeded, BOOL unicode) { - OPENEDPRINTER *lpOpenedPrinter; + LPCWSTR name; DWORD size, needed = 0; LPBYTE ptr = NULL; HKEY hkeyPrinter, hkeyPrinters; @@ -1418,20 +1341,16 @@ TRACE("(%d,%ld,%p,%ld,%p)\n",hPrinter,Level,pPrinter,cbBuf, pcbNeeded); - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return FALSE; - } + if (!(name = WINSPOOL_GetOpenedPrinter(hPrinter))) return FALSE; + if(RegCreateKeyA(HKEY_LOCAL_MACHINE, Printers, &hkeyPrinters) != ERROR_SUCCESS) { ERR("Can't create Printers key\n"); return FALSE; } - if(RegOpenKeyW(hkeyPrinters, lpOpenedPrinter->lpsPrinterName, &hkeyPrinter) - != ERROR_SUCCESS) { - ERR("Can't find opened printer %s in registry\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + if(RegOpenKeyW(hkeyPrinters, name, &hkeyPrinter) != ERROR_SUCCESS) + { + ERR("Can't find opened printer %s in registry\n", debugstr_w(name)); RegCloseKey(hkeyPrinters); SetLastError(ERROR_INVALID_PRINTER_NAME); /* ? */ return FALSE; @@ -1933,7 +1852,7 @@ DWORD cbBuf, LPDWORD pcbNeeded, BOOL unicode) { - OPENEDPRINTER *lpOpenedPrinter; + LPCWSTR name; WCHAR DriverName[100]; DWORD ret, type, size, needed = 0; LPBYTE ptr = NULL; @@ -1944,11 +1863,8 @@ ZeroMemory(pDriverInfo, cbBuf); - lpOpenedPrinter = WINSPOOL_GetOpenedPrinter(hPrinter); - if(!lpOpenedPrinter) { - SetLastError(ERROR_INVALID_HANDLE); - return FALSE; - } + if (!(name = WINSPOOL_GetOpenedPrinter(hPrinter))) return FALSE; + if(Level < 1 || Level > 3) { SetLastError(ERROR_INVALID_LEVEL); return FALSE; @@ -1958,10 +1874,9 @@ ERR("Can't create Printers key\n"); return FALSE; } - if(RegOpenKeyW(hkeyPrinters, lpOpenedPrinter->lpsPrinterName, &hkeyPrinter) + if(RegOpenKeyW(hkeyPrinters, name, &hkeyPrinter) != ERROR_SUCCESS) { - ERR("Can't find opened printer %s in registry\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + ERR("Can't find opened printer %s in registry\n", debugstr_w(name)); RegCloseKey(hkeyPrinters); SetLastError(ERROR_INVALID_PRINTER_NAME); /* ? */ return FALSE; @@ -1972,8 +1887,7 @@ RegCloseKey(hkeyPrinter); RegCloseKey(hkeyPrinters); if(ret != ERROR_SUCCESS) { - ERR("Can't get DriverName for printer %s\n", - debugstr_w(lpOpenedPrinter->lpsPrinterName)); + ERR("Can't get DriverName for printer %s\n", debugstr_w(name)); return FALSE; } Index: dlls/winspool/wspool.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/winspool/wspool.c,v retrieving revision 1.3 diff -u -r1.3 wspool.c --- dlls/winspool/wspool.c 2001/02/12 03:51:05 1.3 +++ dlls/winspool/wspool.c 2001/02/26 23:01:57 @@ -5,15 +5,10 @@ * Copyright 1999 Thuy Nguyen */ -#include "commctrl.h" #include "debugtools.h" DEFAULT_DEBUG_CHANNEL(winspool); -HINSTANCE hcomctl32 = 0; -HDPA WINAPI (*WINSPOOL_DPA_CreateEx)(INT, HANDLE); -LPVOID WINAPI (*WINSPOOL_DPA_GetPtr)(const HDPA, INT); -INT WINAPI (*WINSPOOL_DPA_InsertPtr)(const HDPA, INT, LPVOID); /****************************************************************************** * WINSPOOL_EntryPoint @@ -28,16 +23,9 @@ switch (reason) { case DLL_PROCESS_ATTACH: - - hcomctl32 = LoadLibraryA("COMCTL32.DLL"); - - WINSPOOL_DPA_CreateEx = (void*)GetProcAddress(hcomctl32, (LPCSTR)340L); - WINSPOOL_DPA_GetPtr = (void*)GetProcAddress(hcomctl32, (LPCSTR)332L); - WINSPOOL_DPA_InsertPtr = (void*)GetProcAddress(hcomctl32, (LPCSTR)334L); break; case DLL_PROCESS_DETACH: - FreeLibrary(hcomctl32); break; } -- Alexandre Julliard julliard(a)winehq.com

3 3

winspool.drv initialization problem
by Ian Pilcher 26 Feb '01

26 Feb '01

The saga continues! I've gotten my modified version of the PostScript driver to load, but it seems to causing/exposing another problem. WINPROC_GetPtr is being called befor WINPROC_Init during Wine initialization. The call to WINPROC_GetPtr results from a call to LoadLibraryExA ("COMCTL32.DLL" ...); here is the stack: #0 HEAP_GetPtr (heap=0) at heap.c:217 #1 0x40093514 in HeapValidate (heap=0, flags=0, block=0x408ffc67) at heap.c:1508 #2 0x4081c93f in WINPROC_GetPtr () from /usr/lib/wine/libuser32.so #3 0x4081cbaa in WINPROC_SetProc () from /usr/lib/wine/libuser32.so #4 0x407e280d in RegisterClassA () from /usr/lib/wine/libuser32.so #5 0x40900058 in ANIMATE_Register () from /usr/lib/wine/libcomctl32.so #6 0x40906412 in COMCTL32_LibMain () from /usr/lib/wine/libcomctl32.so #7 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #8 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #9 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #10 0x4007f364 in LoadLibraryExA () from /usr/lib/wine/libntdll.so #11 0x4007f916 in LoadLibraryA () from /usr/lib/wine/libntdll.so #12 0x40975772 in WINSPOOL_EntryPoint () from /usr/lib/wine/libwinspool.drv.so #13 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #14 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #15 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #16 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #17 0x4007f364 in LoadLibraryExA () from /usr/lib/wine/libntdll.so #18 0x4007f916 in LoadLibraryA () from /usr/lib/wine/libntdll.so #19 0x4087206b in MAIN_GdiInit () from /usr/lib/wine/libgdi32.so #20 0x400814e8 in PE_InitDLL () from /usr/lib/wine/libntdll.so #21 0x4007d0f9 in MODULE_InitDLL () from /usr/lib/wine/libntdll.so #22 0x4007d216 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #23 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #24 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #25 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #26 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #27 0x4007d1f0 in MODULE_DllProcessAttach () from /usr/lib/wine/libntdll.so #28 0x400c758c in start_process () from /usr/lib/wine/libntdll.so #29 0x400caeed in SYSDEPS_DoCallOnStack () from /usr/lib/wine/libntdll.so #30 0x400caf97 in SYSDEPS_CallOnStack () from /usr/lib/wine/libntdll.so #31 0x400cb03a in SYSDEPS_SwitchToThreadStack () from /usr/lib/wine/libntdll.so #32 0x400c79d7 in PROCESS_InitWine () from /usr/lib/wine/libntdll.so #33 0x804b213 in main () #34 0x4027ff55 in __libc_start_main (main=0x804b1f8 <main>, argc=1, ubp_av=0xbffff9d4, init=0x8048728 <_init>, fini=0x804b25c <_fini>, rtld_fini=0x4000e3e4 <_dl_fini>, stack_end=0xbffff9cc) at ../sysdeps/generic/libc-start.c:129 This is way out of my depth! -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

2 1

Re: undefined symbol: GetPrinterDataA
by Alexandre Julliard 26 Feb '01

26 Feb '01

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > Would it be useful to create such a list, and maybe list > for each of the dlls in there, why there aren't separated yet? Here's a list of the undefined symbols that prevent separation of the remaining dlls (I didn't include user/gdi/kernel to avoid scaring people too much ;-) ./libddraw.so: undefined reference to `DIB_CreateDIBSection' ./libddraw.so: undefined reference to `DIB_GetDIBWidthBytes' ./libddraw.so: undefined reference to `PROFILE_GetWineIniBool' ./libddraw.so: undefined reference to `WIN_FindWndPtr' ./libddraw.so: undefined reference to `WIN_ReleaseWndPtr' ./libddraw.so: undefined reference to `X11DRV_WND_GetXWindow' ./libddraw.so: undefined reference to `display' ./libddraw.so: undefined reference to `root_window' ./libddraw.so: undefined reference to `visual' ./libopengl32.so: undefined reference to `DC_GetDCPtr' ./libopengl32.so: undefined reference to `GDI_ReleaseObj' ./libopengl32.so: undefined reference to `XFONT_GetFontObject' ./libopengl32.so: undefined reference to `display' ./libopengl32.so: undefined reference to `root_window' ./libopengl32.so: undefined reference to `visual' ./libdinput.so: undefined reference to `MOUSE_Enable' ./libdinput.so: undefined reference to `USER_Driver' ./libwinedos.so: undefined reference to `DOSMEM_Available' ./libwinedos.so: undefined reference to `DOSMEM_FreeBlock' ./libwinedos.so: undefined reference to `DOSMEM_GetBlock' ./libwinedos.so: undefined reference to `DOSMEM_Init' ./libwinedos.so: undefined reference to `DOSMEM_MapRealToLinear' ./libwinedos.so: undefined reference to `DOSMEM_wrap_seg' ./libwinedos.so: undefined reference to `EXC_RtlRaiseException' ./libwinedos.so: undefined reference to `FILE_GetUnixHandle' ./libwinedos.so: undefined reference to `INSTR_EmulateInstruction' ./libwinedos.so: undefined reference to `INT_GetRMHandler' ./libwinedos.so: undefined reference to `INT_Int09SendScan' ./libwinedos.so: undefined reference to `INT_Int33Message' ./libwinedos.so: undefined reference to `INT_RealModeInterrupt' ./libwinedos.so: undefined reference to `INT_SetRMHandler' ./libwinedos.so: undefined reference to `VGA_Clean' ./libwinedos.so: undefined reference to `_LeaveWin16Lock' ./libwinedos.so: undefined reference to `full_argv0' ./libwineps.so: undefined reference to `CloseJob16' ./libwineps.so: undefined reference to `DC_GetDCPtr' ./libwineps.so: undefined reference to `DIB_GetBitmapInfo' ./libwineps.so: undefined reference to `DIB_GetDIBWidthBytes' ./libwineps.so: undefined reference to `DRIVER_RegisterDriver' ./libwineps.so: undefined reference to `DRIVER_UnregisterDriver' ./libwineps.so: undefined reference to `DrvGetPrinterData16' ./libwineps.so: undefined reference to `DrvSetPrinterData16' ./libwineps.so: undefined reference to `GDI_GetObjPtr' ./libwineps.so: undefined reference to `GDI_ReleaseObj' ./libwineps.so: undefined reference to `OpenJob16' ./libwineps.so: undefined reference to `PROFILE_EnumWineIniString' ./libwineps.so: undefined reference to `PROFILE_GetWineIniString' ./libwineps.so: undefined reference to `SelectClipRgn16' ./libwineps.so: undefined reference to `WriteSpool16' ./libmcicda.drv.so: undefined reference to `CDROM_Close' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Stop' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetCDStatus' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Play' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetTracksInfo' ./libmcicda.drv.so: undefined reference to `CDROM_CloseDev' ./libmcicda.drv.so: undefined reference to `CDROM_OpenDev' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetSerial' ./libmcicda.drv.so: undefined reference to `CDROM_Open' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_GetNumberOfTracks' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Pause' ./libmcicda.drv.so: undefined reference to `CDROM_SetDoor' ./libmcicda.drv.so: undefined reference to `CDROM_Audio_Seek' ./libws2_32.so: undefined reference to `SERVICE_Delete' ./libws2_32.so: undefined reference to `SERVICE_AddObject' ./libws2_32.so: undefined reference to `FILE_GetUnixHandle' ./libx11drv.so: undefined reference to `BITMAP_Driver' ./libx11drv.so: undefined reference to `BITMAP_GetWidthBytes' ./libx11drv.so: undefined reference to `CLIPBOARD_DeleteRecord' ./libx11drv.so: undefined reference to `CLIPBOARD_EmptyCache' ./libx11drv.so: undefined reference to `CLIPBOARD_GetFormatName' ./libx11drv.so: undefined reference to `CLIPBOARD_IsPresent' ./libx11drv.so: undefined reference to `CLIPBOARD_LookupFormat' ./libx11drv.so: undefined reference to `CLIPBOARD_ReleaseOwner' ./libx11drv.so: undefined reference to `CLIPPING_IntersectVisRect' ./libx11drv.so: undefined reference to `COLOR_IsSolid' ./libx11drv.so: undefined reference to `COLOR_PaletteLookupExactIndex' ./libx11drv.so: undefined reference to `COLOR_PaletteLookupPixel' ./libx11drv.so: undefined reference to `COLOR_gapEnd' ./libx11drv.so: undefined reference to `COLOR_gapFilled' ./libx11drv.so: undefined reference to `COLOR_gapStart' ./libx11drv.so: undefined reference to `COLOR_max' ./libx11drv.so: undefined reference to `COLOR_sysPal' ./libx11drv.so: undefined reference to `COLOR_sysPalTemplate' ./libx11drv.so: undefined reference to `DCE_InvalidateDCE' ./libx11drv.so: undefined reference to `DC_GetDCPtr' ./libx11drv.so: undefined reference to `DC_InitDC' ./libx11drv.so: undefined reference to `DIB_BitmapInfoSize' ./libx11drv.so: undefined reference to `DIB_CreateDIBFromBitmap' ./libx11drv.so: undefined reference to `DIB_GetBitmapInfo' ./libx11drv.so: undefined reference to `DIB_GetDIBImageBytes' ./libx11drv.so: undefined reference to `DIB_GetDIBWidthBytes' ./libx11drv.so: undefined reference to `DRAG_QueryUpdate' ./libx11drv.so: undefined reference to `DRIVER_RegisterDriver' ./libx11drv.so: undefined reference to `DeleteObject16' ./libx11drv.so: undefined reference to `EVENT_Synchronize' ./libx11drv.so: undefined reference to `FILE_DupUnixHandle' ./libx11drv.so: undefined reference to `FONT_LogFontWTo16' ./libx11drv.so: undefined reference to `GDI_AllocObject' ./libx11drv.so: undefined reference to `GDI_GetObjPtr' ./libx11drv.so: undefined reference to `GDI_ReleaseObj' ./libx11drv.so: undefined reference to `GetClipboardData16' ./libx11drv.so: undefined reference to `InputKeyStateTable' ./libx11drv.so: undefined reference to `KEYBOARD_SendEvent' ./libx11drv.so: undefined reference to `NC_IconForWindow' ./libx11drv.so: undefined reference to `Options' ./libx11drv.so: undefined reference to `PALETTE_Driver' ./libx11drv.so: undefined reference to `PROFILE_GetStringItem' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniBool' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniInt' ./libx11drv.so: undefined reference to `PROFILE_GetWineIniString' ./libx11drv.so: undefined reference to `PostMessage16' ./libx11drv.so: undefined reference to `REGION_LPTODP' ./libx11drv.so: undefined reference to `RestoreVisRgn16' ./libx11drv.so: undefined reference to `SELECTOR_AllocBlock' ./libx11drv.so: undefined reference to `SELECTOR_FreeBlock' ./libx11drv.so: undefined reference to `SERVICE_AddObject' ./libx11drv.so: undefined reference to `SERVICE_AddTimer' ./libx11drv.so: undefined reference to `SaveVisRgn16' ./libx11drv.so: undefined reference to `SelectClipRgn16' ./libx11drv.so: undefined reference to `SelectVisRgn16' ./libx11drv.so: undefined reference to `TWEAK_WineLook' ./libx11drv.so: undefined reference to `VIRTUAL_SetFaultHandler' ./libx11drv.so: undefined reference to `WIN_FindWndPtr' ./libx11drv.so: undefined reference to `WIN_GetDesktop' ./libx11drv.so: undefined reference to `WIN_InternalShowOwnedPopups' ./libx11drv.so: undefined reference to `WIN_LinkWindow' ./libx11drv.so: undefined reference to `WIN_LockWndPtr' ./libx11drv.so: undefined reference to `WIN_ReleaseDesktop' ./libx11drv.so: undefined reference to `WIN_ReleaseWndPtr' ./libx11drv.so: undefined reference to `WIN_RestoreWndsLock' ./libx11drv.so: undefined reference to `WIN_SuspendWndsLock' ./libx11drv.so: undefined reference to `WIN_UnlinkWindow' ./libx11drv.so: undefined reference to `WIN_UpdateWndPtr' ./libx11drv.so: undefined reference to `WIN_WindowNeedsWMBorder' ./libx11drv.so: undefined reference to `WND_Driver' ./libx11drv.so: undefined reference to `argv0' ./libx11drv.so: undefined reference to `get_config_dir' ./libx11drv.so: undefined reference to `pKeyStateTable' ./libttydrv.so: undefined reference to `BITMAP_Driver' ./libttydrv.so: undefined reference to `COLOR_gapEnd' ./libttydrv.so: undefined reference to `COLOR_gapStart' ./libttydrv.so: undefined reference to `COLOR_sysPal' ./libttydrv.so: undefined reference to `COLOR_sysPalTemplate' ./libttydrv.so: undefined reference to `DC_GetDCPtr' ./libttydrv.so: undefined reference to `DRIVER_FindDriver' ./libttydrv.so: undefined reference to `DRIVER_RegisterDriver' ./libttydrv.so: undefined reference to `GDI_GetObjPtr' ./libttydrv.so: undefined reference to `GDI_ReleaseObj' ./libttydrv.so: undefined reference to `PALETTE_Driver' ./libttydrv.so: undefined reference to `WND_Driver' -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > So your concern is simply that if it's too simple to lock the mutex, then > you have an unacceptably high probability of a runaway process > accidentally locking the mutex, whereas you regard the probability of the > process accidentally calling AcquireMutex again (or executing the > protected control transfer on its own) as acceptably low. That seems > reasonable. No, that's not my concern. The probability of error doesn't matter at all, I don't mind if the process locks the mutex by accident. What must not be able to happen is that the process somehow corrupts the state as seen from the wineserver or other processes. That is, it doesn't matter if the process thinks it got the mutex when it didn't; but it must not be possible to make the wineserver see two processes holding the mutex, or some other inconsistent state. Any inconsistency must remain local to the process. > Yeah, but that doesn't seem fundamental --- the wineserver can always take > ownership of the mutex itself when it needs to do a complex atomic > operation. I'll let Gavriel work out the details :-). My point is that getting the details right is what is important; and if you are not interested in doing this, then there is no point in arguing any further. -- Alexandre Julliard julliard(a)winehq.com

1 0

undefined symbol: GetPrinterDataA
by Ian Pilcher 26 Feb '01

26 Feb '01

I am trying to modify the Wine PostScript driver to use GetPrinterDataA to read configuration information from the registry. I have added a line that reads "import winspool.drv" to wineps.spec, and Wine builds with no errors. When I try to run Wine, however, I get the following error: BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Ideas? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

5 4

Re: Speeding up wineserver synchronization objects with shared memory
by Alexandre Julliard 26 Feb '01

26 Feb '01

"Robert O'Callahan" <roc+(a)cs.cmu.edu> writes: > Of course it has to be 100% reliable, but since you're dealing with > failing processes it's not 100% clear what 100% reliability is. Anyway, I > think 100% reliability is possible for any plausible definition. For a mutex the basic definition is obviously that you can never have two threads holding the mutex at the same time, and that when it is released some other thread has a chance at grabbing it. This has to be true no matter what the process does, including corrupting memory or crashing. You also need to make sure nothing a process does should be able to crash/hang the wineserver or another process (except if they fight over the same mutex of course), and then there is the small matter of respecting the Win32 semantics... Actually it is the last constraint that is the main problem. You can certainly provide some kind of mutexes using shared memory; but we don't need just 'some kind', we need Win32 mutexes. This means a mutex is identified by a handle that can be manipulated by CloseHandle or DuplicateHandle; it means you need to detect and handle abandoned mutexes; it means you must support WaitForMultipleObjects, including the 'all' case where you cannot grab the mutex unless all objects are signaled; all things that I didn't see in your implementation ;-) -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: undefined symbol: GetPrinterDataA
by gerard patel 26 Feb '01

26 Feb '01

At 08:30 PM 25/02/2001 +0600, you wrote: >I am trying to modify the Wine PostScript driver to use GetPrinterDataA >to read configuration information from the registry. I have added a >line that reads "import winspool.drv" to wineps.spec, and Wine builds >with no errors. When I try to run Wine, however, I get the following >error: > > BUILTIN32_dlopen failed to load .so lib for builtin wineps.dll: > /usr/lib/wine/libwineps.so: undefined symbol: GetPrinterDataA Note the differences between the Makefile for common dialog (where this works) and the Makefile for wineps : commdlg : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = comdlg32 ALTNAMES = commdlg EXTRALIBS = $(LIBUUID) LDDLLFLAGS = -Wl,-Bsymbolic SYMBOLFILE = $(MODULE).tmp.o (...) wineps : # Generated automatically from Makefile.in by configure. TOPSRCDIR = ../.. TOPOBJDIR = ../.. SRCDIR = . MODULE = wineps SOVERSION = 1.0 ALTNAMES = wineps16 IMPORTS = user32 gdi32 kernel32 ntdll C_SRCS = \ (...) I think that the mechanism is not working because dlls separation is not done for wineps ;-) Gerard

1 0

Re: undefined symbol: GetPrinterDataA
by Ian Pilcher 26 Feb '01

26 Feb '01

lawson_whitney(a)juno.com wrote: > > I think maybe you have created a new dependency and need to run make > depend again? If I understand the import mechanism, something > (winebuild?) generates stubs for the functions you import and ties them > in to the import mechanism, so they shouldn't be left hanging for ld.so > to choke on. They should resolve to .spec.o. It looks to me as if the > .spec didin't get rebuilt. > If only it were that simple. I've rebuilt from scratch, with a clean source tree. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

2 3

Re: various config files for various applications
by Alexandre Julliard 26 Feb '01

26 Feb '01

Martin Pilka <mpilka(a)codeweavers.com> writes: > another way could be have some additional (let's say > ~/.wine/app-config/1database.txt) file which will contain <regular > expression> --> <filename> mappings. that way wine have to open (and > read) only that file, and we're able to do that pretty fast (as i found > out when worked on registry patch). however, it has to evaluate all the > reg. expressions at runtime, but that is linear dependency. > > hmm, i don't know now. first letter or an additional file? This is getting way too complex IMO. I think having everything in the .wine/config file is much more reasonable; most people don't need that many different configurations anyway. What we should do is take advantage of the new config file format to create a deeper configuration hierarchy. So for instance the default x11drv config is under the registry key Wine\Config\x11drv, but we could create subtrees like Wine\Config\AppDefaults\Solitaire\x11drv which would contain the Solitaire-specific config values. This is then very fast to lookup, just try AppDefaults\<current module> and if not found fall back to the current method. I don't think we need regular expressions at all. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: Re: undefined symbol: GetPrinterDataA
by Eric Pouech 26 Feb '01

26 Feb '01

>wineps : > ># Generated automatically from Makefile.in by configure. >TOPSRCDIR = ../.. >TOPOBJDIR = ../.. >SRCDIR = . >MODULE = wineps >SOVERSION = 1.0 >ALTNAMES = wineps16 >IMPORTS = user32 gdi32 kernel32 ntdll in this case, just add winspool.drv to the IMPORT list in the Makefile.in, rerun configure, and it should work. (If Alexandre didn't convert the Makefile.in for dll separation, there should be some good reasons... like using non exported symbols... which would require much more work) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel