wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Serialization of DEBUGMSG needed
by Uwe Bonnes 21 May '05

21 May '05

Hallo, running CVS wine on my dual pentium machine with debugmessages enabled, I now see that both CPUs spit out debug output at the same time, leading to garbled output, like: 000b:Call gdi32.GetCurrentObject(0000136c,00000005) ret=7f0013:Ca000b:Ret gdi32.GetCurrentObject() retval=00000044 ret=7fef3e40 0013:Ret ntdll.NtUnmapViewOfSection() retval=00000000 ret=77b000b:R0013:Ret kernel32.UnmapViewOfFile() retval=00000001 re000b:Call g0013 :Ret wininet.CommitUrlCacheEntryW() re000b:Ret gdi32.GDI_ReleaseObj() retval=00000000 ret=7fef3f1d Is this an artefact of my machine or a wine problem? In the latter case, as Hyperthreading amd Multicore machines will get more available with time, a fix would be appreciated. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

[RFC] upmfs - page-unaligned mmap() for Linux
by Dan Aloni 21 May '05

21 May '05

Hello All, I'd like to bring this to your attention and review, hopefully to spawn some constructive discussions. The code was a result of experiments I've been doing lately concering some new idea not especially related to WINE. To quote myself from http://wiki.winehq.org/UnalignedMmap: ---- Large majority of PE executables have sections that are page-aligned in memory but not in the PE file image. Linux's mmap() doesn't support mappings that are not aligned to page boundries with regard to file offsets. Currently it forces wineserver to fake mmap() by allocating anonymous pages and using read() to load the sections. In dlls/ntdll/virtual.c, comment above map_file_into_view() says: "Linux kernels before 2.4.x can support non page-aligned offsets, as long as the offset is aligned to the filesystem block size. This is a big performance gain so we want to take advantage of it." These days are long gone, we are now using Linux 2.6, and it doesn't support unaligned mmap(). Enter upmfs. This simple kernel module exports this function to userspace using '/proc': * int mmap_offset(int fd, unsigned long offset); Given an fd and an offset, a new fd is returned. Using mmap() on that new fd, the mapping will be aligned with the given offset, which can be smaller than PAGE_SIZE. A wineserver implementation can check the existance of that module in the kernel (i.e "/proc/upmfs/interface" exists) and use its functionality. ---- The code for the upmfs source package is attached to this post. -- Dan Aloni da-x(a)colinux.org

1 0

environment-priority
by Detlef Riekenberg 21 May '05

21 May '05

Hi While working with wine, I found the way how wine handles the environment. example for "TMP": 1. HCU\Environment\TMP 2. HKLM\System\CurrentControlSet\Control\Session Manager\Environment\TMP 3. $WINETMP 4. $WINEPREFIX/config (TEMP) 5. Buildin Default (c:\windows\temp) During "wineprefixcreate", "TMP" and "TEMP" are created for entry 2 (HKLM\..) from entry 4 ($WINEPREFIX/config : TEMP) with a fallback to entry 5 (c:\windows\temp), but entry 3 ($WINETMP) is ignored. When I delete the entry 2 (HKLM\..), then entry 3 is used ($WINETMP). IMHO, "$WINETMP" should overwrite all other locations. PS: Tested only "WINETMP", but there are also $WINETEMP, WINEHOME and WINEPATH. -- By By ... ... Detlef

1 0

[WINEDOCS] WINEPREFIX and other variables
by Detlef Riekenberg 21 May '05

21 May '05

Hi While reading the source to learn how wine works internal, i found some things not found in the documentation (wine-user.pdf, wine-devel.pdf or winelib-user.pdf): environment: WINEPATH WINEHOME WINETEMP WINETMP "WINEPREFIX" is not new for me (working with wineprefixcreate), but the documentation is "rare". I found many references for "~/.wine" (winetools is worst case in this). Is someone working on the documentation for this? Target-Documentation for this ? [IMHO: (wine|winelib)-(user|devel)] PS: sgml is a black hole for me atm. -- By By ... ... Detlef

