RE: Developing wine
I've wanted to get into wine development for some time now but I've never found a bug simple enough for me to comprehend (and, normally, that everyone else hasn't already found ten times over), let alone fix. I really want to contribute something to the project, but I don't know where to start. Any suggestions? Try and run winapi_check. cd winedir ./tools/winapi_check/winapi_check --all This will present a list of a _lot_ of _potential_ error, some of them are real some of them are not. In short be _extermely_ critical of what winapi_check says, since the heuristics used are far from perfect. The options --all shows everything, but you can also select what you want to show. See ./tools/winapi_check/winapi_check --help for details. I'm the author of winapi_check so please mail all problems/questions concerning winapi_check to me, or post it on the list if you think that other people might be intrested. PS. If you have less than 128 Mb of memory, the global checks that are done after all files are checked will be _extermely_ slow. In that case you can turn them of by using --no-global.
PE_LoadImage We need to perform base relocations
Hallo, what is the reason that we still have the fixme:win32:PE_LoadImage We need to perform base relocations for... Sorry for that ignorant question! Bye Uwe Bonnes[EMAIL PROTECTED] Free Software: If you contribute nothing, expect nothing --
Winedbg and WINE_MODREF-filename(II)
Hallo, after address separation I reported about some installation (selecting quickwork from the quicklogic installation version 8.2) not finding some needed files. I suspected the current directory not set appropriate. However after I applied the patch in the first posting about the usage of unix vs. short dos vs long dos file name in PROCESS_InitWine, I don't hit that error any longer. The patch tries to retrieve the dos short (8.3) filename and does put this filename in WINE_MODREF-filename. Bye Uwe Bonnes[EMAIL PROTECTED] Free Software: If you contribute nothing, expect nothing --
Endless loop wodPlayer -wodPlayer_WriteFragments
Hallo, trying the test version of Encarta Plus 2000 I often hit an endless loop of calls to wodPlayer_WriteFragments from wodPlayer. err:wave:wodPlayer_WriteFragments ioctl failed (22) wodPlayer_WriteFragments returns false for this failure, but wodPlayer doesn't honor the return value. Bye Uwe Bonnes[EMAIL PROTECTED] Free Software: If you contribute nothing, expect nothing --
glext.h
Could someone please explain why we need to include glext.h in wine_gl.h? It seems to compile without it (and, as I don't have it, it won't compile with it for me). -- Sam Dennis [EMAIL PROTECTED] "The strstr() function finds the first occurrence of the substring needle in the string haystack."
Re: LOCAL_GetBlock not enough space in GDI local heap
On Thu, 1 Jun 2000, Jacques Gelinas wrote: We came to the following conclusion (and we are no windows expert). Anyone may comment ? It is a limitation in wine. Its GDI library is still using a lot of 16 bits object. It is a limitation in win32. Is has to use 16 bits heap objects (then why our app is working correctly in windows and windows NT) Something odd is happening somewhere and confuse wine, so the error above does not mean much. Where is the "memory/object/resource leak in Wine" option?
Re: LOCAL_GetBlock not enough space in GDI local heap
On Thu, 1 Jun 2000, Ove Kaaven wrote: On Thu, 1 Jun 2000, Jacques Gelinas wrote: We came to the following conclusion (and we are no windows expert). Anyone may comment ? It is a limitation in wine. Its GDI library is still using a lot of 16 bits object. It is a limitation in win32. Is has to use 16 bits heap objects (then why our app is working correctly in windows and windows NT) Something odd is happening somewhere and confuse wine, so the error above does not mean much. Where is the "memory/object/resource leak in Wine" option? See http://www.winehq.com/patches970914/ for one way of trying to find such a leak. The required patch probably won't apply without modification. There might also be a more recent or better way to find such a leak. doug. [EMAIL PROTECTED]
Re: PE_LoadImage We need to perform base relocations
Uwe Bonnes [EMAIL PROTECTED] writes: what is the reason that we still have the fixme:win32:PE_LoadImage We need to perform base relocations for... This helps spotting dlls that need relocating, since it causes a performance hit. It should happen less frequently now but it can still happen with dlls that haven't been rebased properly. There isn't much we can do about it though, so the message should probably become a TRACE. -- Alexandre Julliard [EMAIL PROTECTED]
RE: LOCAL_GetBlock not enough space in GDI local heap
Jacques, In Wine there's currently a limitation on the size of the GDI heap. It is limited to 64K. This is a old limitation from Win 3.1 (16 bits), this limitation doesn't exist under Win9x/WinNT. Alexandre fixed that issue on the Corel wine tree, and I'm pretty sure eventually somebody will merge his work back into Wine-HQ source tree. It could even be you :-) If your application creates a lot of Gdi objects that could be the problem. Or maybe also your application leaks some Gdi object, if it's the case you'll run into that problem (no more space in the Gdi heap) much faster than in Windows. I think in Windows you can create 64K objects before Windows starts to complain. Stephane Lussier. Macadamian Technologies -Original Message- From: Jacques Gelinas [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 01, 2000 12:58 PM To: [EMAIL PROTECTED] Subject: LOCAL_GetBlock not enough space in GDI local heap We are trying to run a win32 application on wine and linux. The application is starting and ultimatly fails with the following message. LOCAL_GetBlock not enough space in GDI local heap (01d7) for 60 bytes The application does quite a lot before failing. It does ODBC access to a sybase server, brings its splash screen, then its main windows. Note that this application main window use quite a few widgets. It is made of a notebook object with several data browsers and input fields distributed in the various pages. Trying to pinpoint the offending piece of code (This is our own application, so we have to source), we think it is not any code in particular, but simply because there are two many widgets. Commenting out the area where our app fails, we get a little further and fails in another window. I would expect that a 32 bit application is not using the 16 bits heap much (--debugmsg +heap shows differently). Am I missing something ? The application is built using the wxWindow 1.66 toolkit. We came to the following conclusion (and we are no windows expert). Anyone may comment ? It is a limitation in wine. Its GDI library is still using a lot of 16 bits object. It is a limitation in win32. Is has to use 16 bits heap objects (then why our app is working correctly in windows and windows NT) Something odd is happening somewhere and confuse wine, so the error above does not mean much. We are getting this with the latest CVS version (well, updated may 25) - Jacques Gelinas [EMAIL PROTECTED] virtualfs: Automounting floppy, CDs, network share, etc... http://www.solucorp.qc.ca/
Re: LOCAL_GetBlock not enough space in GDI local heap
At 12:57 PM 6/1/00 -0400, you wrote:
We are trying to run a win32 application on wine and linux. The
application is starting and ultimatly fails with the following message.
LOCAL_GetBlock not enough space in GDI local heap (01d7) for 60 bytes
Try to do a bit of searching on your own with the following patch against
memory/local.c, and whatever other option of -debugmsg can be of interest
with your app.
Post again when you have found more precisely where is the problem.
Gerard
--- local.c.origSun May 28 18:19:35 2000
+++ local.c Thu Jun 1 20:28:58 2000
@@ -1068,8 +1068,11 @@
{
char *ptr = PTR_SEG_OFF_TO_LIN( ds, 0 );
-TRACE("%04x ds=%04x\n", handle, ds );
-
+if (ds == GDI_HeapSel)
+{
+MESSAGE("free %04x\n", handle);
+LOCAL_CountFree( ds );
+}
if (!handle) { WARN("Handle is 0.\n" ); return 0; }
if (HANDLE_FIXED( handle ))
{
@@ -1103,7 +1106,11 @@
char *ptr;
HLOCAL16 handle;
-TRACE("%04x %d ds=%04x\n", flags, size, ds );
+if (ds == GDI_HeapSel)
+{
+MESSAGE("alloc size=%d\n", size );
+LOCAL_CountFree( ds );
+}
if(size 0 size = 4) size = 5;
if (flags LMEM_MOVEABLE)
@@ -1170,8 +1177,11 @@
((LOCALHANDLEENTRY *)(ptr + handle))-lock == 0xff) /* An unused handle */
return 0;
-TRACE("%04x %d %04x ds=%04x\n",
- handle, size, flags, ds );
+if (ds == GDI_HeapSel)
+{
+MESSAGE("realloc %04x size=%d\n", handle, size);
+LOCAL_CountFree( ds );
+}
if (!(pInfo = LOCAL_GetHeap( ds ))) return 0;
if (HANDLE_FIXED( handle ))
@@ -1500,7 +1510,7 @@
if (arena == pArena-free_next) break;
total += pArena-size;
}
-TRACE("(%04x): returning %d\n", ds, total);
+MESSAGE("(%04x): returning %d\n", ds, total);
return total;
}
How to handle ...\\Windows\\CurrentVersion\\App Paths\\...
Hallo, the installation of Encarta 200 (Testversion) succeeded somehow. However starting Enc2000.exe from the directory it is located in, wine aborts because of the failing shrl30 DLL: err:module:BUILTIN32_dlopen failed to load libshrl30.so: /home/bon/wine/cvs/lib/libshrl30.so: cannot open shared object file: File or directory not found err:module:fixup_imports Module SHRL30.dll not found But in system.reg, there is an entry [MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\Enc2000.exe] 959863964 "Path"="d:\\finden\\enc2000;d:\\finden\\enc2000\\Update 2000;\\Microsoft Shared\\Reference Titles" "UpdatesPath"="d:\\finden\\enc2000\\Update 2000\\" pointing to the directory containing the DLL. Reading the docs about "App Paths", I read that the shell spawning the executable should read that registry value and prepend it to the (inherited) path before calling CreateProcess. Any ideas how to handle this problem? Bye Uwe Bonnes[EMAIL PROTECTED] Free Software: If you contribute nothing, expect nothing --
toolbar crash fix
Here's a patch for dlls/comctl32/toolbar.c
It corrects a potential crash and removes the one pixel of garbage
that's appearing at the bottom of the toolbar.
--- /devel/corelwineVirgin/corelwine/dlls/comctl32/toolbar.cMon May 15 10:47:35
2000
+++ toolbar.c Thu Jun 1 16:03:39 2000
@@ -952,9 +952,9 @@
if (!(infoPtr-himlDef)) {
/* create new default image list */
TRACE ("creating default image list!\n");
- /* It seems that the image list created is 1 pixel taller than the bitmap
height */
+
infoPtr-himlDef =
- ImageList_Create (infoPtr-nBitmapWidth, infoPtr-nBitmapHeight + 1,
+ ImageList_Create (infoPtr-nBitmapWidth, infoPtr-nBitmapHeight,// + 1,
ILC_COLOR | ILC_MASK, nButtons, 2);
infoPtr-himlInt = infoPtr-himlDef;
}
@@ -1687,13 +1688,16 @@
lpTbInfo-fsState = btnPtr-fsState;
if (lpTbInfo-dwMask TBIF_STYLE)
lpTbInfo-fsStyle = btnPtr-fsStyle;
-if (lpTbInfo-dwMask TBIF_TEXT) {
- if ((btnPtr-iString = 0) || (btnPtr-iString infoPtr-nNumStrings))
- lstrcpynWtoA (lpTbInfo-pszText,
+ if (lpTbInfo-dwMask TBIF_TEXT) {
+
+ /*make sure infoPtr-strings has been allocated before dereferencing
+it! */
+ if ( infoPtr-strings ((btnPtr-iString = 0) || (btnPtr-iString
+infoPtr-nNumStrings)))
+ {
+ lstrcpynWtoA (lpTbInfo-pszText,
(LPWSTR)infoPtr-strings[btnPtr-iString],
lpTbInfo-cchText);
+ }
}
-
return nIndex;
}
Wine Status
I've created a "WWN Wine Status page" at http://www.winehq.com/News/status.html Is there anything I should change or add? (And I'm still kind of wondering what to write about for next WWN...)
Re: Developing wine
Andreas Mohr [EMAIL PROTECTED] writes: 4. Write WineHQ mirror scripts as needed and asked for by Bertho Stultiens. I missed that one. What kind of mirror script i needed? -- Peter Bortas http://peter.bortas.org Roxen IS http://www.roxen.com
