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

ReadFile() and WriteFile() choke on non-zero lpOverlapped.

by Eric Kohl

Hello! I'm currently debugging a database-application that uses the M$ Jet Engine 3.5. This db-engine does not behave very well. It opens an exisisting database-file (FILE_FLAG_OVERLAPPED is *not* set) and reads or writes using calls to ReadFile() and WriteFile() with non-zero lpOverlapped pointers. In this case calls to ReadFile() or WriteFile() return FALSE. IMO ReadFile() and WriteFile() should check whether FILE_FLAG_OVERLAPPED is set. Unfortunately there is no method to retrieve the full file attributes from wineserver. Is a new server call required? Best regards, Eric Kohl

Feb. 3, 2001

ReadFile() and WriteFile() choke on non-zero lpOverlapped.

by Eric Kohl

Hello! I'm currently debugging a database-application that uses the M$ Jet Engine 3.5. This db-engine does not behave very well. It opens an exisisting database-file (FILE_FLAG_OVERLAPPED is *not* set) and reads or writes using calls to ReadFile() and WriteFile() with non-zero lpOverlapped pointers. In this case calls to ReadFile() or WriteFile() return FALSE. IMO ReadFile() and WriteFile() should check whether FILE_FLAG_OVERLAPPED is set. Unfortunately there is no method to retrieve the full file attributes from wineserver. Is a new server call required? Best regards, Eric Kohl

Feb. 3, 2001

Re: psdrv: map Courier New to Courier

by Ian Pilcher

Huw D M Davies wrote: > > OK, I've just submitted G|SetPrinterData implementations to > wine-patches - please use these instead of direct Reg apis. (it should > make life easier anyway. > I cannot get this patch to apply. I've tried it with a CVS pull from earlier today and one from 1/29. With both, I get: patching file include/winspool.h Hunk #1 FAILED at 957. 1 out of 1 hunk FAILED -- saving rejects to file include/winspool.h.rej patching file dlls/winspool/info.c Hunk #1 FAILED at 73. 1 out of 3 hunks FAILED -- saving rejects to file dlls/winspool/info.c.rej patching file dlls/winspool/winspool.drv.spec Am I missing a prerequisite patch? (I did have to cut & paste this out of the HTML archive using Netscape, but it looks OK.) -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 3, 2001

Re: psdrv: map Courier New to Courier

by Ian Pilcher

Huw D M Davies wrote: > > Great! Well the Windows 2000 PS driver stores the font sub table > under the value name "TTFontSubTable" in the printer driver's > PrinterDriverData registry key. To do this we need to implement > Get/SetPrinterData (if you give me a couple of days I'll do it). The > data associated with TTFontSubTable is just a set of 2n \0 > terminated strings the final one terminated by 2 \0 > (i.e. REG_MULTISZ). The actual configuring should go on in the > printer setup property sheet. Hmmm, fancy learning a little of the > Win32 api? > I just spent some time poking around in the Registry of my Windows 2000 system. Neither "TTFontSubTable" or "FontSubTable" appears anywhere. (I have printers installed that use both the Adobe and Microsoft Post- Script drivers.) In fact, when I searched on "Helvetica" the only things I found that looked like font substitution tables were under HKCU\Software\Microsoft\ Shared Tools\Font Mapping and HKLM\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\FontSubstitutes. Another point of interest -- none of the printer properties dialogs seem to allow me to configure the font substitution, even though I have "TrueType Font: Substitute with Device Font" set in the Advanced Options of the Apple LaserWriter 12/640 PS driver. > > OK, I've just submitted G|SetPrinterData implementations to > wine-patches - please use these instead of direct Reg apis. (it should > make life easier anyway. > > You basically want > > HANDLE hprn; > OpenPrinterA("Wine PostScript Driver", &hprn, NULL); > SetPrinterDataA(hprn, "FontSubTable" /*or whatever*/, REG_MULTI_SZ, pData, size); > ClosePrinter(hprn); > > where pData is a list of \0 terminated strings that make up the table, > finally terminated by a double \0. > > Reading the data back is almost the same using GetPrinterDataA So is "FontSubTable" what we want to use? It should be easy enough for me to have the driver use GetPrinterData and set up a simple array when it is initialized. (Although it does seem a little weird to have the driver calling OpenPrinter; is this OK?) > > I think we should also allow the Wine config file to override what's > > in the registry. > > Not really convinced about this. I'd like to move all of the psdrv > stuff out of the config file (which afterall is just a bit of the > registry) into its correct place under > HKLM\System\CurrentControlSet\Control\Printers\Print > The configuration should all be done via a GUI control. Two points: 1) How can a user get this information into the Registry until the GUI control is written? (I hope you weren't thinking that this is some- think I'm capable of doing. Me stupid procedural guy; OO GUI stuff make head feel oogey!) 2) Just because people use Wine to run Windows applications, doesn't mean that they've bought into the "everything should be GUI" philosophy; some of us actually *like* ASCII configuration files. > > In the old style, I would have suggested something of the form: > > > > Windows Font = X LFD, PostScript font name > > > > This would seem to be relatively straightforward to implement, and it > > would bring a small measure of sanity to the area. (I currently have > > both 'MS Sans Serif' and 'Ms Sans Serif' fonts, because the X server and > > the PostScript driver don't agree on what the font should be called!) > > This should all be a lot easier when I get a FreeType engine bolted on > to gdi. Then psdrv,x11drv,ttydrv(?) will all have access to the same > data and thus consistancy should not be a problem. I actually see a manual font configuration as a *very* small step in this direction. At least it will let Wine control it's view of what fonts are available, rather than trying to make intelligent guesses based on the X font list and the PostScript driver. It does assume a certain intelligence on the user's part; mapping the core Windows fonts to X fonts that aren't installed on the system would be "bad", but it shouldn't be too hard to supply a reasonable default configuration. -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 3, 2001

wine-patches working?

by Ian Pilcher

Is anyone else not getting stuff that's sent to wine-patches? -- ======================================================================== Ian Pilcher pilcher(a)concentric.net ========================================================================

Feb. 3, 2001

Re: Notes and Java test on 20010112.

by David.Goodenough＠dga.co.uk

Well the good news is that this patch does indeed fix the Callout problem. Unfortunately we are then back to the original font problem, where (at least with the Sun JRE) we just get black squares instead of characters. The IBM JRE still has problems and never even displays the frame for the characters, let alone the characters. But this may still be due to the same underlying problem. Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> on 28-01-2001 11:43:03 PM To: gerard.patel(a)asi.fr (gerard patel) cc: David Goodenough/DGA/GB, wine-devel(a)winehq.com Subject: Re: Notes and Java test on 20010112. Gerard Patel wrote: > I did not include the trace as it's rather large (I can mail it to you > if you want...) but what happens is clear enough : the main exe loads > implicitely KERNEL32 but not USER - USER is loaded implicitely > by a DLL loaded by LoadLibrary. > So when the kernel initialisation is done, USER is not yet loaded. > It's unusual but seems perfectly valid IMO. > > What about adding a specific Wine call from User to Kernel to trigger the > initialization when USER is loaded ? (maybe there is already an > undocumented one - you are the undisputed master here :-)) Hmmm. Strictly speaking, if an app dynamically loads USER, it can also dynamically *unload* USER; we'd have to take care that we invalidate the Callout pointers if this happens. What do you think about the following solution? It just checks whenever any DLL is loaded or unloaded, whether the Callout pointers need to be updated ... Bye, Ulrich diff -ur wine-cvs/if1632/thunk.c wine-uw/if1632/thunk.c --- wine-cvs/if1632/thunk.c Wed Jan 3 22:51:30 2001 +++ wine-uw/if1632/thunk.c Mon Jan 29 00:35:49 2001 @@ -166,7 +166,7 @@ NE_MODULE *pModule; hModule = GetModuleHandleA( "user32.dll" ); - if ( hModule ) + if ( hModule && !Callout.PeekMessageA ) { #define GETADDR( name ) \ *(FARPROC *)&Callout.name = GetProcAddress( hModule, #name ) @@ -185,10 +185,24 @@ GETADDR( MessageBoxW ); #undef GETADDR } - else WARN("no 32-bit USER\n"); + if ( !hModule && Callout.PeekMessageA ) + { + Callout.PeekMessageA = NULL; + Callout.GetMessageA = NULL; + Callout.SendMessageA = NULL; + Callout.PostMessageA = NULL; + Callout.TranslateMessage = NULL; + Callout.DispatchMessageA = NULL; + Callout.RedrawWindow = NULL; + Callout.WaitForInputIdle = NULL; + Callout.MsgWaitForMultipleObjects = NULL; + Callout.WindowFromDC = NULL; + Callout.MessageBoxA = NULL; + Callout.MessageBoxW = NULL; + } pModule = NE_GetPtr( GetModuleHandle16( "USER.EXE" ) ); - if ( pModule ) + if ( pModule && !Callout.FinalUserInit16 ) { #define GETADDR( var, name, thk ) \ *(FARPROC *)&Callout.var = THUNK_GetCalloutThunk( pModule, name, \ @@ -201,5 +215,12 @@ GETADDR( UserSignalProc, "SignalProc32", word_lllw ); #undef GETADDR } - else WARN("no 16-bit USER\n"); + if ( !pModule && Callout.FinalUserInit16 ) + { + Callout.FinalUserInit16 = NULL; + Callout.InitThreadInput16 = NULL; + Callout.UserYield16 = NULL; + Callout.DestroyIcon32 = NULL; + Callout.UserSignalProc = NULL; + } } diff -ur wine-cvs/loader/module.c wine-uw/loader/module.c --- wine-cvs/loader/module.c Tue Jan 16 00:29:27 2001 +++ wine-uw/loader/module.c Mon Jan 29 00:30:20 2001 @@ -1432,6 +1432,9 @@ /* decrement the dependencies through the MODULE_FreeLibrary call. */ pwm->refCount++; + /* Update the kernel Callout tables */ + THUNK_InitCallout(); + RtlReleasePebLock(); SetLastError( err ); /* restore last error */ HeapFree ( GetProcessHeap(), 0, filename ); @@ -1526,6 +1529,9 @@ HeapFree( GetProcessHeap(), 0, wm->short_filename ); HeapFree( GetProcessHeap(), 0, wm ); } + + /* Update the kernel Callout tables */ + THUNK_InitCallout(); } /*********************************************************************** diff -ur wine-cvs/miscemu/main.c wine-uw/miscemu/main.c --- wine-cvs/miscemu/main.c Wed Jan 10 02:42:49 2001 +++ wine-uw/miscemu/main.c Mon Jan 29 00:36:05 2001 @@ -34,7 +34,6 @@ MESSAGE( "Cannot load user32.dll\n" ); ExitProcess( GetLastError() ); } - THUNK_InitCallout(); if ((instance = NE_StartMain( main_exe_name, main_exe_file )) < 32) { diff -ur wine-cvs/scheduler/process.c wine-uw/scheduler/process.c --- wine-cvs/scheduler/process.c Sun Jan 28 18:58:09 2001 +++ wine-uw/scheduler/process.c Mon Jan 29 00:36:17 2001 @@ -346,9 +346,6 @@ MODULE_DllProcessAttach( NULL, (LPVOID)1 ); RtlReleasePebLock(); - /* Get pointers to USER routines called by KERNEL */ - THUNK_InitCallout(); - /* Call FinalUserInit routine */ if (Callout.FinalUserInit16) Callout.FinalUserInit16(); -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

Feb. 2, 2001

Re: psdrv: map Courier New to Courier

by Huw D M Davies

On Thu, Feb 01, 2001 at 11:19:31PM +0600, Ian Pilcher wrote: > I think I can probably handle reading the registry. (Although from > what little I've seen of the Win32 API, even that could be a night- > mare.) OK, I've just submitted G|SetPrinterData implementations to wine-patches - please use these instead of direct Reg apis. (it should make life easier anyway. You basically want HANDLE hprn; OpenPrinterA("Wine PostScript Driver", &hprn, NULL); SetPrinterDataA(hprn, "FontSubTable" /*or whatever*/, REG_MULTI_SZ, pData, size); ClosePrinter(hprn); where pData is a list of \0 terminated strings that make up the table, finally terminated by a double \0. Reading the data back is almost the same using GetPrinterDataA > I think we should also allow the Wine config file to override what's > in the registry. Not really convinced about this. I'd like to move all of the psdrv stuff out of the config file (which afterall is just a bit of the registry) into its correct place under HKLM\System\CurrentControlSet\Control\Printers\Print The configuration should all be done via a GUI control. > Which leads me to another, more dangerous, thought. It seems to me that > life would be simpler for everyone if we could bring some consistency to > the way that Wine's display and print subsystems work with fonts. What > about a section in the configuration file that related Windows, X, and > PostScript font names? > > In the old style, I would have suggested something of the form: > > Windows Font = X LFD, PostScript font name > > This would seem to be relatively straightforward to implement, and it > would bring a small measure of sanity to the area. (I currently have > both 'MS Sans Serif' and 'Ms Sans Serif' fonts, because the X server and > the PostScript driver don't agree on what the font should be called!) This should all be a lot easier when I get a FreeType engine bolted on to gdi. Then psdrv,x11drv,ttydrv(?) will all have access to the same data and thus consistancy should not be a problem. Huw.

Feb. 2, 2001

Re: psdrv: map Courier New to Courier

by Dmitry Timoshkov

Gavriel State <gav(a)transgaming.com> wrote: >It's at http://opensource.corel.com > >It hasn't been updated in quite a while, and the last import from >WineHQ was back in December '99, I believe. In addition to the >font/printing work, there may still be a few other outstanding fixes >that haven't made it into the Wine tree - but the only way to tell >is probably going to be manual inspection of the diffs. Yes, this is a pain to do for instance cvs log -N corelwine/windows/defwnd.c >defwnd.c.log then inspect it for some interesting log message, then do cvs log -N -r1.3 corelwine/windows/defwnd.c >defwnd.c.patch cvs diff -u -r 1.2 -r 1.3 corelwine/windows/defwnd.c >>defwnd.c.patch especially if the patch actually changed several files.

Feb. 2, 2001

Re: psdrv: map Courier New to Courier

by Gavriel State

Ian Pilcher wrote: > > This may be a stupid question, but where is the Corel Wine tree? It's at http://opensource.corel.com It hasn't been updated in quite a while, and the last import from WineHQ was back in December '99, I believe. In addition to the font/printing work, there may still be a few other outstanding fixes that haven't made it into the Wine tree - but the only way to tell is probably going to be manual inspection of the diffs. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

Feb. 2, 2001

Re: psdrv: map Courier New to Courier

by James Abbatiello

Ian Pilcher wrote: > Gavriel State wrote: > >> Just FYI, the corelwine tree has support for psdrv font mapping that >> you might be able to use - it uses the wine config file rather than >> the registry to store font aliases, but as I recall it was a pretty >> minor change in the psdrv code. >> > > > This may be a stupid question, but where is the Corel Wine tree? http://opensource.corel.com/ -- James Abbatiello

Feb. 2, 2001