3 2

Re: Detecting ulimit problem
by Daniel Kegel 21 May '05

21 May '05

efrias(a)syncad.com wrote: > http://bugs.winehq.org/show_bug.cgi?id=2609 > [Proposed fix:] > struct rlimit address_limits; > int required_address_space = 1024 * 1024 * 1400; /* 1400M */ > getrlimit(RLIMIT_AS, &address_limits); > if (address_limits.rlim_max < required_address_space) > WINE_WARN("Your virtual memory limit is set to %dk, which > will\nprobably prevent wine from loading correctly. If you get an > error,\nincrease the limit with 'ulimit -v' to at least %dk.\n", > address_limits.rlim_max / 1024, required_address_space / 1024); Looks groovy to me. But it will completely annoy people using 2.4 kernels, which by default have only 896MB of user address space, won't it? (I may be confused here, but that's what I remember.) See e.g. http://mail.nl.linux.org/kernelnewbies/2004-12/msg00073.html + On a system with 1 gigabyte of memory, you may get 896 MB of + "user memory" and 128 megabytes of "high memory" with this + selection. This is the usual setting. So I'd encourage you to submit a patch to do this, but only after testing on Red Hat 9.0 to make sure I'm wrong :-)

5 5

Re: Implement RegNotifyChangeKeyValue on top of NtNotifyChangeKey
by Dimitrie Paun 21 May '05

21 May '05

> This patch removes the last server call from advapi32 and we should keep > it free from server calls to reduce the effects of the changing of a > server interface. Nice. BTW, what DLLs make server calls? Any other that shoudn't but still do? -- Dimi.

3 2

Re: crypt32 [4/4]: (un)protectdata test suite
by Alexandre Julliard 20 May '05

20 May '05

Kees Cook <kees(a)outflux.net> writes: > ChangeLog: > Create basic test suite for CryptProtectData/CryptUnprotectData. The tests fail here: ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so protectdata.c && touch protectdata.ok err:crypt:CryptProtectData CryptAcquireContextW failed protectdata.c:89: Test failed: Encrypting without entropy. protectdata.c:91: Test failed: Wrong (2148073494) GetLastError seen err:crypt:CryptProtectData CryptAcquireContextW failed protectdata.c:99: Test failed: Encrypting with entropy. protectdata.c:101: Test failed: Wrong (2148073494) GetLastError seen err:crypt:CryptProtectData CryptAcquireContextW failed protectdata.c:111: Test failed: Encrypting with entropy and no description. protectdata.c:113: Test failed: Wrong (2148073494) GetLastError seen protectdata.c:127: Test failed: CryptProtectData failed to run, so I can't test its output make[3]: *** [protectdata.ok] Error 7 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [QCAP] Final patch
by Dimi Paun 20 May '05

20 May '05

