Problems running wine.
Hi all.
I have been trying to get the CVS version of wine up
and running but I am having no luck. When I try to
run my program under wine, I get an error like this:
trace:heap:HeapAlloc (4041,0002,0018): returning 40413414
warn:thread:THREAD_InitStack Thread stack size is 32 MB.
trace:virtual:VirtualAlloc 02027000 1000 0040
0805f458: terminate_process( handle=-1, exit_code=14 )
0805f458: terminate_process() = 0 { self=1 }
0805f458: *killed* exit_code=14
/home/mo/.wine/user.reg: saving key USER\\mo
/home/mo/.wine/system.reg: saving key MACHINE
mo(/mnt/image/win_root/Tcl_Xmingw/bin)% /home/mo/.wine/userdef.reg:
saving key USER\\.Default
/home/mo/.wine/wine.userreg: saving key USER
I figured that was a memory problem so I added some
more swap space and ran it again, that seemed to work
a little better, but it broke like so:
trace:heap:HeapFree (4041,0002,40423f24): returning TRUE
trace:heap:HeapFree (4041,0002,40423f00): returning TRUE
trace:module:MODULE_InitDLL (0x40423e6c,PROCESS_DETACH,0x1) - RETURN 1
trace:module:MODULE_InitDLL (KERNEL32.dll,PROCESS_DETACH,0x1) - CALL
trace:relay:PE_InitDLL
CallTo32(entryproc=0x4057916c,module=40574000,type=0,res=0x1)
trace:module:MODULE_InitDLL (0x40411fec,PROCESS_DETACH,0x1) - RETURN 1
trace:module:MODULE_InitDLL (ntdll.dll,PROCESS_DETACH,0x1) - CALL
trace:module:MODULE_InitDLL (0x40412150,PROCESS_DETACH,0x1) - RETURN 1
0805f458: terminate_process( handle=-1, exit_code=0 )
0877d5a0: *killed* exit_code=0
0805f458: terminate_process() = 0 { self=1 }
0805f458: *killed* exit_code=0
Does anyone know what is going one here?
I am trying to test out code that I created using mingw
to cross compile windows applications under Linux. I
do not need to test everything, I just want to run
the thing in wine as a sanity check for the compiler.
If wine really works well, I may end up running regression tests
for the windows application under wine. That would
be cool because I would not need to boot into windows.
This could also be a really good way to test out wine
itself. I will post more on that later if I get it working.
thanks
Mo DeJong
Red Hat Inc
Civ 2
Well in my continued quest to get Civilization 2 working on Linux and Wine, I thought I'd ask some questions on the latest debug output I've got. I've noticed that Civ2 as its dieing is trying to post an error message box and I also noticed that at around the point where all goes wrong, the ds get changed from 0x0897 to 0x. While I don't understand this all 100%, it seems to be a part of the problem. A CreateWindow16 call is made but the two strings at the start or the args have the addresses 0x1e02 and 0x1e01 but these addresses look to be too low. I can find a previous CreateWindow16 call that has the addresses that look right of 0x08971e02 and 0x08971e01 and this is what got me looking at just what was set to 0x897 and when it gets changed. The change happens in a call to SetErrorMode and I think thats the whole problem. Civ2 is using SetErrorMode(SEM_FAILCRITICALERRORS) which from what I understand it supposed to stop Windows from handling critical errors and instead to send them directly to the application. In looking around in Wine, this doesn't seem to be supported. While the call to SetErrorMode will set the error_mode in the task and/or process structures, nothing uses it. Is there any hope of SetErrorMode functioning properly? Anyway - here is a bit of the debug output that I hope illuminates the problem enough to make sense to someone else so that I can either get pointed in the right direction or given a clue as to what could be wrong. Here is where I think things are starting to go wrong. Of course it could be that something earlier has trashed some memory or something but this is where ds suddenly changes to 0x and there is a bogus CreateWindow16 call followed immediately by the MessageBoxA with an exception. Any clues as to why ds would suddenly change? Ret USER.53: DESTROYWINDOW() retval=0x0001 ret=03bf:0fe9 ds=0897 Call KERNEL.107: SETERRORMODE(0x) ret=03bf:0ff1 ds=0897 Ret KERNEL.107: SETERRORMODE() retval=0x0001 ret=03bf:0ff1 ds=0897 Call KERNEL.107: SETERRORMODE(0x0001) ret=03bf:0e75 ds= Ret KERNEL.107: SETERRORMODE() retval=0x ret=03bf:0e75 ds= Call USER.133: GETWINDOWWORD(0x01b4,0xfffa) ret=03bf:0eb3 ds= Ret USER.133: GETWINDOWWORD() retval=0x0896 ret=03bf:0eb3 ds= Call USER.41: CREATEWINDOW(0x1e02 #1e02,0x1e01 #1e01,0x40a3,0x,0x,0x,0x,0x01b4,0x0064,0x0896,0x) ret=03bf:0ebc ds= Ret USER.41: CREATEWINDOW() retval=0x ret=03bf:0ebc ds= Call user32.391: MessageBoxA(,40be4aac "Unhandled exception 0xc096 at address 0x0fbb.\nDo you wish to debug it ?",40281fea "Error",0014) ret=40158a48 fs=024f Here is the previous call to CreateWindow16 where things seem to be more normal and the first two string addresses correct. Notice that at this point a SetErrorMode(1) is called which is still in effect at the later failing point as shown above. Call KERNEL.107: SETERRORMODE(0x0001) ret=03bf:0e75 ds=0897 Ret KERNEL.107: SETERRORMODE() retval=0x ret=03bf:0e75 ds=0897 Call USER.133: GETWINDOWWORD(0x01b4,0xfffa) ret=03bf:0eb3 ds=0897 Ret USER.133: GETWINDOWWORD() retval=0x0896 ret=03bf:0eb3 ds=0897 Call USER.41: CREATEWINDOW(0x08971e02 "LISTBOX",0x08971e01 "",0x40a3,0x,0x,0x,0x,0x01b4,0x0064,0x0896,0x) ret=03bf:0ebc ds=0897 trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_NCCREATE,wp=,lp=40d06d14) trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_NCCALCSIZE,wp=,lp=40d06b00) trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_CREATE,wp=,lp=40d06d14) trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_WINDOWPOSCHANGING,wp=,lp=40d06788) trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_NCCALCSIZE,wp=0001,lp=40d06630) trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_WINDOWPOSCHANGED,wp=,lp=40d06788) trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_SIZE,wp=,lp=) trace:relay:WINPROC_CallWndProc (wndproc=0x40079e98,hwnd=028c,msg=WM_MOVE,wp=,lp=) CallTo16(func=0467:70a4,ds=0897,0x01b4,0x0210,0x0001,0x0064,0x028c) ss:sp=0897:9a2a AX=0896 BX= CX= DX= SI= DI= BP=9a54 ES=0897 FS= Call USER.135: GETWINDOWLONG(0x01b4,0x0004) ret=0467:70be ds=0897 Ret USER.135: GETWINDOWLONG() retval=0x04e7904c ret=0467:70be ds=0897 Call USER.107: DEFWINDOWPROC(0x01b4,0x0210,0x0001,0x0064028c) ret=046f:1be9 ds=0897 Ret USER.107: DEFWINDOWPROC() retval=0x ret=046f:1be9 ds=0897 CallTo16() ss:sp=0897:9a2a retval=0x Ret USER.41: CREATEWINDOW() retval=0x028c ret=03bf:0ebc ds=0897 I've tried making SetErrorMode16 a NOP but it still fails. I think Civ2 is planning to fail and trying to capture the critical error message it knows it will get and since capturing it is not working, the whole thing falls apar
Re: linking problem
> collect2: ld terminated with signal 11 [segmentation fault] > make: *** [wine] Error 12 A signal 11 is almost always a hardware problem. See the FAQ: http://www.bitwizard.nl/sig11/ -- Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED]) http://defiance.dyndns.org/ / http://radio.scenespot.org/ Now playing on Defiance Radio: Mind Rubbers by Squarepusher
Re: wine.conf graphical front-end development
On Mon, 10 Jul 2000, Martin Pilka wrote: : hello all! : ... : once again, your notice are welcomed. First of all, thnx a lot! Now, it would be nice to find some way, how to make this utility "cross-desktop". What do I mean? Consider this: many people will use GNOME / KDE / Corel-desktop (How is it called?) or bare X with wine (and possibly something like "wine-desktop" ... maybe). I absolutelly think, the "wine.conf graphical front-end" for GNOME _should_ be a GNOME application (written using Gtk+ and gnome-libs), similary the KDE one should be written using Qt and the "bare wine" by using winelib. Now it would be nice not to "invent the wheel" for each desktop separately, but rather to create some "skeleton" for the app, with desktop specific addons, that would be possible to compile then separately for each desktop. We can maybe use some meta-configuration file, that would describe, what the wine.conf entries are (including help), that would be distributed with each wine version, making the configuration program up-to-date. And Yes, the "wine.conf configurator" is not the only program, that is desktop-dependant and would be nice to be developed somehow "centrally" for all wine-desktop combinations. Consider e.g. 1) help browser (or better: the possibility to view windows .hlp files using native help-browser of the current desktop); or 2) integrating the component-systems between wine & the desktops; or 3) integrating "start menu" and "the desktop" between wine and the desktops (so that freshly installed program's entry will appear somwhere in the GNOME/KDE/whatever "start menu".) I think, we need some central "wine-desktops intergration project", that would create skeletons for such integrattion effords. I'd be willing (time permits) to help such effords. : have a nice day... have a nice night ;-) : martin Petr Tomasek (Sorry for my english...) -- Petr Tomasek, http://www.etf.cuni.cz/~tomasek/
linking problem
Hi, while compiling wine I am getting the following error during final linking collect2: ld terminated with signal 11 [segmentation fault] make: *** [wine] Error 12 bye, Rav
RE: Crash report : X11DRV_DIB_GetDIBits
At 02:13 PM 7/10/00 -0400, you wrote: >Here's a patch that should fix the problem with Adobe. Let me know if it's >working, if so I'll post the patch. Yes it avoids the crash. Thanks to you and François for your answer. Btw you will have to repost the whole patch since Alexandre Julliard nuked the first patch. Gerard
Segfault
With current CVS it's necessary to revert the
teb->CurrentLocale = GetUserDefaultLCID() change in scheduler/thread.c
else Wine segfaults.
Gerard
--- thread.c.orig Mon Jul 10 22:19:09 2000
+++ thread.cMon Jul 10 23:12:17 2000
@@ -90,7 +90,6 @@
teb->StaticUnicodeString.MaximumLength = sizeof(teb->StaticUnicodeBuffer);
teb->StaticUnicodeString.Buffer = (PWSTR)teb->StaticUnicodeBuffer;
teb->teb_sel = SELECTOR_AllocBlock( teb, 0x1000, SEGMENT_DATA, TRUE, FALSE );
-teb->CurrentLocale = GetUserDefaultLCID(); /* for threads in user context */
return (teb->teb_sel != 0);
}
@@ -302,6 +301,7 @@
teb->entry_arg = param;
teb->startup = THREAD_Start;
teb->htask16 = GetCurrentTask();
+teb->CurrentLocale = GetUserDefaultLCID(); /* for threads in user context */
if (id) *id = (DWORD)tid;
if (SYSDEPS_SpawnThread( teb ) == -1)
{
Re: Crash report : X11DRV_DIB_GetDIBits
On Mon, Jul 10, 2000 at 02:13:24PM -0400, Stephane Lussier wrote: > Here's a patch that should fix the problem with Adobe. Let me know if it's > working, if so I'll post the patch. The DIB code used by Xing DVD Player works again with it. Ciao, Marcus
wine.conf graphical front-end development
hello all! i'm working on graphical front-end for wine.conf file. the goal is to provide useful tool for both newbie and linux-guru. it will be something like wizard you know from windows, but it will also accept the command line, which allows you to directly jump into something like advanced section, where can you edit everything. Following is the VERY PRELIMINARY draft, what should single screens contains. your boggles are welcomed. 1. you can choose if you want to generate new or edit existing wine.conf file. 2. choose a location of your wine.conf file 3. add/remove disks which will be accessible from wine 4. where the windows/profile/temp directory is ([wine] section of wine.conf file) 4.5 default wine look ([tweak.layout] section) 5. you can choose if you want to answer more questions, or if it is enough and you want save it and finish configuration. if you choosed more questions: 6. dll load order 7. things like "managed windows" ([x11drv] section) 8. ports ([serialports] [parallelports] [spooler] sections) 9. registry ([registry] section) 10. complete screen, where you can see and edit everything once again, your notice are welcomed. have a nice day... martin
Re: Mixer bugs and proposed fixes
> Ed Snow wrote: > > I've run across what I believe to be bugs in winmm/wineoss/mixer.c. But as I am not >that familiar with either winmm or OSS, I > decided I'd post here instead of shooting straight for wine-patches. > > There are 3 items: > > 1) Handling of unmute when you are not muted. > > In MIX_SetControlDetails(), when being asked to unmute, MIX_Volume[lineID] is >written out to OSS and -1 is stored in > MIX_Volume[lineID] to indicate that mute is off. If however, mute is off when this >begins, -1 is written to OSS (and looks like > full scale). Fix is a check for -1 before writing it out. correct > 2) Handling of Volume scale > > In MIX_DoGetLineControls(), the range for the volume is returned as [0..100]. >However, in MIX_SetControlDetails(), the range is > assumed to be [0..65535] and scaled into [0..100] before being sent to OSS. There >are two possible corrections; to use the range > that is reported, or report the range that is used. Both fixes work. I picked >reporting the range that is used (returning > [0..65535] in MIX_DoGetLineControls()). correct too. > 3) Bass and Treble > > Here I actually don't like my fix (read hack) and suspect that a much better one >exists. It appears that OSS supports Bass and > Treble as peers to PCM, Synth, etc. Windows appears not to. The problem I saw was >a program querying all the devices. As BASS > and TREBLE have no equivelent device in Windows the MIX_GetLineInfoFromIndex() >cannot map them. For instance SOUND_MIXER_PCM > mapped to MIXERLINE_COMPONENTTYPE_SRC_WAVEOUT. SOUND_MIXER_BASS triggers an error >(returns invalid line). To hack around this I > have case'd out BASS and TREBLE and they return MMSYSERR_NOERROR. I suspect that >the correct fix is to not provide BASS and > TREBLE to windows as devices. a better fix (untested) would be to simply remove the bass and treeble oss controls from the WINE_MIXER_MASK definition (which is supposed to be the mask of OSS controls to present to any calling application) A+ -- --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
Re: Link windows NT .lib
On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote: > Hi, > > Sorry to ask for a maybe off-topic subject but : > > I got an old Windows NT 3.5 apps which runs fine (perfect but no shell > commands i.e. I can't do a !dir ). It was provided with a binary lib file > (MSVC) , the header file and the API documention to wite C programs to > perform specific tasks faster than with what they called procedure files. > > I was wondering if I could drop NT platform to use Linux with Wine. The > only > point left without an answer is how to link the MS lib with GCC under > Linux. > > This sound to me to be a GCC question but I couldn't find any information > in > the GCC How-to and as the application works fine with Wine, I'm trying in > the wine-devel list. > > Thanks. > Let's see if I understand what you are asking. You want to write c code that calls fuctions in MSVC.DLL and compile it with gcc? The way I know to do that is to write the c code as a winelib program. It would get at the dll with LoadLirary and GetProcAddress. There is a HOWTO-winelib in documetation. Lawson ---cut here YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
RE: Crash report : X11DRV_DIB_GetDIBits
Here's a patch that should fix the problem with Adobe. Let me know if it's working, if so I'll post the patch. Stephane Lussier Macadamian Technologies > -Original Message- > From: gerard patel [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 10, 2000 5:41 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Crash report : X11DRV_DIB_GetDIBits > > > At 02:40 PM 7/10/00 +, you wrote: > > >Anyway, the patch might be wrong - the problem could be > elsewhere - but to track it > >down I'll need a bit more information. If you could send the > exact numbers printed in > >X11DRV_DIB_GetDIBits trace, that would be great. > > (I have added a custom trace just before the last call to XGetSubImage) > > trace:bitmap:CreateBitmap 18x18, 2 colors returning 173a > trace:bitmap:CreateCompatibleBitmap 173a > trace:bitmap:GetDIBits biSizeImage = 216, biWidth = 18, biHeight = 18 > trace:bitmap:X11DRV_DIB_GetDIBits 18 scanlines of (18,18) -> > (18,18) starting from 0 > trace:bitmap:X11DRV_DIB_GetImageBits src=0-17 dest=0-0 width=18 lines=18 > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 73 (X_GetImage) > Serial number of failed request: 3733 > Current serial number in output stream: 3733 > > It seems that we are asking X to behave like Windows here :-) > I have not tried to fix it myself because I don't understand the problem > you are fixing :-/; my impression is that in the Acrobat case, > the previous > way of calculating ySrc was correct. > > You can see the problem by yourself if you want, the Acrobat 3.01 reader > is a freeware by Adobe; it's a 5 MB download, though. > > Gerard > > dib.diff
Re: Crash report : X11DRV_DIB_GetDIBits
At 02:40 PM 7/10/00 +, you wrote: >Anyway, the patch might be wrong - the problem could be elsewhere - but to track it >down I'll need a bit more information. If you could send the exact numbers printed in >X11DRV_DIB_GetDIBits trace, that would be great. (I have added a custom trace just before the last call to XGetSubImage) trace:bitmap:CreateBitmap 18x18, 2 colors returning 173a trace:bitmap:CreateCompatibleBitmap 173a trace:bitmap:GetDIBits biSizeImage = 216, biWidth = 18, biHeight = 18 trace:bitmap:X11DRV_DIB_GetDIBits 18 scanlines of (18,18) -> (18,18) starting from 0 trace:bitmap:X11DRV_DIB_GetImageBits src=0-17 dest=0-0 width=18 lines=18 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 73 (X_GetImage) Serial number of failed request: 3733 Current serial number in output stream: 3733 It seems that we are asking X to behave like Windows here :-) I have not tried to fix it myself because I don't understand the problem you are fixing :-/; my impression is that in the Acrobat case, the previous way of calculating ySrc was correct. You can see the problem by yourself if you want, the Acrobat 3.01 reader is a freeware by Adobe; it's a 5 MB download, though. Gerard
Re: HOWTO-winelib update
On Monday, July 10, 2000, Veksler Michael <[EMAIL PROTECTED]> wrote: > > On Mon, 10 Jul 2000, Wilbur N. Dale wrote: > > > These are my latest additions to the HOWTO. > > > > The patch is big because you have repeated big 'configure' artifacts all > over the directory tree: > ltconfig ltmain.sh configure config.guess config.sub aclocal.m4 > > I am not sure what the policy should be in this case. I'm simply pointing > out the facts. This big repetition of files does not feel right, but it > does not seem to be critical. All of the above are (typically) generated files, so they probably don't belong in CVS. The configure script may or may not be appropriate (e.g., Wine's configure script is in CVS). The lt* files are generated by libtool and would only be included if you're targeting developers without libtool installed on their systems. aclocal.m4 is often generated by the aclocal tool (usually in conjunction with automake). Unless you have some hand-written autoconf macros in there, it should be left out. Finally, the config.(guess|sub) files are machine-dependent and should absolutely not be included. My personal take is that none of the above files should be included. After all, the WineLib examples are targeted for developers, who should be able to install autoconf and libtool (and automake?). They are usually installed as part of a development environment anyways. John -- [EMAIL PROTECTED]http://www.gnome.org [EMAIL PROTECTED] http://www.worldforge.org http://advogato.org/person/jsheets
Link windows NT .lib
Hi, Sorry to ask for a maybe off-topic subject but : I got an old Windows NT 3.5 apps which runs fine (perfect but no shell commands i.e. I can't do a !dir ). It was provided with a binary lib file (MSVC) , the header file and the API documention to wite C programs to perform specific tasks faster than with what they called procedure files. I was wondering if I could drop NT platform to use Linux with Wine. The only point left without an answer is how to link the MS lib with GCC under Linux. This sound to me to be a GCC question but I couldn't find any information in the GCC How-to and as the application works fine with Wine, I'm trying in the wine-devel list. Thanks.
Re: Crash report : X11DRV_DIB_GetDIBits
In message <[EMAIL PROTECTED]>, Francois Jacques <[EMAIL PROTECTED]> writes >Aaaagghhh! > >Anybody else experienced problems with DIBs manipulation? > >Cheers, >Francois yes I think so (but mine's in X11DRV_CreateBitMap?) - with MathCad7 (ironically, just after Gerard had fixed to a winsock funny for me -see post on cemw) Bob Hall >> X spits a BadMatch when Wine is trying to retrieve data after the end of the >> drawable with the call to XGetSubImage in X11DRV_DIB_GetImageBits :-( >> (for example, with a 18 lines bitmap and startscan = 0, Wine asks for 18 lines >> with ysrc=17; reverting the change to always set ysrc = startscan cures the >crash) >> >> Gerard >> > Can you post this patch for a try please? Bob -- robert w hall
Re: Enhanced Metafiles
On Mon, Jul 10, 2000 at 04:08:37PM +0100, Huw D M Davies wrote: > On Mon, Jul 10, 2000 at 10:42:30AM -0400, Jason Mawdsley wrote: > The recording of enhmetas definitely does this. Insert 'under Windows' somewhere in this sentence ;-) Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: HOWTO-winelib update
On Mon, 10 Jul 2000, Wilbur N. Dale wrote: > These are my latest additions to the HOWTO. > > The tar file contains examples that are used in the HOWTO. Unpacking the tar > file will add the directory programs/dllExamples. The windows sources and the > examples are subdirectories of dllExamples. There are only sources in the tar > file: no binaries. > The patch is big because you have repeated big 'configure' artifacts all over the directory tree: ltconfig ltmain.sh configure config.guess config.sub aclocal.m4 These take up 75% (1030k out of 1390k total) of the uncompressed tar. (or 80% [260k out of 330k] of the compressed tar). I am not sure what the policy should be in this case. I'm simply pointing out the facts. This big repetition of files does not feel right, but it does not seem to be critical. The above measurements were performed by tar -xzOf dllExamples.tar.gz list-of-filter-flags | gzip | wc This measurement is not accurate, so there may be some (minor) inaccuracies in the analysis (I have quota limitations on this machine). Michael
Re: Enhanced Metafiles
On Mon, Jul 10, 2000 at 10:42:30AM -0400, Jason Mawdsley wrote:
> Hi All-
>
> I noticed in the Enhanced Metafile driver functions the following code
> is everywhere.
>
> if(dc->w.GraphicsMode == GM_COMPATIBLE) {
> right--;
> bottom--;
> }
>
> Why are we excluding the bottom right edge if in compatible mode. The
> MSDN docs say nothing about this.
The recording of enhmetas definitely does this. I'm not certain about
what happens in modes other than MM_TEXT though. Try creating a disk
based emf and 'od' the result.
> To me this is bad, because if we take for example the EMFDRV_Rectangle
> function, we exclude the edge at the EMFDRV level and at the XllDRV
> level when we draw it.
The playback is incorrect. I think playback always happens in
GM_ADVANCED mode, here the br corner shouldn't be chopped off, but
X11DRV_Rectangle and friends don't observe this. So this is what
needs fixing.
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390| Oxford OX1 3PU
Fax: +44 1865 272400| UK
Re: Crash report : X11DRV_DIB_GetDIBits
Aaaagghhh! Gerard, I was fearing problems of such kind. I have an application here that has a bottom-up DIB in memory and retrieve data from it one line at the time. And after investigation it appeared that the proposed patch was the good solution... I never pretended to not break anything! Anyway, the patch might be wrong - the problem could be elsewhere - but to track it down I'll need a bit more information. If you could send the exact numbers printed in X11DRV_DIB_GetDIBits trace, that would be great. Anybody else experienced problems with DIBs manipulation? Cheers, Francois gerard patel wrote: > Crashes are occurring for me with latest Cvs commits > (an example is Acrobat 3.01 32 bits, but I have other apps crashing as well) > The culprit is the following patch > > Changelog : > Updated X11DRV_DIB_GetDIBits to properly handle bottom-up DIBs manipulation. > Corrected XGetSubImage arguments order. > > Modified files : > graphics/x11drv/dib.c > > X spits a BadMatch when Wine is trying to retrieve data after the end of the > drawable with the call to XGetSubImage in X11DRV_DIB_GetImageBits :-( > (for example, with a 18 lines bitmap and startscan = 0, Wine asks for 18 lines > with ysrc=17; reverting the change to always set ysrc = startscan cures the crash) > > Gerard >
Enhanced Metafiles
Hi All-
I noticed in the Enhanced Metafile driver functions the following code
is everywhere.
if(dc->w.GraphicsMode == GM_COMPATIBLE) {
right--;
bottom--;
}
Why are we excluding the bottom right edge if in compatible mode. The
MSDN docs say nothing about this.
To me this is bad, because if we take for example the EMFDRV_Rectangle
function, we exclude the edge at the EMFDRV level and at the XllDRV
level when we draw it.
Is there a specific reason for this behavior or should I get rid of
it.
Thanks in advance.
Jason Mawdsley
Macadamian Technologies
Printing Summit (fwd)
This looks relevant to Wine as well. doug. [EMAIL PROTECTED] -- Forwarded message -- Date: Sun, 9 Jul 2000 21:23:19 -0700 From: David Dawes <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Printing Summit (fwd) Some people at VA Linux are organising a "printing summit", and they've asked if XFree86 would like to be prepresented there. If anyone here is interested in representing XFree86, please let me know soon. The details are included below. David -- Currently we have lined up from the development side CUPS, LPRng, GPR, libppd, printing HOWTOs, GNOME, KDE, IBM and the efforts within VA Linux. On the manufacturing side we have HP, Okidata, AGFA, set to come, as well as many of the GNU/Linux distribution vendors. As you can tell this is a pretty substantial representation of all of the efforts within the Linux printing environment. The dates are July 27th and 28th, the location is the Sheraton hotel in Sunnyvale California. The agenda is somewhat open by design, and as such we suggest the following schedule: - July 27th Opening comments - Introductions from each effort *Provide a 10-15 presentation of efforts, vision, and issues surrounding each of your efforts. - BoF After all efforts are outlined, a large portion of the agenda is open to allow the group to address those issues that they perceive as being the most important. The rest of the summit will consist mainly of BoF sessions to allow people to tackle specific issues in smaller, more focused groups. To help facilitate this conversation I have created a Printing Summit mailing list at: http://lists.sourceforge.net/mailman/listinfo/printing-summit You are encouraged to subscribe, either by using the form accessible at the above URL, or by sending a message to [EMAIL PROTECTED] with the word "subscribe" in the subject or body of the message. It is a discussion list where some fine tuning of the agenda and other logistical information will be discussed , and all are encouraged to participate. I know this seems to be a fairly open agenda but we feel it is imperative that the meeting be a working group with the only hidden agenda to be a sharing of visions, ideas, and issues. We can always hope that there will be a great epiphany and a single future vision of Linux/*nix printing can be realized, but realistically we feel that building the relationships and communication channels among the various groups will be a huge step in the right direction. More information on the organization and goals of this summit will be available on the mailing list. Latecomers who may wish to catch up on the list discussion may wish to visit the above URL for a pointer to the archives.
Re: interface for IID {31416d44-86ae-11d2-822d-a8d53187cafa} NOT found! (X4.01 + NVIDA GLX)
In case anyone is interested heres a dump of -debugmsg +ddraw attached in bzip2 format. I should have attached this with the oeiriginal mail I suppose. thanks people, Colin Fowler gpolice.bz2
Re: DOS patch
On Mon, 10 Jul 2000 [EMAIL PROTECTED] wrote: > Thanks for the explanation. Isn't rmcb->proc_ofs kind of an odd name > for a 48 bit pointer? :-) Well, since gcc doesn't know about far (48-bit) pointers, I just had to take the address of the offset part... the segment part is directly after it in the RMCB structure anyway.
