Re: portability improvements for wineshelllink script
Somebody wrote: [Let's use bash features in wine shell scripts] Bad idea. Unless you have a *very* good reason, you should stick to Posix interfaces, which here means get it to run under Bourne shell. Portability -- it's a good thing. By the way, if anyone out there is looking for a concise, illuminating guide to portable shell scripting, I highly recomment Portable Shell Programming by Bruce Blinn. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: Stable release builds with fixme output (Wine 20050310 debian sarge/testing)
On 05/07/2005 05:55:35 PM, J. Grant wrote: On 07/05/05 16:15, Paul van Schayck wrote: On 5/7/05, J. Grant [EMAIL PROTECTED] wrote: I typically launch applications using wine from the terminal, I get pages of these fixme debug messages. I wonder if there is a reason these fixme harmless messages are being displayed? IMHO stable releases should only output err messages, thus not displaying fixme or warnings. I wonder if this has been considered already? Not all fixme's are harmless. Most of them are actually potentially hazardous - most of the time they indicate missing features. I also don't see how supressing fixme's has something to do with stable releases anyway - a stable release should probably immediatly terminate the process on any fixme since continuing execution might lead to instability. And such a stable wine release would be pretty useless right now. This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly. People choose to use whatever there is because there is no other choice, in these circumstances it would be more suitable to release a version suitable for users which will mean you get bug reports. Bug reports without any hint what actually went wrong. The user's might maybe even get the idea that the application is buggy and not wine. -flx
Now hiring
Jeremy, guys, it seems we have run low on official janitors, I have talked with someone that seems to know what they are doing as far as the right way to bug report (he contribs to MPlayer), and he said he would be willing to help maintain bugzilla, but that he doesn't have a whole lot of time, the extra hand will be helpful. Could you add 'canconfirm' and 'editbugs' to [EMAIL PROTECTED] Does anyone have any objection to me posting a note on wine-users that we are accepting applications for dedicated bug maintainers (read: janitors lol)? I will handle interviewing and hiring, and just send an email to Jeremy when we get people that know what they are doing and can really be of use.. I think 5 should be good for now.. Dustin
Re: [DInput] Fix 'peek' code for mouse (S3 problem)
Am Samstag, 7. Mai 2005 20:46 schrieb Lionel Ulmer: I just noticed that S3 has a registry setting called GDIMouse. This setting is reflected by the use colored mouse pointer(if possible) / use monochrome mouse pointer settings. (Benutze farbigen Mauszeiger(wenn möglich) and Benutze monochrimen Mauszeiger in my German version). Changing this Setting has no effect on S3 in Wine. I suppose S3 fails to draw its own mouse pointer in Wine and falls back to the GDI one. In that case, you need to do a +dinput,+cursor,+ddraw,+event trace to see if it puts DInput in 'EXCLUSIVE' mode and also if there are no cursor calls once the game starts (as there is no need to change the GDI cursor if the game is using its own). Well I've attached another log if you're interested, but I looked at it and S3 still puts Dinput in NONEXCLUSIVE mode. The ddraw mouse pointer causes a Blue Screen of Death on my brothers Notebook(win2k), so I'd consider it somewhat broken. I just installed S3 in qemu 0.7.0 + win95, it doesn't bail out with a illegal instruction any more, but the copy protection seems to be broken, the game can't find the CD. Stefan s3.out.gz Description: GNU Zip compressed data
Re: Assertion fails in riched20; relay debug segfaults
This a known bug. head to http://bugs.winehq.org/show_bug.cgi?id=2924
for more info and a workaround..
We are waiting on the person that made this patch to post a fixed patch..
Alexandre.. This is generating a lot of bug reports, is there a chance
we could remove it for now, as it seems to have caused more harm than good?
Dustin
Adrian Harvey wrote:
The wine version of riched20 fails an assertion when starting
StreamboxVCR
$ wine .wine/drive_c/Program\
Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-
b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154
err:ole:ITypeInfo_fnInvoke did not find member id fdfa, flags 4!
err:ole:ITypeInfo_fnInvoke did not find member id fdfb, flags 4!
fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub
wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed.
fixme:ole:ITypeInfo_fnRelease destroy child objects
Along with a popup dialogue box from the visual C++ runtime library
indicating abnormal program termination. The file run.c appears to be
part of riched20, and indeed overriding the load order to native only
for that DLL allows the program work.
All reasonably standard debugging so far, and I went for some more
logging to aid tracing the problem (or to log in bugzilla when it all
gets too hard for my skill level ;-) )
$ WINEDEBUG=+relay wine .wine/drive_c/Program\
Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe
0009:Call kernel32.__wine_kernel_init() ret=55727d9e
Segmentation fault
Shortest relay trace I've ever had! But I'm not really sure where to go
from here... Running GDB on it gives me no useful results. I have an
AMD64 box running Fedora Core 3 and wine is the latest from CVS.
I'm going to try some other tracing to look at the riched problem, but
+relay crashing seems serious to me.
Adrian
Re: ignore requested height for non-menubar ownerdraw popups
On Sun, 8 May 2005 11:14:52 +0200, you wrote:
This fixes bug 2764 (the scrolling issue seems to be resolved
already?). Verified this behaviour on WinXP and changed the comment to
reflect that.
ChangeLog:
Ignore requested height for non-menubar ownerdraw popups too.
Index: menu.c
===
RCS file: /home/wine/wine/dlls/user/menu.c,v
retrieving revision 1.26
diff -u -r1.26 menu.c
--- menu.c19 Apr 2005 09:47:02 - 1.26
+++ menu.c8 May 2005 09:09:06 -
@@ -887,17 +887,14 @@
SendMessageW( hwndOwner, WM_MEASUREITEM, 0, (LPARAM)mis );
lpitem-rect.right += mis.itemWidth;
- if (menuBar)
- {
- lpitem-rect.right += MENU_BAR_ITEMS_SPACE;
+ /* under windows you are given a standard height for the
+menu and the height value is ignored. delphi 7 depends
+on this behaviour. */
+ lpitem-rect.bottom += GetSystemMetrics(SM_CYMENU)-1;
That does not seem correct on the Win2k system that I am using for
testing.
Attached is the test that I am working on. It creates a non-menubar
popup menu, fills it with a couple of items and traces the resulting
item rectangles. It is all work in progress of course, not meant for
submitting yet.
Without your patch the rectangles get the height that is returned by the
WM_MEASUREITEM handler both Win2k and Wine. With your patch the Wine
behavior is broken. I have a real world application too, that is
affected by this brokenness.
Can you see if that is different on WinXP. If it is not, can you look
what is different with your test and mine?
Rein.
--- wine/dlls/user/tests/menu.c 2005-04-14 15:57:27.0 +0200
+++ mywine/dlls/user/tests/menu.c 2005-05-08 12:04:08.0 +0200
@@ -41,7 +41,30 @@ static LRESULT WINAPI menu_check_wnd_pro
/* mark window as having entered menu loop */
SetWindowLongPtr(hwnd, GWLP_USERDATA, TRUE);
/* exit menu modal loop */
-return SendMessage(hwnd, WM_CANCELMODE, 0, 0);
+//return SendMessage(hwnd, WM_CANCELMODE, 0, 0);
+ return DefWindowProc(hwnd, msg, wparam, lparam);
+
+case WM_MEASUREITEM:
+trace(WM_MEASUREITEM received\n);
+((MEASUREITEMSTRUCT*)lparam)-itemWidth = 10;
+((MEASUREITEMSTRUCT*)lparam)-itemHeight = 30;
+return TRUE;
+case WM_DRAWITEM:
+{
+DRAWITEMSTRUCT * pdis;
+ RECT rc;
+pdis = (DRAWITEMSTRUCT *) lparam;
+trace(WM_DRAWITEM received item %d rc %ld,%ld-%ld,%ld \n,
+pdis-itemID,
+
pdis-rcItem.left,pdis-rcItem.top,pdis-rcItem.right,pdis-rcItem.bottom );
+ GetMenuItemRect( NULL, (HMENU)pdis-hwndItem, 1, rc);
+ trace(it 1 rc %ld,%ld-%ld,%ld\n,rc.left,
rc.top,rc.right,rc.bottom);
+ GetMenuItemRect( NULL, (HMENU)pdis-hwndItem, 3, rc);
+ trace(it 3 rc %ld,%ld-%ld,%ld\n,rc.left,
rc.top,rc.right,rc.bottom);
+
+
+}
+
}
return DefWindowProc(hwnd, msg, wparam, lparam);
}
@@ -101,9 +124,37 @@ static void test_menu_locked_by_window()
DestroyWindow(hwnd);
}
+static void test_menu_ownerdrawn()
+{
+int i,j,k;
+BOOL ret;
+HMENU hmenu;
+HWND hwnd = CreateWindowEx(0, MAKEINTATOM(atomMenuCheckClass), NULL,
+WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
+NULL, NULL, NULL, NULL);
+ok(hwnd != NULL, CreateWindowEx failed with error %ld\n, GetLastError());
+if( !hwnd) return;
+hmenu = CreatePopupMenu();
+ok(hmenu != NULL, CreateMenu failed with error %ld\n, GetLastError());
+if( !hmenu) { DestroyWindow(hwnd);return;}
+k=1;
+for( j=0;j1;j++)
+for(i=0;i2;i++) {
+ret = AppendMenu( hmenu, MF_OWNERDRAW |
+ (i==0 ? MF_MENUBREAK : 0), k++, 0);
+ ok( ret, AppendMenu failed for %d\n, k-1);
+ }
+ret = TrackPopupMenu( hmenu, 0x100, 100,100, 0, hwnd, NULL);
+ ok( ret, TrackPopupMenu failed gle %ld\n, GetLastError());
+ trace(done\n);
+
+DestroyWindow(hwnd);
+}
+
START_TEST(menu)
{
register_menu_check_class();
-test_menu_locked_by_window();
+//test_menu_locked_by_window();
+test_menu_ownerdrawn();
}
Re: Now hiring
Dustin Navea wrote: Jeremy, guys, it seems we have run low on official janitors, I have talked with someone that seems to know what they are doing as far as the right way to bug report (he contribs to MPlayer), and he said he would be willing to help maintain bugzilla, but that he doesn't have a whole lot of time, the extra hand will be helpful. Could you add 'canconfirm' and 'editbugs' to [EMAIL PROTECTED] Does anyone have any objection to me posting a note on wine-users that we are accepting applications for dedicated bug maintainers (read: janitors lol)? I will handle interviewing and hiring, and just send an email to Jeremy when we get people that know what they are doing and can really be of use.. I think 5 should be good for now.. Dustin I think recruiting is a better term. After all, most armies don't pay salaries worth of anything, and neither do we :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Bug 2131 - 16-bit support?
Hi, On Sat, May 07, 2005 at 08:09:39PM -0500, Dustin Navea wrote: I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit. Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason. As has been mentioned before on WD, cards.dll is a very obvious Microsoft screwup, since both 16bit and 32bit DLL carry the same name, which is a big no-no. I really don't think we want to patch our loader like mad to accomodate for such a stupid mistake. Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version? OTOH, is cards.dll being used by any program other than Microsoft's Solitaire? If it isn't, then it's rather useless to care about the 16/32bit distinction anyway. Basically, I just need to know for the purposes of resolving this bug, should I leave it open and confirmed so that someone knows to implement the 16-bit functions (32 - 16 bit conversions?), or should I just go ahead and close it as WONTFIX? I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation. Andreas
Re: Assertion fails in riched20; relay debug segfaults
Thanks, Dustin, that sorts the riched problem. Any ideas as to why the
relay trace segfaults though? That was the bit I thought was
interesting... I have now found it will segfault even if wine is not
given an executable, so it's happening very early on.
Adrian
On Sun, 2005-05-08 at 04:58 -0500, Dustin Navea wrote:
This a known bug. head to http://bugs.winehq.org/show_bug.cgi?id=2924
for more info and a workaround..
We are waiting on the person that made this patch to post a fixed patch..
Alexandre.. This is generating a lot of bug reports, is there a chance
we could remove it for now, as it seems to have caused more harm than good?
Dustin
Adrian Harvey wrote:
The wine version of riched20 fails an assertion when starting
StreamboxVCR
$ wine .wine/drive_c/Program\
Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-
b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154
err:ole:ITypeInfo_fnInvoke did not find member id fdfa, flags 4!
err:ole:ITypeInfo_fnInvoke did not find member id fdfb, flags 4!
fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub
wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed.
fixme:ole:ITypeInfo_fnRelease destroy child objects
Along with a popup dialogue box from the visual C++ runtime library
indicating abnormal program termination. The file run.c appears to be
part of riched20, and indeed overriding the load order to native only
for that DLL allows the program work.
All reasonably standard debugging so far, and I went for some more
logging to aid tracing the problem (or to log in bugzilla when it all
gets too hard for my skill level ;-) )
$ WINEDEBUG=+relay wine .wine/drive_c/Program\
Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe
0009:Call kernel32.__wine_kernel_init() ret=55727d9e
Segmentation fault
Shortest relay trace I've ever had! But I'm not really sure where to go
from here... Running GDB on it gives me no useful results. I have an
AMD64 box running Fedora Core 3 and wine is the latest from CVS.
I'm going to try some other tracing to look at the riched problem, but
+relay crashing seems serious to me.
Adrian
Flattening of ddraw directory and renaming of files
Hi, I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. If this is ok, I plan to submit the changes soon. Bye, Christian struct_convert.c\ convert.c - ddraw_utils.c helper.c/ d3dexecutebuffer.c - executebuffer.c d3dmaterial.c - material.c d3dvertexbuffer.c - vertexbuffer.c main.c - * regsvr.c- * d3dcommon.c - d3d_utils.c d3dlight.c - light.c d3dtexture.c- texture.c d3dviewport.c - viewport.c mesa.c - opengl.c d3d_private.h - * ddcomimpl.h - * ddraw_private.h - * gl_api.h- * gl_private.h- * mesa_private.h - opengl_private.h d3ddevice/main.c- device_main.c d3ddevice/main.h- device_main.h d3ddevice/mesa.c- device_opengl.c dclipper/main.c - clipper.c dclipper/main.h - clipper.h ddraw/hal.c - ddraw_hal.h ddraw/hal.h - ddraw_hal.c ddraw/main.c- ddraw_main.c ddraw/main.h- ddraw_main.h ddraw/thunks.c - ddraw_thunks.c ddraw/user.c- ddraw_user.c ddraw/user.h- ddraw_user.h direct3d/main.c - direct3d_main.c direct3d/main.h - direct3d_main.h direct3d/mesa.c - direct3d_opengl.c dpalette/hal.c - palette_hal.c dpalette/hal.h - palette_hal.h dpalette/main.c - palette_main.c dpalette/main.h - palette_main.h dsurface/dib.c - surface_dib.c dsurface/dib.h - surface_dib.h dsurface/fakezbuffer.c - surface_fakezbuffer.c dsurface/fakezbuffer.h - surface_fakezbuffer.h dsurface/gamma.c- surface_gamma.c dsurface/hal.c - surface_hal.c dsurface/hal.h - surface_hal.h dsurface/main.c - surface_main.c dsurface/main.h - surface_main.h dsurface/thunks.c - surface_thunks.c dsurface/thunks.h - surface_thunks.h dsurface/user.c - surface_user.c dsurface/user.h - surface_user.h dsurface/wndproc.c - surface_wndproc.c dsurface/wndproc.h - surface_wndproc.h Note: * = no change
Re: Flattening of ddraw directory and renaming of files
On Sun, 08 May 2005 13:22:20 +0100, Christian Costa wrote: I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. No objection, I'm just curious as to the rationale. Why is surface_hal.c? better than surface/hal.c? thanks -mike
Re: ignore requested height for non-menubar ownerdraw popups
On 05/08/2005 12:25:18 PM, Rein Klazes wrote: That does not seem correct on the Win2k system that I am using for testing. Right. Windows sets itemHeight before and not after WM_MEASUREITEM. Sorry for that. And it also seems not to be GetSystemMetrics(SM_CYMENU)-1 but a rather strange magic value of 16. (with my test it looked 100% the same ... sigh. I'll go to bed soon. ;) How about this patch? -flxIndex: menu.c === RCS file: /home/wine/wine/dlls/user/menu.c,v retrieving revision 1.26 diff -u -r1.26 menu.c --- menu.c 19 Apr 2005 09:47:02 - 1.26 +++ menu.c 8 May 2005 11:23:59 - @@ -882,7 +882,8 @@ mis.CtlID = 0; mis.itemID = lpitem-wID; mis.itemData = (DWORD)lpitem-dwItemData; -mis.itemHeight = 0; +mis.itemHeight = 16; /* XXX: WinXP sets this - but where does +this come from? */ mis.itemWidth = 0; SendMessageW( hwndOwner, WM_MEASUREITEM, 0, (LPARAM)mis ); lpitem-rect.right += mis.itemWidth;
Re: Wiki stuff
More Wiki stuff: for some reason on my browser at least pre sections aren't showing as a monospace font which makes embedded code hard to read. Is this some CSS thing? Firefox renders text/plain files as monospace OK so it's not my fonts. thanks -mike
Re: wineconsole exits immediately (Wine 20050310 debian sarge/testing)
[...] Install the wine-utils package. It is a suggested package for wine, but should be more recommended than suggested. Ok, thank you; it now works. Perhaps there could be a stub which informs users that wcmd is not avialable because wine-utils was not installed? Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: Bug 2131 - 16-bit support?
Andreas Mohr wrote: Hi, On Sat, May 07, 2005 at 08:09:39PM -0500, Dustin Navea wrote: I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit. Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason. As has been mentioned before on WD, cards.dll is a very obvious Microsoft screwup, since both 16bit and 32bit DLL carry the same name, which is a big no-no. I really don't think we want to patch our loader like mad to accomodate for such a stupid mistake. And I, personally, will not see the lose of the 16 bit version as too much of a problem. However: Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version? A real PE file has an NE header, which has a MZ header. Usually, these headers just tell whoever is trying to run the application that this is a 32 bit application. One can, however, generate a DLL which is both a 32 and a 16 bit DLL. Does our loader support such a format? If we call LoadLibrary16 on a DLL that has both PE and NE, will it use the NE? If so, we can create both DLLs inside the same file, and problem solved. OTOH, is cards.dll being used by any program other than Microsoft's Solitaire? If it isn't, then it's rather useless to care about the 16/32bit distinction anyway. I'm with you on this one, but if the Windows loader can do the 16/32 separation and we can't we may need to fix that. I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation. I'm with you. Andreas Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: ignore requested height for non-menubar ownerdraw popups
On Sun, 8 May 2005 13:30:30 +0200, you wrote: On 05/08/2005 12:25:18 PM, Rein Klazes wrote: That does not seem correct on the Win2k system that I am using for testing. Right. Windows sets itemHeight before and not after WM_MEASUREITEM. Sorry for that. And it also seems not to be GetSystemMetrics(SM_CYMENU)-1 but a rather strange magic value of 16. (with my test it looked 100% the same ... sigh. I'll go to bed soon. ;) How about this patch? Much better. About the magic number: I looked at the value on Win2k and WinME with different resolutions ( desktop-properties-settings, click on advanced tab and change what windows calls font size but is really changing the DPI, dots-per-inch, which is also reported). DPI Win2k WinME == 9616 13 120 20 16 I assume that you are using a DPI of 96, and XP and 2k behave the same way. The DPI you can retrieve with GetDeviceCaps( hdc, LOGPIXELSY). I would recommend using the Win2k values computed by: DPI/6. Rein.
Re: Flattening of ddraw directory and renaming of files
Mike Hearn wrote: On Sun, 08 May 2005 13:22:20 +0100, Christian Costa wrote: I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. No objection, I'm just curious as to the rationale. Why is surface_hal.c? better than surface/hal.c? 1) This removes the directories hierarchy (which is not really necessary) 2) You don't have several files with the same name (there are 6 main.c, 3 hal.c,... and when there are all opened for editing, this begins to be a little confusing) Bye, Christian
Regression in start wars jedi knight: jedi academy
Hello, I've yet another problem with the OpenGL patches from April 28: Star Wars Jedi Knight: Jedi Academy crashes during startup. The problematic commit is http://www.winehq.org/hypermail/wine-cvs/2005/04/0308.html, it's not the same problem as with Half-life. The crash happens in ntdll in HEAP_CreateFreeBlock. The call trace shows EDIT_MakeFit on wine/dlls/user/edit.c as the function which calls the heap functions. The crash only occurs if the game's configuration file exists, so the first start succeeds, but the following calls fail. I've attached 3 +opengl,+edit traces: before.out: Game start with config file and without the mentioned wine patch after.out: Game start with config file and with the patch applied(crash) nocfg.out: Game start without config file and with the patch(no crash) Any ideas? The whole thing looks quite strange as the crash is not directly related to OpenGL. Stefan The crash dump is: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x77cfff70 in 32-bit code (0x77ec1139). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:77ec1139 ESP:77a7e588 EBP:77a7e5a8 EFLAGS:00010283( - 00 -RIS1C) EAX:77d0 EBX:77ef6d8c ECX:77efdb1c EDX:0011 ESI:77cfff70 EDI:77c3bcb0 Stack dump: 0x77a7e588: 77a7e5c4 77ec198f 77bf 77efdb1c 0x77a7e598: 77ec221d 77ef6d8c 0848 77c3b460 0x77a7e5a8: 77a7e5c4 77ec14a6 77bf 77c3bcb0 0x77a7e5b8: 000c42c0 77c3b460 77c3b468 77a7e61c 0x77a7e5c8: 77ec2c3e 77bf 77c3b460 0848 0x77a7e5d8: 0001 77a7e5ec 77ec2e40 77bf001c Backtrace: =1 0x77ec1139 HEAP_CreateFreeBlock+0x69(subheap=0x77bf, ptr=0x77c3bcb0, size=0xc42c0) [heap.c:447] in ntdll (0x77a7e5a8) 2 0x77ec14a6 HEAP_ShrinkBlock+0x56(subheap=0x77bf, pArena=0x77c3b460, size=0x848) [heap.c:543] in ntdll (0x77a7e5c4) 3 0x77ec2c3e RtlReAllocateHeap(heap=0x77bf, flags=0xa, ptr=0x77c3a5a8, size=0x848) [heap.c:1348] in ntdll (0x77a7e61c) 4 0x77b33774 HeapReAlloc(heap=0x77bf, flags=0x8, ptr=0x77c3a5a8, size=0x848) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:280] in kernel32 (0x77a7e638) 5 0x77b33f76 GlobalReAlloc+0x1b6(hmem=0x77c3641a, size=0x840, flags=0x42) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:617] in kernel32 (0x77a7e668) 6 0x77b3457d LocalReAlloc+0x2d(handle=0x77c3641a, size=0x840, flags=0x42) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:926] in kernel32 (0x77a7e680) 7 0x77148793 EDIT_MakeFit+0x1a3(es=0x77c36368, size=0x41e) [/windows/c/sonstiges/wine/dlls/user/edit.c:1787] in user32 (0x77a7e6b0) 8 0x7714b24f EDIT_EM_ReplaceSel+0x17f(es=0x77c36368, can_undo=0x0, lpsz_replace=0x77c38a58, send_update=0x1, honor_limit=0x1) [/windows/c/sonstiges/wine/dlls/user/edit.c:3045] in user32 (0x77a7e718) 9 0x77145e84 EditWndProc_common+0x634(hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958, unicode=0x0) [/windows/c/sonstiges/wine/dlls/user/edit.c:617] in user32 (0x77a7e794) 10 0x77146c1c EditWndProcA(hWnd=0x1002c, uMsg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/edit.c:1016] in user32 (0x77a7e7b0) 11 0x7719ecef WINPROC_wrapper+0x17 in user32 (0x77a7e7d4) 12 0x7719f056 WINPROC_CallWndProc+0x76(proc=0x77146bf0, hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/winproc.c:419] in user32 (0x77a7e80c) 13 0x771a5fe7 CallWindowProcA(func=0x77146bf0, hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/winproc.c:3216] in user32 (0x77a7e840) 14 0x77170c61 call_window_proc+0x171(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958, unicode=0x0, same_thread=0x1) [/windows/c/sonstiges/wine/dlls/user/message.c:1521] in user32 (0x77a7e89c) 15 0x77172cbf SendMessageTimeoutA+0x1ff(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958, flags=0x0, timeout=0x, res_ptr=0x77a7e92c) [/windows/c/sonstiges/wine/dlls/user/message.c:2399] in user32 (0x77a7e908) 16 0x77172db1 SendMessageA+0x51(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/message.c:2443] in user32 (0x77a7e934) 17 0x00454613 in jamp (+0x54613) (0x001f) 18 0x (0x) 0x77ec1139 HEAP_CreateFreeBlock+0x69 [heap.c:447] in ntdll: movl0x0 (%esi),%ecx Unable to open file 'heap.c' Modules: Module Address Debug info Name (70 modules) PE 0x0040-01327000 Export jamp PE 0x1000-100f2000 Deferredopenal32 ELF 0x712fc000-71376000 Deferredlibglu.so.1 ELF 0x71376000-7141 Deferredopengl32elf \-PE 0x713b-7141 \ opengl32 ELF 0x71a5b000-71a7 Deferredmidimap.drvelf \-PE 0x71a6-71a7 \ midimap.drv ELF 0x71b8c000-71bb Deferredmsacm32elf \-PE 0x71b9-71bb \
Re: Bug 2131 - 16-bit support?
Shachar Shemesh [EMAIL PROTECTED] writes: A real PE file has an NE header, which has a MZ header. Usually, these headers just tell whoever is trying to run the application that this is a 32 bit application. One can, however, generate a DLL which is both a 32 and a 16 bit DLL. No, there's no way to do that, PE and NE are mutually exclusive. You could generate a DLL that is also a DOS binary but that's not very useful... I'm with you on this one, but if the Windows loader can do the 16/32 separation and we can't we may need to fix that. The Windows loader can't do it either. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Flattening of ddraw directory and renaming of files
Christian Costa [EMAIL PROTECTED] writes: I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. While you are at it, it would be nice to merge the header files. We really don't need one header for each source file. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine - WineHQ - codeweavers
I'm glad you like it; we're very fond of it ourselves. You need to get the art from Jeremy Newman, who is on vacation right now. His email is jnewman at codeweavers dot com. Cheers, Jeremy Derzu wrote: Hi all, I saw at the www.winehq.org/ the banner (http://www.winehq.org/images/bannerads/cw-ad02.gif) that ponts to the www.codeweavers.com/ page. That banner has a little penguin opening a bottle of wine and after, the penguin appears very drunk, does any one knows who did that banner? I wanna the picture of the drunk penguin to set as mine wallpaper, but I wanna a big one. Any one can help me? Sorry if that mesage is not exatly a devel question. Thanks, Derzu Yahoo! Mail, cada vez melhor: agora com 1GB de espaço grátis! http://mail.yahoo.com.br
Re: wineconsole exits immediately (Wine 20050310 debian sarge/testing)
J. Grant wrote: [...] Install the wine-utils package. It is a suggested package for wine, but should be more recommended than suggested. Ok, thank you; it now works. Perhaps there could be a stub which informs users that wcmd is not avialable because wine-utils was not installed? Well, not realy because it's a packaging bug and not a Wine bug. The rpms for the other distributions don't separate stuff out into a wine-utils package. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: ignore requested height for non-menubar ownerdraw popups
On 05/08/2005 04:21:46 PM, Rein Klazes wrote: About the magic number: I looked at the value on Win2k and WinME with different resolutions ( desktop-properties-settings, click on advanced tab and change what windows calls font size but is really changing the DPI, dots-per-inch, which is also reported). DPI Win2k WinME == 9616 13 120 20 16 Looks like a font-height in pixels for me then - maybe some system font has a different size on your Win2k and WinME box? (I'm reinstalling Windows ATM - can't test it) -flx
Re: ignore requested height for non-menubar ownerdraw popups
On Sun, 8 May 2005 21:00:28 +0200, you wrote: On 05/08/2005 04:21:46 PM, Rein Klazes wrote: About the magic number: I looked at the value on Win2k and WinME with different resolutions ( desktop-properties-settings, click on advanced tab and change what windows calls font size but is really changing the DPI, dots-per-inch, which is also reported). DPI Win2k WinME == 9616 13 120 20 16 Looks like a font-height in pixels for me then - maybe some system font has a different size on your Win2k and WinME box? (I'm reinstalling Windows ATM - can't test it) Everything else that I can think of is the same on those boxes. Changing menu font size is also irrelevant. I tested also a box with WinXP: same results as the Win2k column. Rein.
Re: LockDIBSection problem
On 06 May 2005 16:01:06 +0200, you wrote:
Rein Klazes [EMAIL PROTECTED] writes:
I managed to fixed it in two ways:
1. put a
X11DRV_CoerceDIBSection( physDevDst, DIB_Status_InSync, FALSE );
at the end of X11DRV_BitBlt. This probably defeats the whole purpose of
these protections so:
2. Add a IsBadReadPtr( buffer, bytesToWrite) in the top of WriteFile
to force an exception and everything works.
Would that be an acceptable fix?
We don't want that at the top of WriteFile, but it could be OK to add
special handling of the INVALID_USER_BUFFER error, with a big FIXME
comment...
Special handling: try again after an IsBadReadPtr call.
Changelog:
dlls/kernel : file.c
Work around a problem where WriteFile is asked to write memory protected
by DIBSection code.
Rein.
--- wine/dlls/kernel/file.c 2005-04-01 13:31:42.0 +0200
+++ mywine/dlls/kernel/file.c 2005-05-08 19:43:38.0 +0200
@@ -431,6 +431,7 @@ BOOL WINAPI WriteFile( HANDLE hFile, LPC
NTSTATUS status;
IO_STATUS_BLOCK iosb;
PIO_STATUS_BLOCK piosb = iosb;
+int FIUBflag = 0; /* Failed Invalid User Buffer flag */
TRACE(%p %p %ld %p %p\n, hFile, buffer, bytesToWrite, bytesWritten,
overlapped );
@@ -448,8 +449,18 @@ BOOL WINAPI WriteFile( HANDLE hFile, LPC
piosb-u.Status = STATUS_PENDING;
piosb-Information = 0;
-status = NtWriteFile(hFile, hEvent, NULL, NULL, piosb,
- buffer, bytesToWrite, poffset, NULL);
+while(1)
+{
+status = NtWriteFile(hFile, hEvent, NULL, NULL, piosb,
+ buffer, bytesToWrite, poffset, NULL);
+if( status != STATUS_INVALID_USER_BUFFER || FIUBflag)
+break;
+FIUBflag = 1;
+/* NtWriteFile does not always cause page faults, generate them now */
+IsBadReadPtr( buffer, bytesToWrite);
+}
+if( FIUBflag !status) /* failed first, but succeeded after access */
+FIXME(Could not access memory (%p,%ld) at first, now OK. Protected by
DIBSection code?\n, buffer, bytesToWrite);
if (status != STATUS_PENDING bytesWritten)
*bytesWritten = piosb-Information;
Re: Now hiring
Shachar Shemesh wrote: I think recruiting is a better term. After all, most armies don't pay salaries worth of anything, and neither do we :-) Shachar Sounds good to me.. Ill post a note tomorrow evening, to give the people that take weekends off a chance to comment.
Re: Bug 2131 - 16-bit support?
Andreas Mohr wrote: Hi, As has been mentioned before on WD, cards.dll is a very obvious Microsoft screwup, since both 16bit and 32bit DLL carry the same name, which is a big no-no. I really don't think we want to patch our loader like mad to accomodate for such a stupid mistake. Figures.. they are always FUBAR'ing things lol.. Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version? Nah, its not worth the trouble to most users. They just expect it to work. OTOH, is cards.dll being used by any program other than Microsoft's Solitaire? If it isn't, then it's rather useless to care about the 16/32bit distinction anyway. Doubtful, and I agree. I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation. I agree here too, as 16-bit support is being phased out (Longhorn wont run any 16-bit apps), so theres no need for us to keep supporting it. If someone wants to play with a 16-bit program, they can make a 200mb DOS/Win3.11 Partition lol... Dustin
Re: Assertion fails in riched20; relay debug segfaults
Adrian Harvey wrote: Thanks, Dustin, that sorts the riched problem. Any ideas as to why the relay trace segfaults though? That was the bit I thought was interesting... I have now found it will segfault even if wine is not given an executable, so it's happening very early on. There are a couple of possible causes. 1) Are you using a 64-bit Linux, or 32, and if 64, are you compiling wine to 64-bit? It defaults (AFAIK) to 32, until you tell it otherwise.. 2) Im not sure (anyone else want to comment?), but I think relay was deprecated by +trace, but then again I could be wrong. If I am right about 2 though, then we should probably either at least fix relay so it doesnt segfault, or just remove it altogether. Dustin
Bugs out of my league
Bug 2938: Seemed at first like this was due to the recent patch to get Mozilla/FF installers working, but after he reverted to the Feb release and the problem still existed, it must be something else.. Bug 2919: If I am reading the backtrace right, it looks like the installer is crashing in kernel32, but then again it does the same for the quicktime installer on the same cd, so could it be configuration related? Just need someone to take a look and comment here, and I'll take care of em, until I need a patch anyways lol. Dustin
Re: Bug 2131 - 16-bit support?
Hi, On Sun, May 08, 2005 at 03:47:52PM -0500, Dustin Navea wrote: Figures.. they are always FUBAR'ing things lol.. That's just normal in software development. But MS does seem to have some special skills there ;) Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version? Nah, its not worth the trouble to most users. They just expect it to work. True. And since NT-based systems most likely only supply the 32bit version, this is what we should do as well. I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation. I agree here too, as 16-bit support is being phased out (Longhorn wont run any 16-bit apps), so theres no need for us to keep supporting it. If someone wants to play with a 16-bit program, they can make a 200mb DOS/Win3.11 Partition lol... Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it. In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support. Andreas
Re: Bug 2131 - 16-bit support?
Andreas Mohr wrote: Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it. In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support. hmm. I see your point, but at the same time, if we are trying to mimic windows, while still keeping the 16-bit code in there, shouldnt we just not work on it as much (like we are doing currently)? Basically, the way I see it, vendors are stressing themselves with making 64-bit versions of their programs, as well as keeping their 32-bit versions going, so they are probably going to scrap 16-bit support in the near future, if they haven't already. Why should we continue developing something that is being phased out by the guys that create the need for this project in the first place? Dustin
Re: Flattening of ddraw directory and renaming of files
Alexandre Julliard wrote: Christian Costa [EMAIL PROTECTED] writes: I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. While you are at it, it would be nice to merge the header files. We really don't need one header for each source file. Good idea! I will see how this can be done and send another proposal. Bye, Christian
Re: Assertion fails in riched20; relay debug segfaults
Le dim 08/05/2005 à 16:53, Dustin Navea a écrit : Adrian Harvey wrote: Thanks, Dustin, that sorts the riched problem. Any ideas as to why the relay trace segfaults though? That was the bit I thought was interesting... I have now found it will segfault even if wine is not given an executable, so it's happening very early on. There are a couple of possible causes. 1) Are you using a 64-bit Linux, or 32, and if 64, are you compiling wine to 64-bit? It defaults (AFAIK) to 32, until you tell it otherwise.. IIRC, Wine doesn't compile yet if x86-64 is the target processor (Win64), it'll compile as x86 (32 bit) instead. Culprits are some assembly routines (InterlockedIncrement et al.), plus 32 bit - 64 bit translations (unless we want a pure Win64, but I'm sure some apps will need both at the same time). So my guess is he's running a 32 bit version. 2) Im not sure (anyone else want to comment?), but I think relay was deprecated by +trace, but then again I could be wrong. If I am right about 2 though, then we should probably either at least fix relay so it doesnt segfault, or just remove it altogether. relay and trace are two different things: relay is a debug channel dumping info at each (or almost) function call, while trace is a class of debug statements shown only when asked. relay is in the same league as dll, file, opengl, while trace is in the same league as fixme, err and message. Relay shouldn't segfault, and it's still supported. I guess Adrian (if nobody else can reproduce) will need to add further traces or go through it with a debugger. Vincent
Re: Bug 2131 - 16-bit support?
Dustin Navea wrote: Andreas Mohr wrote: Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it. In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support. hmm. I see your point, but at the same time, if we are trying to mimic windows, while still keeping the 16-bit code in there, shouldnt we just not work on it as much (like we are doing currently)? Basically, the way I see it, vendors are stressing themselves with making 64-bit versions of their programs, as well as keeping their 32-bit versions going, so they are probably going to scrap 16-bit support in the near future, if they haven't already. Why should we continue developing something that is being phased out by the guys that create the need for this project in the first place? Because there are still a lot of Win16 out there that continue to just do their job. Vendors are trying to convince you that you need the latest wizbang because they need to sell. But that's not necessary in the best interest of the customer. With Wine you can still use the old software on modern computer hardware in case your old one dies. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
ERROR_NOT_READY (21) in ne_module.c
Since bug 2131 was closed I'll paste it here again: ne_module.c explicitly sets errorcode 21 (ERROR_NOT_READY) when ( LoadLibraryA()ing the owner of a 16bit dll failed or the search for the 16bit dll returned a real (.so) dll and not a symlink to the owner ) and trying to load a native version of the 16bit dll failed with ERROR_FILE_NOT_FOUND. (dlls/kernel/ne_module.c:1218) Anyone knows the reason for that behavior? -flx
Re: Commercial support
On 5/7/05, Shachar Shemesh [EMAIL PROTECTED] wrote: I really suggest we adhere to KISS - Keep It Simple. On Sat, 7 May 2005 22:17, Tom Wickline wrote: And have nothing in place if a rouge company fails to adhear to the LGPL!!! Actually, rouge companies quite like the LGPL because it fits with their philosophy, although they tend to prefer the GPL, those pinkos. Rogue companies on the other hand... In any case, the difficulty you have here is that anything you do that sets a barrier against the bad guys is also likely to set a barrier against the good guys. One of the reasons (if not the major reason) I avoid Microsoft products now is because of their increasingly intrusive approach to license enforcement. All my Microsoft stuff was fully paid for, but I wasn't interested in being treated like a crook or even a potential crook at the outset, nor was I interested in jumping through increasingly annoying hoops. In fact if they hadn't gotten so damned annoying about it I probably still wouldn't be using Linux or contributing to WINE. If you ask the question how can the WINE project stop some random company X from exploiting the situation unfairly, then perhaps hoops is a good idea. If you ask the question how can the WINE project get the maximum possible benefit from this, then hoops may not be a good idea, since the WINE project's interests lie in the largest possible pool of suppliers of services. You may get some who exploit or abuse the situation without giving back, but the goal is (IMO) not minimisation of exploitation, but maximisation of benefit. These are not necessarily complimentary goals - often you have to wear some amount of exploitation by others to get the maximum benefit for yourself.
Re: Regression in start wars jedi knight: jedi academy
On Sunday 08 May 2005 18:26, Stefan Dösinger wrote:
Hello,
I've yet another problem with the OpenGL patches from April 28: Star Wars
Jedi Knight: Jedi Academy crashes during startup.
The problematic commit is
http://www.winehq.org/hypermail/wine-cvs/2005/04/0308.html, it's not the
same problem as with Half-life. The crash happens in ntdll in
HEAP_CreateFreeBlock. The call trace shows EDIT_MakeFit on
wine/dlls/user/edit.c as the function which calls the heap functions.
The crash only occurs if the game's configuration file exists, so the first
start succeeds, but the following calls fail.
I've attached 3 +opengl,+edit traces:
before.out: Game start with config file and without the mentioned wine
patch after.out: Game start with config file and with the patch
applied(crash) nocfg.out: Game start without config file and with the
patch(no crash)
Any ideas? The whole thing looks quite strange as the crash is not directly
related to OpenGL.
Stefan
Strange behavior to see alocations problems after my patch :(
can you try to edit dlls/opengl32/wgl.c
and change internal_glGetString to something like (see below) to try
const GLubyte * internal_glGetString(GLenum name) {
return glGetString(name);
}
Regards,
Raphael
pgp1lgYlDKcV2.pgp
Description: PGP signature
Re: Regression in Half life
On Saturday 07 May 2005 12:41, Stefan Dösinger wrote:
I switched to the Xorg radeon driver which has 16 bpp support(the 2nd
column shows 16 now), and made sure that hl runs with 16bpp, but the
error still occurs.
Yes it don't work,
because you speak about frame buffer (named Color buffer on traces) when
you speak about 16bpp. I spoke about depth buffer
Good, thanks for explaining this to me. I mixed the two buffers.
Well, HL doesn't offer any depth buffer setting. There's only one console
command, gl_zmax, which is supposed to set the maximum depth buffer size.
The default is 4096, and changing this value has no effect on the error.(HL
still tries to get a 32 bit depth buffer)
:(
I sort of fixed the problem for me by forcing the depth buffer to 24 bit in
dlls/x11drv/opengl.c, but I understand that this is not a real solution. Is
there any chance for a better fix? I have no chance to fix this in the game
nor in the video driver
I will see how we can have a better fix but for now can you try attached
patch ?
Stefan
Regards,
Raphael
Index: opengl.c
===
RCS file: /home/wine/wine/dlls/x11drv/opengl.c,v
retrieving revision 1.5
diff -u -r1.5 opengl.c
--- opengl.c 28 Apr 2005 18:29:12 - 1.5
+++ opengl.c 9 May 2005 00:33:11 -
@@ -203,7 +203,15 @@
if (ppfd-iPixelType == PFD_TYPE_RGBA) {
ADD2(GLX_RENDER_TYPE, GLX_RGBA_BIT);
ADD2(GLX_BUFFER_SIZE, ppfd-cColorBits);
-TEST_AND_ADD2(ppfd-cDepthBits, GLX_DEPTH_SIZE, ppfd-cDepthBits);
+if (32 == ppfd-cDepthBits) {
+ /**
+ * for 32 bpp depth buffers force to use 24.
+ * needed as some drivers don't support 32bpp
+ */
+ TEST_AND_ADD2(ppfd-cDepthBits, GLX_DEPTH_SIZE, 24);
+} else {
+ TEST_AND_ADD2(ppfd-cDepthBits, GLX_DEPTH_SIZE, ppfd-cDepthBits);
+}
TEST_AND_ADD2(ppfd-cAlphaBits, GLX_ALPHA_SIZE, ppfd-cAlphaBits);
}
TEST_AND_ADD2(ppfd-cStencilBits, GLX_STENCIL_SIZE, ppfd-cStencilBits);
pgpHXVeJrgHgQ.pgp
Description: PGP signature
Re: Winelib's role in converting Windows applications
On Sat, 7 May 2005 16:16, Shachar Shemesh wrote: What I found, when I suggested to clients to work this way, was that the debugging tools were wholly and utterly inadequate. With all due respect (and I have TONS of respect) to winedbg, it's not up to the standards of working with ddd or the Visual Studio integrated debugger. Many years ago I made GDB understand Borland's TDS debugging format. I now use a modified gdb+insight under Linux to debug Borland compiled executables under WINE, together with some scripts that allow me to debug Borland code and GCC code in the same session. I believe the old Microsoft VC++ debug format was trivially different to Borland's TDS, although I don't know about Microsoft's current debugging formats. If winedbg already has symbol reading code perhaps that can be ported. I tried to get the Borland TDS stuff merged into the standard GDB code but there were components that needed to go into some of the libraries GDB depends on and the maintainers of those libraries were somewhat unresponsive to my submissions.
Re: ERROR_NOT_READY (21) in ne_module.c
Felix Nawothnig wrote: Since bug 2131 was closed I'll paste it here again: ne_module.c explicitly sets errorcode 21 (ERROR_NOT_READY) when ( LoadLibraryA()ing the owner of a 16bit dll failed or the search for the 16bit dll returned a real (.so) dll and not a symlink to the owner ) and trying to load a native version of the 16bit dll failed with ERROR_FILE_NOT_FOUND. (dlls/kernel/ne_module.c:1218) Anyone knows the reason for that behavior? -flx You can still comment to the bug even though it is closed. Since that bug was 2 issues in 1, I went ahead and closed it since the first issue cant/wont be fixed, but even though this issue has been posted to this list, it will be easier to keep track of if you file a bug for it as well.. Of course it could be related to the error in 2131. Some of the devs commented that 16-bit dll's use a PE header, while 32-bit ones use a NE header, and that is why it wouldnt be possible to wrap the 16-bit routines within the same dll as the 32-bit ones. This appears to honestly be for the same reason, if I understood what they were saying. Let's let them comment though, and if a bug should be filed, they will tell you to do so.. Dustin
Re: Wiki stuff
On Sun, 2005-05-08 at 13:12 +0100, Mike Hearn wrote:
More Wiki stuff: for some reason on my browser at least pre sections
aren't showing as a monospace font which makes embedded code hard to read.
Is this some CSS thing? Firefox renders text/plain files as monospace OK
so it's not my fonts.
Yes, this is indeed rather strange. We used to have this:
pre {
padding: 0.5em;
font-family: courier, monospace;
For whatever reason, asking for courier/monospace for pre causes the
browser to display proportional fonts (at least for the two of us).
A fontconfig bug? Anyway, if I comment it out and let the browser use
its default font, it works.
Explanations about why this happens are most welcomed.
--
Dimi.
Re: ERROR_NOT_READY (21) in ne_module.c
(seems WD doesn't like being CCed? Resending...) Dustin Navea wrote: You can still comment to the bug even though it is closed. I know, but my question was neigher related to bug 2131 (it's just that it triggers the code in question) nor am I sure that the behaviour is wrong - the person who wrote that line must have had something in his mind. That's why I ask here. -flx