On Fri, 2005-05-20 at 00:42 +0200, Maarten Lankhorst wrote: > m3h, v4l driver for vfwcapture.. please leave the ERR notice on > initialisation intact, thank you :) I think you've overusing ERR(). ERR() should be called to signal an internal error such as inconsistent state, not something that the function is designed to handle. > + capBox->grab_buf = CoTaskMemAlloc(sizeof(struct video_mmap) * capBox->buffers); > + if(!capBox->grab_buf) { > + ERR("Out of memory?\n"); > + munmap(capBox->pmap, capBox->gb_buffers.size); > + return E_OUTOFMEMORY; > + } The function knows how to deal with this condition gracefully, just get rid of the ERR(). > + if (!capBox->grab_data) > + { > + ERR("%p: Out of memory?\n", capBox); > + return E_OUTOFMEMORY; > + } Ditto. Also the code is more clear if you just do: if (!capBox->grab_data) return E_OUTOFMEMORY; > + if (!capBox) { > + ERR("Out of memory\n"); > + return E_OUTOFMEMORY; > + } Ditto. > + if (stat (device, &st) == -1) { > + ERR("%s: %s\n", device, strerror(errno)); > + CoTaskMemFree(capBox); > + return E_FAIL; > + } Why is this a ERR()? > + > + if (!S_ISCHR (st.st_mode)) { > + ERR("%s: Not a device\n", device); > + CoTaskMemFree(capBox); > + return E_FAIL; > + } And why this? > + > + capBox->fd = open(device, O_RDWR | O_NONBLOCK); > + if (capBox->fd == -1) { > + ERR("%s: Failed to open: %s\n", device, strerror(errno)); > + CoTaskMemFree(capBox); > + return E_FAIL; > + } This is a TRACE or WARN at most. > + ERR("Tinkerer detected? Thou shalt not define HAVE_V4L2\n"); > + CoTaskMemFree(capBox); > + close(capBox->fd); > + return E_FAIL; This is a FIXME. And so on... -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

4 6

Q for AJ? Re: UT2003 Windowing Regression - Yet Another nights effort...
by Ann and Jason Edmeades 20 May '05

20 May '05

Ok, I need advice on this one... I have been purely testing on windows, no wine involvement, to see what happens when I do various things. My test program doesn't do anything in the WM_PAINT handler at all. This results in the machine sitting at 100% CPU processing WM_PAINT messages. 1. Changing the WM_PAINT process to post another user message, results in alternating message posted and WM_PAINT messages, ie normal user message processing is occurring 2. Posting a user message inside the user message handler, results in WM_PAINT being driven, followed by looping processing the user messages - ie WM_PAINT messages are not on the message queue 3. RedrawWindow with update now jumps straight into the message routine with a WM_PAINT, but if we do nothing in that routine, it does indeed proceed to the line after the RedrawWindow call. Wine never leaves the updatenow processing because it loops until the whole region is validated. I believe staying in the updatenow code in wine is incorrect. I think what happens is that when the message dispatch loop gets an empty queue and the window has an invalid region, then a WM_PAINT is returned. So... Can we / I please remove the loop? :-)) What other tests can I do under windows to confirm the behaviour? Jason

2 4

