- Wine-Devel - list.winehq.org

Can't get a minimal Windows app running with winelib
by Chris Seaton Feb. 12, 2004

Feb. 12, 2004

I can't get a minimal Windows app to run with winelib (it compiles fine). I'm compiling ----------------------------------- #include <stdlib.h> #include <windows.h> int WINAPI WinMain(HINSTANCE Instance, HINSTANCE PreviousInstance, LPSTR CommandLine, int ComandShow) { return EXIT_SUCCESS; } ----------------------------------- With winegcc -mwindows -o test.exe -Iwine/windows test.c -lwine -lkernel32.dll -luser32.dll Which succeeds but when I run ./test I get err:heap:HEAP_GetPtr Invalid heap (nil)! Segmentation fault Any ideas, anyone? Chris Seaton

2 2

mistake in wine user guide
by lazybones Feb. 12, 2004

Feb. 12, 2004

section 2.2.2.3 - getting wine for freebsd http://www.winehq.com/site/docs/wine-user/getting-wine-package#GETTING-FREE… $ su - # cd /usr/port/emulators/ (should be /usr/ports/emulators/wine/) # make # make install # make clean lazybones

1 0

LOCAL: Not enough space in GDI heap
by Fabian Cenedese Feb. 12, 2004

Feb. 12, 2004

Hi When trying to run a program I get these messages: trace:font:GetTextMetricsW text metrics: Weight = 400 FirstChar = 32 AveCharWidth = 6 Italic = 0 LastChar = 65532 MaxCharWidth = 35 UnderLined = 0 DefaultChar = 0 Overhang = 0 StruckOut = 0 BreakChar = 32 CharSet = 0 PitchAndFamily = 27 -------------------- InternalLeading = 3 Ascent = 13 Descent = 3 Height = 16 trace:font:X11DRV_SelectFont hdc=0x74, hfont=0xa6 trace:font:X11DRV_SelectFont dc->gdiFont = 0x40378f28 trace:ole:OLEFontImpl_SetRatio (0x47d85a60)->(96, 2540) trace:ole:OLEFontImpl_get_hFont (0x47d85a60)->(0x408bf0bc) trace:ole:OLEFontImpl_get_Size (0x47d85a60)->(0x408bf034) err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes trace:ole:OLEFontImpl_get_hFont Returning (nil) wine: Unhandled exception (thread 0009), starting debugger... I had a look at this LOCAL_GetBlock function. There is already code with some FIXME comments, but it's all #ifdef 0'd out. So that means it's not tested or not even supposed to work. Is there something else I could do to increase my GDI heap? Thanks bye Fabi

3 9

Compatability problem in wineps driver
by gslink Feb. 12, 2004

Feb. 12, 2004

It appears that a check needs to be made in ps.c. The method PSDRV_WriteSetFont passes the parameter size. In some early Win 95 versions there was a bug that required that parameter to be negative and some early windows programs make size negative. This produces garbage. It appears that Windows checks and if that parameter is negative that it is changed to posative. I put a patch to make this check into our copies of Wine without any problem but I do not suggest a patch. I would like the maintainer of the Postscript driver to do that as there is a possibility of other consequences. It may be that this change can be made in ps.c or it may be that it must be accompanied by a flag in the config file also. One program that will not run without the patch is DeScribe but I know there are others.

2 2

Re: SelectionMark
by Dimitrie O. Paun Feb. 12, 2004

Feb. 12, 2004

On February 11, 2004 02:07 pm, Aric Stewart wrote: > + if (bResult && lvItem.stateMask & LVIS_SELECTED && > + lvItem.state&LVIS_SELECTED && ((infoPtr->nSelectionMark > + == -1) || (lvItem.iItem <= infoPtr->nSelectionMark))) That's some funky indentation here :) > + { > + infoPtr->nSelectionMark = -1; > + int i = 0; > + for (i = 0; i < infoPtr->nItemCount; i++) > + { > + if (infoPtr->uCallbackMask & LVIS_SELECTED) > + { > + if (LISTVIEW_GetItemState(infoPtr, i, LVIS_SELECTED)) ^^^^^^^ here as well, any particular reason? -- Dimi.

3 2

Re: Fix Potential Deadlock in LdrLoadDll
by Alexandre Julliard Feb. 12, 2004

Feb. 12, 2004

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > This patch fixes a potential deadlock in LdrLoadDll as it tries to call > LdrUnloadDll with the loader lock held, resulting in deadlock once > LdrUnloadDll also tries to enter the loader critical section. > This only happens on process_attach failure. This cannot deadlock, a critical section is reentrant. There must be some other issue here. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: widl function pointers
by Alexandre Julliard Feb. 11, 2004

Feb. 11, 2004

Ove Kaaven <ovek(a)arcticnet.no> writes: > Incidentally, that means I also reversed his indentation suppression of > the arguments of these function pointers, but I don't see the "old" > indentation as a problem - after all, MIDL does not suppress indentation > of function pointer arguments, why should widl? > > But I could probably submit a patch with Alexandre's indentation changes > preserved if he's really attached to it. I don't really care about the indentation, but the reason for the change was so that we could use the proper type in the METHODS macro without having to add special support for escaping EOLs. Your patch avoids this issue by declaring function pointers as void*, but I'm not sure I agree that this is the right thing to do. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Resend of Update to heap.c
by Alexandre Julliard Feb. 11, 2004

Feb. 11, 2004

jeffl <jeffl(a)defcen.gov.au> writes: > When browsing ntdll/heap.c I noticed that the condition set would > cause a memory leak if the unlikely event ever occured. The patch > causes a warning to be issued as well so that there is a record. Why would it cause a memory leak? This thing is only used for clearing the block when debugging. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/dlls/ntdll virtual.c
by Mike Hearn Feb. 11, 2004

Feb. 11, 2004

> Log message: > Don't request PROT_EXEC permissions when mapping an image file to > avoid problems on noexec filesystems with kernel 2.6. http://people.redhat.com/mingo/exec-shield/ANNOUNCE-exec-shield According to the exec-shield paper, its effects can include revealing "bugs in applications that assume PROT_READ implies PROT_EXEC" due to the funky things it does with relocations into the ASCII-armour. Not sure but it might be worth ensuring mprotect is called afterwards.... Just a random thought, I don't think it'd matter in this case as we use MAP_FIXED anyway.

2 1

Re: can the wine debugger be disabled
by Dmitry Timoshkov Feb. 11, 2004

Feb. 11, 2004

"Cristóvão B. B. Dalla Costa" <cbraga(a)fs.inf.br> wrote: > However, in the company I work for we will replace a hundred or so PCs > which run Windows with Linux PCs. The people using these PCs are the > most clueless possible, and we want to avoid aggravation from them > when/if the Wine debugger shows up when an application fails. That's > inacceptable since those people would be lost and not know what to do. > However, I cannot figure out how to do so using configuration files > (wineserver -d0 rarely does the trick, and I don't think we can rely on > that). The easiest way for you is to edit the following registry key: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug] or remove it altogether. -- Dmitry.

1 0