Re: RFC: Windows NT VDD
Andreas Mohr, > > OK, I just thought a followup on my own mail would be nice here to see > what I suggested before (see end of mail for the old text). > I was wondering what to do next. I didn't see anybody come to a conclusion on this idea so I left it rest. It takes somebody higher up than me to go about adding configuration variables > But now that I'm in the process of heavily rewriting CD-ROM labels and serials > and drive stuff, I thought "why not add this part, too ?". > > I think a very easy way to do this kind of stuff is using a new "BIOS" boolean flag. > And as we all know that floppies have BIOS (i.e. int 0x13) IDs of 0, 1, 2, ... > and HDDs have IDs of 0x80, 0x81, ..., the assignment is no problem at all. > And other wine.conf device types aren't available for BIOS IDs anyway. > > I.e. > > [Drive A] > Path=/dosa > Type=floppy > Label=FloppyA > Serial=87654321 > Device=/dev/fd0 > Filesystem=win95 > BIOS=1 > > [Drive B] > Path=/dosb > Type=floppy > Label=FloppyB > Device=/dev/fd1 > Filesystem=win95 > > [Drive C] > ;Path=/dosc > ;Path=/smb/roland/c > Path=/wine > Type=hd > Label=MS-DOS > Filesystem=win95 > BIOS=1 > > [Drive D] > Path=/dosd > Type=hd > Label=WINDOWS > Filesystem=win95 > > [Drive E] > Path=/dose > Type=hd > Label=LINUX-PORT > Filesystem=win95 > BIOS=1 > > would give us the following IDs for the drives: > A 0 (first floppy with a "BIOS" flag) > B -- > C 0x80 (we know it's "Type=hd") > D -- > E 0x81 ( "" ) > > So A would be the first "physical" BIOS floppy, whereas B wouldn't be > configured as a BIOS device; ok, it is a floppy, but it does NOT have a BIOS > flag. > Could be done. Maybe an auto setting to have wine detect the settings. Some of the data returned by int 0x13 requires knowing physical properties of the drive. Can the BIOS variable include this data or should wine go about faking the drive capacity and the like? > I don't think directly assigning BIOS IDs instead of just telling Wine to > assign BIOS IDs would be better. My original idea was automation to save the user configuration settings, but you seem to have the only comment and you're against it. Why not expand the ID in the config file to tell wine something usefull? What data do you want returned by INT 0x13? > OK, that way you could assign ID 0 to floppy B and ID 1 to floppy A (reversed), > but that could horribly break some programs and IMHO you don't have any > useful advantage. And of course you confuse newbies even more ;-) > Maybe it would break the programs. If we have a level of abstraction between Wine and the hardware, then we're in control of where the hardware appears to be. It's all virtual drives anyway. (Cable lengths in one of my system has my 5 1/4" drive set up as my A floppy and the 3 1/2" set as the B. Reversing this would have an advantage.) > OK, so much for this stuff. > > Now about the dangers of raw block writing: > I think we should assume that as soon as a [Drive X] has a "Device=" entry, > it can be used for DOS int 0x25/0x26 raw sector reads (given the accessability > of the device file, of course. Wine won't give a warning if it's not, BTW). > And as soon as a drive has a "BIOS=" entry, it can be used for BIOS int 0x13 > raw block device reads, too. > And now I suggest adding a "RawWrite=1" flag that tells Wine that writing > to the device via either DOS or BIOS access is allowed. Why not extend the BIOS flag to include this data? You've only had BIOS flags of 1 this far. > In case RawWrite is set to 1, I'd emit a BIG FAT WARNING upon EVERY Wine > startup telling that this could cause data loss. > Give the user the ability to shut off this warning . That would annoy some people a great deal after awhile. Default the warning to ON, but give it an off setting. > That's it. > > The only thing I need to know now is: > 1. Is this viable ? Please think of any problem you might see with that > assignment ! Think of many very different test cases. > 2. Do my new [Drive X] entries have good names or should that be changed ? > 3. Maybe it's not to have the DOS and BIOS writing configuration option > combined. Just tell me your opinion here. > I'd combine these two into a single flag. Since INT 0x13 does more than just return the type, drive size for example, it might be easiest to tell BIOS what to tell the program. It would also allow you to fake additional floppy drives when you need them and would be very usefull when you have more than one drive mapped to partitions on the same drive. -Robert 'Admiral' Coeyman -- http://www.corner.net/admiral/ May you live as long as you wish and age but a single day. [Telnet to telnet.corner.net]
problem with wineinstall script in wine 20000716
Greetings !
I am an experienced programmer but a newcomer to wine. Today I downloaded
wine 2716. I typed:
./tools/wineinstall
Sed reports a "bad substitution" at line 305 and again at line 326. The
output is below.
Thanks,
Bert Douglas
--
Searching for an existing Windows installation...
Windows was not found on your system, so I assume you want a Wine-only
installation.
Am I correct? (yes/no)
yes
Configuring Wine without Windows. Some fake Windows directories must be
created, to
hold any .ini files, DLLs, and start menu entries your applications may need
to install.
Where would you like your fake C drive to be placed? (default is /c)
Configuring Wine for a no-windows install in /c...
./tools/wineinstall: s/Path=\/c$/Path=${CROOT//\//\\/}/: bad substitution
Setting EXTRA_LD_LIBRARY_PATH in .winerc to /usr/local/lib/wine...
./tools/wineinstall:
s/EXTRA_LD_LIBRARY_PATH=.*/EXTRA_LD_LIBRARY_PATH=${DLLPATH//\//\\/}/: bad
substitution
Checking for real Windows registry...
Not found, default Wine registry will be installed.
Compiling regapi...
--
Re: `PFNGLCOLORTABLEEXTPROC' undeclared
Andreas Mohr wrote: > Hello Gerald ! > > On Wed, Jul 19, 2000 at 01:41:47PM +0200, Gerald Pfeifer wrote: > > One user reported a problem with an updated Wine port under FreeBSD, which > > I cannot reproduce: > > > > > -D_REENTRANT -D_THREAD_SAFE -I/usr/X11R6/include -o d3ddevice/mesa.o >d3ddevice/mesa.c > > > d3ddevice/mesa.c: In function `fill_device_capabilities': > > > d3ddevice/mesa.c:130: `PFNGLCOLORTABLEEXTPROC' undeclared (first use in this >function) > > > d3ddevice/mesa.c:130: (Each undeclared identifier is reported only once > > > d3ddevice/mesa.c:130: for each function it appears in.) > > > d3ddevice/mesa.c:130: syntax error before `glXGetProcAddressARB' > > > > Said user is running XFree 4.0 (not 4.0.1) on FreeBSD 5.0-CURRENT, and I > > found some discussion in the newsgroup: It seems that XFree 4.0 does not > > define that, so I guess we should not rely on it? > NO ! > I had the very same compile error and I do NOT run XF4 (336 here). > But I have to admit that I tweaked my Mesa/GLX setup a lot, > so it might show ;) > This happened after the last CVS upgrade, BTW. > Not adding --enable-opengl to ./configure "fixed" it. > Actually, I think there are some problems with the XFree 4.0 headers which cause this. You can easily fix it by grabbing the appropriate headers from 4.0.1 (which is how I fixed it). I am still running XF 4.0 though. > > > Any suggestion on how to fix this/workaround this problem (short of > > updating XFree)? > No idea. > I should have reported it, I know (*brownpaperbaghead*). > If you guys had checked the discussion on this two days ago between Lionel and I, you would have noticed it's already been fixed, grab the three files Wine needs out of XF 4.0.1 since the 4.0 ones are technically broken anyway. -Dave
process's name
WINE deals incorrectly with process's names. This prevents some
programs from working. I think that the bug is here:
scheduler/process.c:
static void PROCESS_Start( HMODULE main_module, LPSTR filename )
{
if (!filename)
{
/* if no explicit filename, use argv[0] */
if (!(filename = malloc( MAX_PATH ))) ExitProcess(1);
if (!GetLongPathNameA( full_argv0, filename, MAX_PATH ))
^^it is just
"/usr/local/bin/wine", why it is here?
lstrcpynA( filename, full_argv0, MAX_PATH );
}
And the function GetModuleFileName16 always returns
"/usr/local/bin/wine" because when WINE creates 16-bit process, it
calls PROCESS_Start like this:
SYSLEVEL_EnterWin16Lock();
PROCESS_Start( main_module, NULL );
This causes the problem, why not
main_exe_name here?
And when creating 32-bit process, it does
if (main_module) PROCESS_Start( main_module, main_exe_name );
^^^No problems here.
My fix was to replace this NULL with main_exe_name for 16-bit processes
too. It works for me. Can anyone fix it properly or just explain the
situation? Is this replacement correct?
Re: Symbols
Robert Bierman wrote: > Thank you for responding, but the problem is that we are still compiling > the product on Windows. So this is a Windows executable. I can generate a > .MAP file and do Map2Sym to generate a .SYM file, but how do I get WINE to > use them and give me symbols upon a crash? Well, Wine is supposed to use CodeView debug information from the executable or the appropriate .PDB file. If this doesn't work, I'd like to have a look at it ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Symbols
Eric, Thank you for responding, but the problem is that we are still compiling the product on Windows. So this is a Windows executable. I can generate a .MAP file and do Map2Sym to generate a .SYM file, but how do I get WINE to use them and give me symbols upon a crash? Thank you, Robert Bierman UserLand Software At 10:17 PM 7/19/2000, Eric Pouech wrote: >Robert Bierman wrote: > > > > Hello, my name is Robert Bierman and I am porting Frontier > > (http://frontier.userland.com) to Linux. I am just starting and need to > > know how to get my program symbols to show when the program crashes. >read documentation/winedbg for more info on debugging >for your app symbols, you just need to recompile it with gcc and debugginng >information enabled (-g) >then everything should be wine. >however, current CVS is broken wrt symbol loading. A patch has been submitted >but hasn't been applied yet to the CVS tree (2716 should be broken too) > >A+ >-- >--- >Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) >"The future will be better tomorrow", Vice President Dan Quayle
Re: Backing store option. (painting optimization)
On Wed, 19 Jul 2000, Stephane Lussier wrote: > I'll be very surprise that nobody has never thought of setting this flag > before, so I suspect there's some good reason to setting it to "NotUseful", Well, if someone had considered that, he would have added a comment on why this does not work, wouldn't he? :-> (Seriously, if there are really some reasons not to do that, we should document them.) Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ Have a look at http://petition.eurolinux.org -- it's not about Linux, btw!
Re: message queue problem
At 10:02 PM 7/18/00 +0200, you wrote:
>There's a problem in the current message queue code, which shows up in
>games (and probably some installers too?)... it doesn't accept mouse input
>before the user has hit a key at least once.
>
>I've tracked it down to the message queue code, this condition:
>
>warn:msg:QUEUE_WakeSomeone couldn't find queue
>
>and this happens because QUEUE_WakeSomeone looks through all queues to
>find a queue with an appropriate wake mask, then sets its wake bits to
>wake it up. But the application is in a PeekMessage loop, so it never
>waits, and so no wake masks are set, so QUEUE_WakeSomeone can't do
>anything. Furthermore, PeekMessage only retrieves hardware events if the
>queue's wake bits are set, and since QUEUE_WakeSomeone didn't set any
>queue's wake bits, nothing happens. All mouse events just get queued but
>never read out before something else happens... (like the user hitting a
>key instead, but I don't know why keypresses don't also get stuck, or why
>mouse events work afterwards.)
[first I CC'ed my previous reply to wine-patches; big mistake of course]
Could the following hack change anything in your problem
(for the worse, of course :-); the idea is to not allow keyboard
messages for disabled windows)
--- message.c.orig Sun Jul 16 09:06:11 2000
+++ message.c Thu Jul 20 22:30:18 2000
@@ -382,6 +382,7 @@
if( message < WM_SYSKEYDOWN )
message += WM_SYSKEYDOWN - WM_KEYDOWN;
}
+if (!IsWindowEnabled(WIN_GetTopParent(hWnd))) hWnd = 0;
pWnd = WIN_FindWndPtr( hWnd );
if (pWnd && (pWnd->hmemTaskQ != GetFastQueue16()))
{
Gerard
Re: Windows system DLLs without Windows installation
Hello David ! On Thu, Jul 20, 2000 at 01:14:04PM +0100, David Howells wrote: > Can you instead construct a system32 directory and populate it with symlinks > to appropriate wine DLL replacements, for example: > >ln -s /opt/wine/lib/libshell32.so /opt/wine/share/system32/shell32.dll > > The people can dynamically load them for resources or code without wine having > to anything more special than check the magic number on the front of the DLL > to see what type it is. > > David Howells Sure, that's what I'll be working on soon. However most probably that won't be libraries (.so), but rather completely new NE or PE "fake DLLs" with a complete header and version resources. Andreas Mohr
Re: `PFNGLCOLORTABLEEXTPROC' undeclared
Hello Gerald ! On Wed, Jul 19, 2000 at 01:41:47PM +0200, Gerald Pfeifer wrote: > One user reported a problem with an updated Wine port under FreeBSD, which > I cannot reproduce: > > > -D_REENTRANT -D_THREAD_SAFE -I/usr/X11R6/include -o d3ddevice/mesa.o >d3ddevice/mesa.c > > d3ddevice/mesa.c: In function `fill_device_capabilities': > > d3ddevice/mesa.c:130: `PFNGLCOLORTABLEEXTPROC' undeclared (first use in this >function) > > d3ddevice/mesa.c:130: (Each undeclared identifier is reported only once > > d3ddevice/mesa.c:130: for each function it appears in.) > > d3ddevice/mesa.c:130: syntax error before `glXGetProcAddressARB' > > Said user is running XFree 4.0 (not 4.0.1) on FreeBSD 5.0-CURRENT, and I > found some discussion in the newsgroup: It seems that XFree 4.0 does not > define that, so I guess we should not rely on it? NO ! I had the very same compile error and I do NOT run XF4 (336 here). But I have to admit that I tweaked my Mesa/GLX setup a lot, so it might show ;) This happened after the last CVS upgrade, BTW. Not adding --enable-opengl to ./configure "fixed" it. > Any suggestion on how to fix this/workaround this problem (short of > updating XFree)? No idea. I should have reported it, I know (*brownpaperbaghead*). Andreas Mohr
`PFNGLCOLORTABLEEXTPROC' undeclared
One user reported a problem with an updated Wine port under FreeBSD, which I cannot reproduce: > -D_REENTRANT -D_THREAD_SAFE -I/usr/X11R6/include -o d3ddevice/mesa.o >d3ddevice/mesa.c > d3ddevice/mesa.c: In function `fill_device_capabilities': > d3ddevice/mesa.c:130: `PFNGLCOLORTABLEEXTPROC' undeclared (first use in this >function) > d3ddevice/mesa.c:130: (Each undeclared identifier is reported only once > d3ddevice/mesa.c:130: for each function it appears in.) > d3ddevice/mesa.c:130: syntax error before `glXGetProcAddressARB' Said user is running XFree 4.0 (not 4.0.1) on FreeBSD 5.0-CURRENT, and I found some discussion in the newsgroup: It seems that XFree 4.0 does not define that, so I guess we should not rely on it? Any suggestion on how to fix this/workaround this problem (short of updating XFree)? Gerald
Re: RFC: Windows NT VDD
Hi all, OK, I just thought a followup on my own mail would be nice here to see what I suggested before (see end of mail for the old text). But now that I'm in the process of heavily rewriting CD-ROM labels and serials and drive stuff, I thought "why not add this part, too ?". I think a very easy way to do this kind of stuff is using a new "BIOS" boolean flag. And as we all know that floppies have BIOS (i.e. int 0x13) IDs of 0, 1, 2, ... and HDDs have IDs of 0x80, 0x81, ..., the assignment is no problem at all. And other wine.conf device types aren't available for BIOS IDs anyway. I.e. [Drive A] Path=/dosa Type=floppy Label=FloppyA Serial=87654321 Device=/dev/fd0 Filesystem=win95 BIOS=1 [Drive B] Path=/dosb Type=floppy Label=FloppyB Device=/dev/fd1 Filesystem=win95 [Drive C] ;Path=/dosc ;Path=/smb/roland/c Path=/wine Type=hd Label=MS-DOS Filesystem=win95 BIOS=1 [Drive D] Path=/dosd Type=hd Label=WINDOWS Filesystem=win95 [Drive E] Path=/dose Type=hd Label=LINUX-PORT Filesystem=win95 BIOS=1 would give us the following IDs for the drives: A 0 (first floppy with a "BIOS" flag) B -- C 0x80 (we know it's "Type=hd") D -- E 0x81 ( "" ) So A would be the first "physical" BIOS floppy, whereas B wouldn't be configured as a BIOS device; ok, it is a floppy, but it does NOT have a BIOS flag. I don't think directly assigning BIOS IDs instead of just telling Wine to assign BIOS IDs would be better. OK, that way you could assign ID 0 to floppy B and ID 1 to floppy A (reversed), but that could horribly break some programs and IMHO you don't have any useful advantage. And of course you confuse newbies even more ;-) OK, so much for this stuff. Now about the dangers of raw block writing: I think we should assume that as soon as a [Drive X] has a "Device=" entry, it can be used for DOS int 0x25/0x26 raw sector reads (given the accessability of the device file, of course. Wine won't give a warning if it's not, BTW). And as soon as a drive has a "BIOS=" entry, it can be used for BIOS int 0x13 raw block device reads, too. And now I suggest adding a "RawWrite=1" flag that tells Wine that writing to the device via either DOS or BIOS access is allowed. In case RawWrite is set to 1, I'd emit a BIG FAT WARNING upon EVERY Wine startup telling that this could cause data loss. That's it. The only thing I need to know now is: 1. Is this viable ? Please think of any problem you might see with that assignment ! Think of many very different test cases. 2. Do my new [Drive X] entries have good names or should that be changed ? 3. Maybe it's not to have the DOS and BIOS writing configuration option combined. Just tell me your opinion here. My old suggestions: On Wed, Jun 28, 2000 at 10:51:58AM +0200, Andreas Mohr wrote: > I´ve been wasting many thoughts on this and I still don´t know > how to implement this wine.conf-wise. > Technically, it´s no problem at all to implement it; the only real > problem is how to solve the BIOS drive assignment > (i.e. how to indicate that such-and-such drive can be safely > written to/read from). > Perhaps we should just introduce an additional parameter called > BiosID=XXX for every [Drive X] that says 0x0 and 0x1 > for the floppies and 0x80, ... for the HDDs ? > Of course the Dev= entry has to be existing for these [Drive X] > entries in this case... > > I guess that´s the way to go. > Of course that means that it´s each individual user´s own problem if > he dares to assign a BiosID= for a Drive entry... > After all it can destroy file systems that way (which often is > exactly what you want when using int 0x13 functions). > > Again, implementing that should be NO problem at all... > (a matter of few hours, definitely not days) > > I guess we could even go as far as print a warning on EVERY > Wine startup that says something like: > "Warning ! Wine detected at least one BiosID= entry in your > config file. This might lead to formatted file systems. > However, this warning is non-critical; we just want to inform you > of the implications this setting has." Andreas Mohr
Backing store option. (painting optimization)
Hi, Is there a reason why we're setting the "backing_store" attribute to "NotUseful" at the creation of a X window? Setting it to "WhenMapped" increase significantly the refresh rate when moving or resizing a window (see the patch below). I understand that it will take more memory using this option, but I'm more concerned with the fact that it could cause some side effects with some applications. I'll be very surprise that nobody has never thought of setting this flag before, so I suspect there's some good reason to setting it to "NotUseful", anybody can tell me why? Stephane Lussier Macadamian Technologies Index: windows/x11drv/wnd.c === RCS file: /home/wine/wine/windows/x11drv/wnd.c,v retrieving revision 1.50 diff -u -r1.50 wnd.c --- windows/x11drv/wnd.c2000/07/10 12:09:32 1.50 +++ windows/x11drv/wnd.c2000/07/19 13:11:28 @@ -295,7 +308,7 @@ win_attr.bit_gravity = (classPtr->style & (CS_VREDRAW | CS_HREDRAW)) ? BGForget : BGNorthWest; win_attr.colormap = X11DRV_PALETTE_PaletteXColormap; - win_attr.backing_store = NotUseful; + win_attr.backing_store = WhenMapped; win_attr.save_under= ((classPtr->style & CS_SAVEBITS) != 0); win_attr.cursor= X11DRV_MOUSE_XCursor;
MFC
Hi, With all the talk of compiling MFC with Wine, i was wondering does anybody know of any alternate implementations of MFC out there? Open source? Guessing that the answer is no, would it be sane to try to write an open source implementation of MFC? Would there be any legal issues? Implementation issues? Is it just plain easier to use the ms implementation? i guess, considering the nature of C++, the implementation would have to be _very_ similar to the original. It probably wouldn't have to be binary compatible though. Mike -- mailto:[EMAIL PROTECTED] ph +86 10 6232 8639 (til 20 July 2000) +61 2 9427 2196 (after 20 July 2000) __ Get your own free web email at http://www.looksmart.com.au LookSmart Australia
Re: icontitle fix
On Tue, Jul 18, 2000 at 04:08:06AM -0600, gerard patel wrote: > The kind of problem really obvious once you have found it :-/ Tell me about it. I've just spent far too long rediscovering this bug ;-) Huw.
Re: FormatMessage() patch
On Wed, 19 Jul 2000, Dmitry Timoshkov wrote: >Dave Pickles <[EMAIL PROTECTED]> wrote: > >> Attached my patch to implement the FORMAT_MESSAGE_FROM_SYSTEM variant of >> FormatMessage(). >I would suggest to have the common kernel32_rc.rc that will include >all other resource files: > >#include "locale_rc.rc" >#include "winerr_enu.rc" > >etc. > >Dmitry. Ah of course! That would be much more elegant. I'll redo the patch. Dave
wineps.drv not found?
Hello,
I've been running QuickBooks 5 for a while now with few problems. At the
same time, I try to do weekly builds out of the WINE CVS tree to see how
support for some applications is doing. Recently, when I try to print
from QB, WINE tells me:
err:module:BUILTIN_LoadModule loaded .so but dll WINEPS.DRV still not
found
along with an application error telling me that there is a problem with
WINEPS.DRV. Unfortunately, the last time I tried printing was May 23, so
I don't know which update caused this. I've noticed that the driver has
recently been moved out of the core, but the documentation would seem to
be lagging if in fact something different has to happen.
-debugmsg +relay shows
Call KERNEL.95: LOADLIBRARY(0x0277be72 "WINEPS.DRV") ret=08af:122c ds=09cf
and +elfdll
trace:elfdll:ELFDLL_dlopen Trying
dlopen('/home/sean/wine/cvs/lib/libwineps.drv.so', 2)
err:module:BUILTIN_LoadModule loaded .so but dll WINEPS.DRV still not
found
(which is weird, because there is no /home/sean/wine directory). As a
guess, I copied /usr/local/lib/libwineps.so to
/home/sean/wine/cvs/lib/libwineps.drv.so, but nothing.
I've got
[dlloverrides]
wineps = builtin
in ~/.winerc and win.ini has
[PrinterPorts]
Wine PostScript Driver=WINEPS,LPT1:,15,45
[windows]
device=Wine PostScript Driver,WINEPS,LPT1:
[devices]
Wine PostScript Driver=WINEPS,LPT1:
(the PrinterPorts entry is new, I saw it the news group and thought it
might help but no luck)
Any help or pointers would be appreciated.
Thanks,
Sean
Sean A. Walberg <[EMAIL PROTECTED]> http://www.ertw.com
Re: Symbols
Robert Bierman wrote: > > Hello, my name is Robert Bierman and I am porting Frontier > (http://frontier.userland.com) to Linux. I am just starting and need to > know how to get my program symbols to show when the program crashes. read documentation/winedbg for more info on debugging for your app symbols, you just need to recompile it with gcc and debugginng information enabled (-g) then everything should be wine. however, current CVS is broken wrt symbol loading. A patch has been submitted but hasn't been applied yet to the CVS tree (2716 should be broken too) A+ -- --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
Windows system DLLs without Windows installation
[Wine Weekly News] > System DLLs > > The Wine team has determined that it is necessary to create fake DLL files to > trick many applications that check for file existence to determine whether a > particular feature (such as Winsock and its TCP/IP networking) is > available. If this is a problem for you, you can create empty files in the > "system" directory to make the application think it's there, and Wine's > built-in DLL will be loaded when the application actually asks for it. > (Unfortunately, tools/wineinstall does not create such empty files itself.) > > Applications sometimes also try to inspect the version resources from the > physical files (for example, to determine the DirectX version). Empty files > will not do in this case, it is rather necessary to install files with > complete version resources. This problem is currently being worked on. In the > meantime, you may still need to grab some real DLL files to fool these apps > with. > ... Can you instead construct a system32 directory and populate it with symlinks to appropriate wine DLL replacements, for example: ln -s /opt/wine/lib/libshell32.so /opt/wine/share/system32/shell32.dll The people can dynamically load them for resources or code without wine having to anything more special than check the magic number on the front of the DLL to see what type it is. David Howells
Re: Sawfish issues with menus, comboboxes, etc.
> So my question is, where do I have to go to fix this problem. I assume it > has something to do with x11drv needing to grab the mouse when displaying > pop-ups like menus and comboboxes. There has been a lot of work done in the Corel tree lately for better support of the various window managers. The work has focused on the Z-order, raising of windows, and the decoration of dockers and flyout tool bars. Take a look at winpos.c and x11drv/expose.c Hope this helps, Jason Mawdsley Macadamian Technologies