Re: [OLE #90] Marshal Objects & Monikers into the ROT
by Mike Hearn 20 May '05

20 May '05

On Fri, 20 May 2005 14:57:49 +0100, Robert Shearman wrote: > +static inline HRESULT WINAPI > +IrotRegister(DWORD *cookie) > +{ > + static DWORD last_cookie = 1; > + *cookie = InterlockedIncrement(&last_cookie); > + return S_OK; > +} I'm sure there's a good reason for this, but why isn't the last cookie an object member of the ROT? And what are all the Irot* methods given that this is a static inline? Could the need for these functions be documented? thanks -mike

1 0

[Fwd: [Bug 2969] New: CVS Regression - "Pure Virtual Function Call"]
by Dustin Navea 20 May '05

20 May '05

This one has been pre-diagnosed and the patch has been found. All relevant info is in the message from wine-bugs, attached below, any additional info needed? Let me know and I will request it from the author.. Dustin -------- Original Message -------- Subject: [Bug 2969] New: CVS Regression - "Pure Virtual Function Call" Date: Thu, 19 May 2005 15:03:13 -0500 From: Wine Bugs <wine-bugs(a)winehq.org> Reply-To: wine-devel(a)winehq.org To: wine-bugs(a)winehq.org http://bugs.winehq.org/show_bug.cgi?id=2969 Summary: CVS Regression - "Pure Virtual Function Call" Product: Wine Version: CVS Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-binary AssignedTo: wine-bugs(a)winehq.org ReportedBy: Andrew.Talbot(a)talbotville.com Patch http://cvs.winehq.org/patch.py?id=17288 causes Personal StockMonitor Gold to crash with error dialog: 'Microsoft Visual C++ Runtime Error':'Runtime Error! R6025 - pure virtual function call.' -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

2 1

Re: Another debugging tutorial
by gslink 20 May '05

20 May '05

There is only one problem with these documents. There aren't nearly enough of them!

1 0

shell32 icon indices and the "intialization hack"
by Michael Jung 20 May '05

20 May '05

Hello, Since the application of this patch http://www.winehq.org/hypermail/wine-cvs/2005/05/0232.html the "open folder" icon isn't displayed correctly any more in the file dialogs. There's a note in shell32/iconcache.c which states > hack to load the resources from the shell32.dll under a different dll name > will be removed when the resource-compiler is ready Furthermore shell32's shellfolders do some fancy stuff with the icon indices in their IShellFolder::GetIconLocation methods (they invert the indices). Is this the way windows does it? Could someone point me to information on this and the hack mentioned above? Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 1

Re: GDI: move 16-bit handles to the large heap
by Andreas Mohr 20 May '05

20 May '05

Hi, On Fri, May 20, 2005 at 12:18:07AM -0400, Dimi Paun wrote: > So we have to export a Wine specific function from GDI. > Big deal... :) What can we do, we have to cut the > Gordian Knot [http://www.gordiansolutions.com/TheKnot.htm]. Well, umm, anyone an idea how Windows does this? ;-) (I assume that Windows has to do the same thing somehow) When I worked on the GDI system object mechanisms, I investigated that, but didn't find anything which could have done that. OTOH I'd bet that the Windows way of achieving this is equally messy... Andreas Mohr

2 1

Re: comctl32: Update LVGROUP struct to match msdn
by Dmitry Timoshkov 20 May '05

20 May '05

"James Hawkins" <truiken(a)gmail.com> wrote: > Changelog > * Update LVGROUP struct to match msdn. > --- include/commctrl.h 18 May 2005 09:43:23 -0000 1.144 > +++ include/commctrl.h 20 May 2005 05:14:22 -0000 > @@ -3439,6 +3439,8 @@ typedef struct LVGROUPA > UINT mask; > LPSTR pszHeader; > int cchHeader; > + LPSTR pszFooter; > + int cchFooter; > int iGroupId; > UINT stateMask; > UINT state; > @@ -3451,6 +3453,8 @@ typedef struct LVGROUPW > UINT mask; > LPWSTR pszHeader; > int cchHeader; > + LPWSTR pszFooter; > + int cchFooter; It appears that PSDK headers don't have LVGROUPA/W structures at all, but a unicode only LVGROUP instead. -- Dmitry.

1 0

Wiki tips
by Mike Hearn 20 May '05

20 May '05

A few tips on how to use the Wiki: - Embedding a block of code is best done like this: {{{ #!cplusplus if (foo) { bar; } }}} This will give it nice syntax highlighting, a monospace font and line numbers. - Unfortunately StudlyCaps as the Win32 API uses them is the same style that triggers WikiWording. To fix this surround Win32 API names like CreateWindow or IShellLink with backticks: eg `IShellLink`. This will disable WikiWording in that section and also format them with a monospace font. - If you have a word that it wants to WikiWord, prefix it with a ! mark. Don't do this just because there's no page for it yet, somebody may create one in future. Also don't do it for Win32 API names, use backticks instead. But it can be useful for some things. Those Wine developers who haven't yet made a todo list, go do it! It's really informative to be able to see what people are working on (not to mention interesting) and this way we can help cut down on duplication of effort. thanks -mike

5 4

Re: listview: Select the item under the point (x,y) in MouseHover
by Dimi Paun 20 May '05

20 May '05

On Thu, 2005-05-19 at 19:38 -0500, James Hawkins wrote: > + if (!lpLVItem) > + return FALSE; Please don't check for NULL, it's an internal function, you should never pass NULL there. And if you do, it should crash :) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Move GDI handles to the large heap
by Dimitrie O. Paun 19 May '05

19 May '05

I'm not sure if this is what Alexandre had in mind, but here it goes... ... I just realized that some things may break. In particular, what do we do with windows/syscolor.c:SYSCOLOR_MakeObjectSystem() Index: dlls/gdi/gdiobj.c =================================================================== RCS file: /var/cvs/wine/dlls/gdi/gdiobj.c,v retrieving revision 1.12 diff -u -p -r1.12 gdiobj.c --- dlls/gdi/gdiobj.c 18 May 2005 09:50:43 -0000 1.12 +++ dlls/gdi/gdiobj.c 19 May 2005 15:43:31 -0000 @@ -76,8 +76,6 @@ static CRITICAL_SECTION_DEBUG critsect_d }; static SYSLEVEL GDI_level = { { &critsect_debug, -1, 0, 0, 0, 0 }, 3 }; -static WORD GDI_HeapSel; - inline static BOOL get_bool(char *buffer) { return (buffer[0] == 'y' || buffer[0] == 'Y' || @@ -602,7 +600,6 @@ inline static void dec_ref_count( HGDIOB */ BOOL GDI_Init(void) { - HINSTANCE16 instance; HKEY hkey; GDIOBJHDR *ptr; LOGFONTW default_gui_font; @@ -612,9 +609,6 @@ BOOL GDI_Init(void) if (RegOpenKeyA(HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\Tweak.Fonts", &hkey)) hkey = 0; - /* create GDI heap */ - if ((instance = LoadLibrary16( "GDI.EXE" )) >= 32) GDI_HeapSel = instance | 7; - /* create stock objects */ stock_objects[WHITE_BRUSH] = CreateBrushIndirect( &WhiteBrush ); stock_objects[LTGRAY_BRUSH] = CreateBrushIndirect( &LtGrayBrush ); @@ -710,34 +704,9 @@ inline static GDIOBJHDR *alloc_large_hea void *GDI_AllocObject( WORD size, WORD magic, HGDIOBJ *handle, const struct gdi_obj_funcs *funcs ) { GDIOBJHDR *obj = NULL; - HLOCAL16 hlocal; _EnterSysLevel( &GDI_level ); - switch(magic) - { - case PEN_MAGIC: - case BRUSH_MAGIC: - if (GDI_HeapSel) - { - STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); - HANDLE16 oldDS = stack16->ds; - - stack16->ds = GDI_HeapSel; - if ((hlocal = LocalAlloc16( LMEM_MOVEABLE, size ))) - { - assert( hlocal & 2 ); - obj = MapSL(LocalLock16( hlocal )); - *handle = (HGDIOBJ)(ULONG_PTR)hlocal; - } - stack16->ds = oldDS; - if (!hlocal) goto error; - break; - } - /* fall through */ - default: - if (!(obj = alloc_large_heap( size, handle ))) goto error; - break; - } + if (!(obj = alloc_large_heap( size, handle ))) goto error; obj->wMagic = magic|OBJECT_NOSYSTEM; obj->dwCount = 0; @@ -762,34 +731,16 @@ error: */ void *GDI_ReallocObject( WORD size, HGDIOBJ handle, void *object ) { - HGDIOBJ new_handle; void *new_ptr = NULL; + int i; - if ((UINT_PTR)handle & 2) /* GDI heap handle */ - { - STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); - HANDLE16 oldDS = stack16->ds; - HLOCAL16 h = LOWORD(handle); - - stack16->ds = GDI_HeapSel; - LocalUnlock16( h ); - if ((new_handle = (HGDIOBJ)(ULONG_PTR)LocalReAlloc16( h, size, LMEM_MOVEABLE ))) - { - assert( new_handle == handle ); /* moveable handle cannot change */ - new_ptr = MapSL(LocalLock16( h )); - } - stack16->ds = oldDS; - } - else + i = ((ULONG_PTR)handle >> 2) - FIRST_LARGE_HANDLE; + if (i >= 0 && i < MAX_LARGE_HANDLES && large_handles[i]) { - int i = ((ULONG_PTR)handle >> 2) - FIRST_LARGE_HANDLE; - if (i >= 0 && i < MAX_LARGE_HANDLES && large_handles[i]) - { - new_ptr = HeapReAlloc( GetProcessHeap(), 0, large_handles[i], size ); - if (new_ptr) large_handles[i] = new_ptr; - } - else ERR( "Invalid handle %p\n", handle ); + new_ptr = HeapReAlloc( GetProcessHeap(), 0, large_handles[i], size ); + if (new_ptr) large_handles[i] = new_ptr; } + else ERR( "Invalid handle %p\n", handle ); if (!new_ptr) { TRACE("(%p): leave %ld\n", handle, GDI_level.crst.RecursionCount); @@ -805,30 +756,17 @@ void *GDI_ReallocObject( WORD size, HGDI BOOL GDI_FreeObject( HGDIOBJ handle, void *ptr ) { GDIOBJHDR *object = ptr; + int i; object->wMagic = 0; /* Mark it as invalid */ object->funcs = NULL; - if ((UINT_PTR)handle & 2) /* GDI heap handle */ + i = ((ULONG_PTR)handle >> 2) - FIRST_LARGE_HANDLE; + if (i >= 0 && i < MAX_LARGE_HANDLES && large_handles[i]) { - STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); - HANDLE16 oldDS = stack16->ds; - HLOCAL16 h = LOWORD(handle); - - stack16->ds = GDI_HeapSel; - LocalUnlock16( h ); - LocalFree16( h ); - stack16->ds = oldDS; - } - else /* large heap handle */ - { - int i = ((ULONG_PTR)handle >> 2) - FIRST_LARGE_HANDLE; - if (i >= 0 && i < MAX_LARGE_HANDLES && large_handles[i]) - { - HeapFree( GetProcessHeap(), 0, large_handles[i] ); - large_handles[i] = NULL; - } - else ERR( "Invalid handle %p\n", handle ); + HeapFree( GetProcessHeap(), 0, large_handles[i] ); + large_handles[i] = NULL; } + else ERR( "Invalid handle %p\n", handle ); TRACE("(%p): leave %ld\n", handle, GDI_level.crst.RecursionCount); _LeaveSysLevel( &GDI_level ); return TRUE; @@ -845,37 +783,15 @@ BOOL GDI_FreeObject( HGDIOBJ handle, voi void *GDI_GetObjPtr( HGDIOBJ handle, WORD magic ) { GDIOBJHDR *ptr = NULL; + int i; _EnterSysLevel( &GDI_level ); - if ((UINT_PTR)handle & 2) /* GDI heap handle */ - { - STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); - HANDLE16 oldDS = stack16->ds; - HLOCAL16 h = LOWORD(handle); - - stack16->ds = GDI_HeapSel; - ptr = MapSL(LocalLock16( h )); - if (ptr) - { - if (((magic != MAGIC_DONTCARE) && (GDIMAGIC(ptr->wMagic) != magic)) || - (GDIMAGIC(ptr->wMagic) < FIRST_MAGIC) || - (GDIMAGIC(ptr->wMagic) > LAST_MAGIC)) - { - LocalUnlock16( h ); - ptr = NULL; - } - } - stack16->ds = oldDS; - } - else /* large heap handle */ + i = ((UINT_PTR)handle >> 2) - FIRST_LARGE_HANDLE; + if (i >= 0 && i < MAX_LARGE_HANDLES) { - int i = ((UINT_PTR)handle >> 2) - FIRST_LARGE_HANDLE; - if (i >= 0 && i < MAX_LARGE_HANDLES) - { - ptr = large_handles[i]; - if (ptr && (magic != MAGIC_DONTCARE) && (GDIMAGIC(ptr->wMagic) != magic)) ptr = NULL; - } + ptr = large_handles[i]; + if (ptr && (magic != MAGIC_DONTCARE) && (GDIMAGIC(ptr->wMagic) != magic)) ptr = NULL; } if (!ptr) @@ -895,15 +811,6 @@ void *GDI_GetObjPtr( HGDIOBJ handle, WOR */ void GDI_ReleaseObj( HGDIOBJ handle ) { - if ((UINT_PTR)handle & 2) - { - STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); - HANDLE16 oldDS = stack16->ds; - - stack16->ds = GDI_HeapSel; - LocalUnlock16( LOWORD(handle) ); - stack16->ds = oldDS; - } TRACE("(%p): leave %ld\n", handle, GDI_level.crst.RecursionCount); _LeaveSysLevel( &GDI_level ); } @@ -1479,30 +1386,29 @@ DWORD WINAPI GdiSetBatchLimit( DWORD lim DWORD WINAPI GdiSeeGdiDo16( WORD wReqType, WORD wParam1, WORD wParam2, WORD wParam3 ) { - STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); - HANDLE16 oldDS = stack16->ds; DWORD ret = ~0UL; - stack16->ds = GDI_HeapSel; switch (wReqType) { case 0x0001: /* LocalAlloc */ - ret = LocalAlloc16( wParam1, wParam3 ); + WARN("LocalAlloc16(%x, %x): ignoring\n", wParam1, wParam3); + ret = 0; break; case 0x0002: /* LocalFree */ - ret = LocalFree16( wParam1 ); + WARN("LocalFree16(%x): ignoring\n", wParam1); + ret = 0; break; case 0x0003: /* LocalCompact */ - ret = LocalCompact16( wParam3 ); + WARN("LocalCompact16(%x): ignoring\n", wParam3); + ret = 65000; /* lie about the amount of free space */ break; case 0x0103: /* LocalHeap */ - ret = GDI_HeapSel; + WARN("LocalHeap16(): ignoring\n"); break; default: WARN("(wReqType=%04x): Unknown\n", wReqType); break; } - stack16->ds = oldDS; return ret; } @@ -1544,15 +1450,7 @@ void WINAPI FinalGdiInit16( HBRUSH16 hPa */ WORD WINAPI GdiFreeResources16( DWORD reserve ) { - STACK16FRAME* stack16 = MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); - HANDLE16 oldDS = stack16->ds; - WORD ret; - - stack16->ds = GDI_HeapSel; - ret = (WORD)( (int)LocalCountFree16() * 100 / (int)LocalHeapSize16() ); - stack16->ds = oldDS; - - return ret; + return 90; /* lie about it, it shouldn't matter */ } -- Dimi.

3 2

Another debugging tutorial
by Mike Hearn 19 May '05

19 May '05

This time, it's how to debug PE Explorer hanging when you double click on a DLL in the file open dialog (fixed in CVS). http://wiki.winehq.com/Debugging_the_PE_Explorer_file_open_dialog Newbie developers, I crave your feedback. Are these actually useful or am I wasting my time? Share and enjoy! thanks -mike

4 3

No rule to make target distclean ??
by Dustin Navea 19 May '05

19 May '05

Im troubleshooting bug 2962 http://bigs.winehq.com/show_bug.cgi?id=2962 and I had the reporter revert to the october release. But when trying to compile it, it failed, so I told him to do make distclean.. Now he's getting the no rule to make target distclean... Im stumped as to what to do... Can someone help me out? Dustin

2 1

Re: [include] fix in winternl
by Paul Vriens 19 May '05

19 May '05

> *SystemDriverInformation should be called SystemModuleInformation because > it provides information on any module in system address space, not only > drivers. > > ChangeLog: Rename SystemDriverInformation to SystemModuleInformation > > Ivan. > * > > Could you also change ntdll/nt.c as it's used there. (didn't that give compile problems ?). Cheers, Paul.

1 0

Detecting ulimit problem
by Eric Frias 19 May '05

19 May '05

I just ran into bug 2609: http://bugs.winehq.org/show_bug.cgi?id=2609 which is that wine fails to initialize when the user has a ulimit for virtual memory (address space) set to less than around 1300MB. This is something wine could test for and issue a warning. I know this isn't technically a problem with wine, but it's pretty unusual for an application to require that much address space. A user might not even realize they have a limit set if they haven't encountered problems with other large applications. It looks like I'm at least the third person to encounter this, and a hint to look at ulimit instead of other things (like the overcommit_memory setting) would've saved me some time. Something like: struct rlimit address_limits; int required_address_space = 1024 * 1024 * 1400; /* 1400M */ getrlimit(RLIMIT_AS, &address_limits); if (address_limits.rlim_max < required_address_space) WINE_WARN("Your virtual memory limit is set to %dk, which will\nprobably prevent wine from loading correctly. If you get an error,\nincrease the limit with 'ulimit -v' to at least %dk.\n", address_limits.rlim_max / 1024, required_address_space / 1024); I don't know how to determine the exact amount of address space wine requires, since it seems to vary somewhat with the application -- 1300M is enough for notepad, our own winelib app requires at least 1375M. Would a warning like this be appropriate? Eric

1 0

Re: Added the feature to change row height in owner draw controls.
by Dimitrie Paun 19 May '05

19 May '05

> Added the feature to change row height in owner draw controls. The indentation looks a bit funky on this one -- can you please use 4-space indentation? -- Dimi.

2 2

Re: list: make LIST_FOR_EACH_ENTRY look more like a for loop
by Alexandre Julliard 19 May '05

19 May '05

Dimi Paun <dimi(a)lattica.com> writes: > I've always been a bit confused about the parameters to the > list macros. If you don't use them much (which I didn't) it's > hard to remember them. I think it would be best if we are > consistent with other for loops out there. I think they are perfectly consistent as they are. The common form of a for loop is something like 'for cursor in list', that's also what LIST_FOR_EACH does, so it makes sense to have LIST_FOR_EACH_ENTRY do the same. The extra 2 parameters are implementation details about the object structure, that are just fine at the end. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: list: make LIST_FOR_EACH_ENTRY look more like a for loop
by Robert Shearman 19 May '05

19 May '05

Dimi Paun wrote: >I've always been a bit confused about the parameters to the >list macros. If you don't use them much (which I didn't) it's >hard to remember them. I think it would be best if we are >consistent with other for loops out there. > >ChangeLog > Change the parameter order for LIST_FOR_EACH_ENTRY() > to more closely match the for loop. > > > > >------------------------------------------------------------------------ > >Index: ./include/wine/list.h >=================================================================== >RCS file: /var/cvs/wine/include/wine/list.h,v >retrieving revision 1.6 >diff -u -p -r1.6 list.h >--- ./include/wine/list.h 18 May 2005 13:24:46 -0000 1.6 >+++ ./include/wine/list.h 19 May 2005 12:19:33 -0000 >@@ -55,7 +55,7 @@ struct list > * And to iterate over it: > * > * struct gadget *gadget; >- * LIST_FOR_EACH_ENTRY( gadget, &global_gadgets, struct gadget, entry ) >+ * LIST_FOR_EACH_ENTRY( struct gadget, entry, &global_gadgets, gadget ) > * { > * ... > * } > > I don't think this makes any more sense with your patch than before. LIST_FOR_EACH_ENTRY is different to a for statement because LIST_FOR_EACH_ENTRY doesn't declare the start condition, end condition and iterator because these are defined by the macro itself. The parameters are really just defining what you are iterating on and what you are using. Rob

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel