- wine-devel - winehq.org

[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

Re: Corrected the priority of operators for LISTVIEW_GetNextItem function.
by taro-x＠justsystem.co.jp 19 May '05

19 May '05

2005-05-19 Kouji Sasaki <taro-x(a)justsystem.co.jp> > > Changelog: > > > > * dlls/comctl32/listview.c > > > > Corrected the priority of operators for LISTVIEW_GetNextItem function. > > > --- dlls/comctl32/listview.c 2005-04-14 22:58:24.000000000 +0900 > > +++ dlls/comctl32/listview.c 2005-05-16 11:29:08.003084512 +0900 > > @@ -5665,7 +5665,7 @@ > > * so it's worth optimizing */ > > if (uFlags & LVNI_FOCUSED) > > { > > - if (!(LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask) return -1; > > + if (!((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask)) return -1; > > Wouldn't it be more readable and less confusing in the below form? > > if ((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) != uMask) return -1; > > > -- > Dmitry. > I will send the modified patch, as changing the patch accordingly will make the source much easier to read. Changelog: * dlls/comctl32/listview.c Corrected the priority of operators for LISTVIEW_GetNextItem function. -- Justsystem Corporation <taro-x(a)justsystem.co.jp>

1 0

Re: Added the callback item processing for LISTVIEW_EndEditLabelT function.
by Dimitrie Paun 19 May '05

19 May '05

> Added the callback item processing for LISTVIEW_EndEditLabelT function. I think this would be a bit more explicit and correct (is_textW() returns false if pszText == NULL) if the test is the other way around: + if (lpItem && lpItem->hdr.pszText == LPSTR_TEXTCALLBACKW) + { + LISTVIEW_InvalidateItem(infoPtr, infoPtr->nEditLabelItem); + } + else + { + ZeroMemory(&dispInfo, sizeof(dispInfo)); + dispInfo.item.mask = LVIF_TEXT; + dispInfo.item.iItem = infoPtr->nEditLabelItem; + dispInfo.item.iSubItem = 0; + dispInfo.item.pszText = pszText; + dispInfo.item.cchTextMax = textlenT(pszText, isW); + return LISTVIEW_SetItemT(infoPtr, &dispInfo.item, isW); + } -- Dimi.

2 1

Re: Implement NtQuerySystemInformation(SystemTimeOfDayInformation)
by Rein Klazes 19 May '05

19 May '05

On Tue, 17 May 2005 23:06:51 +0200, you wrote: > + RtlSystemTimeToLocalTime(&sys_time, &local_time); > + /* liExpTimeZoneBias is not the same as tzi.Bias since it takes > + * disabled DST correction into account (tested on WinXP). */ > + local_diff.QuadPart = sys_time.QuadPart - local_time.QuadPart; You mean the "Automatically adjust clock for daylight saving"? Wine does not follow this silly flag and at a couple of places it depends on it. I doubt whether it should. > + > + sti->liKeBootTime = NTDLL_BootTime; > + sti->liKeSystemTime = sys_time; > + sti->liExpTimeZoneBias = local_diff; > + sti->uCurrentTimeZoneId = RtlQueryTimeZoneInformation(&tzi); This does not look correct. AFAIK RtlQueryTimeZoneInformation returns an NT-status code, 0 is no success, otherwise it is an error code. Have a look at GetTimeZoneInformation how to compute a TimeZoneId. Rein.

2 3

Re: [crypt32] take 3: CryptProtectData/CryptUnprotectData helper functions
by Mike McCormack 18 May '05

18 May '05

Kees Cook wrote: > Corrected for MESSAGE() use and a botch of wine_dbg_sprintf usage. Julliard won't commit dead code, so you have to make sure that each function that you send is used by something else. How about sending a patch implementing CryptProtectData()? Mike

1 0

Re: [crypt32] CryptProtectData/CryptUnprotectData helper functions
by Alexandre Julliard 18 May '05

18 May '05

Kees Cook <kees(a)outflux.net> writes: > +static int > +hexprint(const char *s, unsigned char *p, int n) > +{ > + char report[80]; > + int r=-1; > + snprintf(report,16,"%14s:", s); > + while (--n >= 0) > + { > + if (r++ % 20 == 19) > + { > + wine_dbg_printf("%s\n",report); > + snprintf(report,16,"%14s ", ""); > + } > + sprintf(report+strlen(report)," %02x", *p++); > + } > + wine_dbg_printf("%s\n",report); You should use wine_dbg_sprintf here and return a string. > +static > +void serialize_dword(DWORD value,BYTE ** ptr) > +{ > + /*TRACE("called\n");*/ > + > + *((DWORD*)*ptr)=value; > + *ptr+=sizeof(DWORD); This (and other similar things later on) isn't safe for CPUs that don't allow unaligned accesses, you have to use memcpy instead. > +static > +BOOL fill_protect_data(struct protect_data_t * pInfo, LPCWSTR szDataDescr, > + HCRYPTPROV hProv) > +{ > + DWORD dwStrLen; > + > + TRACE("called\n"); > + > + if (!pInfo) return FALSE; > + > + dwStrLen=lstrlenW(szDataDescr); > + > + memset(pInfo,0,sizeof(*pInfo)); > + > + pInfo->count0=0x0001; > + > + pInfo->info0.cbData=strlen(crypt_magic_str)+1; > + pInfo->info0.pbData=strdup(crypt_magic_str); You don't want to use strdup, you should use HeapAlloc and friends (especially since you use HeapFree later on). > +static void > +crypt_report_func_input(DATA_BLOB* pDataIn, > + DATA_BLOB* pOptionalEntropy, > + CRYPTPROTECT_PROMPTSTRUCT* pPromptStruct, > + DWORD dwFlags) > +{ > + wine_dbg_printf("\tpPromptStruct: 0x%x\n",(unsigned int)pPromptStruct); > + if (pPromptStruct) > + { > + wine_dbg_printf("\t\tcbSize: 0x%x\n",(unsigned int)pPromptStruct->cbSize); > + wine_dbg_printf("\t\tdwPromptFlags: 0x%x\n",(unsigned int)pPromptStruct->dwPromptFlags); > + wine_dbg_printf("\t\thwndApp: 0x%x\n",(unsigned int)pPromptStruct->hwndApp); > + wine_dbg_printf("\t\tszPrompt: 0x%x %s\n", > + (unsigned int)pPromptStruct->szPrompt, > + pPromptStruct->szPrompt ? debugstr_w(pPromptStruct->szPrompt) > + : ""); > + } > + wine_dbg_printf("\tdwFlags: 0x%04x\n",(unsigned int)dwFlags); > + wine_dbg_printf("\tpDataIn->cbData: %u\n",(unsigned int)pDataIn->cbData); > + wine_dbg_printf("\tpDataIn->pbData: 0x%x\n",(unsigned int)pDataIn->pbData); > + hexprint("pbData", pDataIn->pbData, pDataIn->cbData); > + if (pOptionalEntropy) > + { > + wine_dbg_printf("\tpOptionalEntropy->cbData: %u\n",(unsigned int)pOptionalEntropy->cbData); > + wine_dbg_printf("\tpOptionalEntropy->pbData: 0x%x\n",(unsigned int)pOptionalEntropy->pbData); > + hexprint("pbData", pOptionalEntropy->pbData, pOptionalEntropy->cbData); > + wine_dbg_printf("\t\t%s\n",debugstr_an(pOptionalEntropy->pbData,pOptionalEntropy->cbData)); > + } > + > +} > + > +static void > +announce_bad_opaque_data() > +{ > + wine_dbg_printf("CryptUnprotectData received the following pDataIn DATA_BLOB that seems to\n"); > + wine_dbg_printf("have NOT been generated by Wine:\n"); > +} You should use the TRACE/FIXME macros here, not raw wine_dbg_printf. -- Alexandre Julliard julliard(a)winehq.org

4 6

Re: [crypt32] CryptProtectData/CryptUnprotectData helper functions
by Kees Cook 18 May '05

18 May '05

On Wed, May 18, 2005 at 12:29:58PM -0700, Kees Cook wrote: > Take two. Ignore... this patch is broken, and I need to do an update of wine_dbg_printf() -> MESSAGE() -- Kees Cook @outflux.net

1 0

Re: [wine] Re: A better Beep
by Marcelo Duarte 18 May '05

18 May '05

David Lee Lambert escreveu: >On Tue, May 17, 2005 at 10:43:25AM -0300, Marcelo Duarte wrote: > > >>Whats happens if a program calls bepp with invalid values for dwFreq and >>dwDur on a linux console? >> >> > >The bell becomes inaudible until reset by another terminal-control >sequence. However, the special value (duration=-1) does not have the >same semantics; it's simply ignored. > >On my box that has a PC speaker, the bell is silent when any of the >following are true: > >freq < 21 >dur == 0 >dur > 1999 > >I can't hear any tones above 12000 Hz or so, but I'm not sure whether >that's my hearing, the speaker-hardware, or the kernel's decision. > >Should I add range-checks on frequency and duration? > > > >>(the programmer thinks that dwFreq and dwDur are ignored by Win95). >> >> > >That's what the API documentation says. Are they used on WinXP or Win2k? > > > If you have programs to test, send me.

1 0

MSN Webcam
by Joaquín Fernández 18 May '05

18 May '05

hmmmm... can you use a webcam in msn under wine???? If yes, can you explain to me how to do it? I was not able to run msn messenger in wine. Regards Joaquín -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.4 (GNU/Linux) mQFCBEFI/gARAwDd2+ojasT3rCyRktSw+Ix3m+yoxSD0NkpMLlunmJxwvn6wKZVl mDw76/Zu9mqDWWeSGdSl+60T7fDLrJZSEB45O9T5jdujj01GFeer7xuiuHBTFw8o CXqD/hzhqYc46ecAoIQQjZ2qZtOWLPRBbegK/nyOIguNAv9QGiKPLBS8o0ksxEUp EfLAExVmu6Zp693uKGf6XrBWNcLriuwRPr1mjy3N/bhMlqc3vcTeUBwxiUuX5h2P NQgB3d2AbJS6oEvhmZL0Bn/8Ij/MSvVrartmCXuw9eSx0aMC/R7Kw9TtUfxFVUGx fQKwoA9BXNElPLcNohbBS/fH87IMMxCJyn+rmTeNCEcUEQ7UgvVCdlzZ8+L4PdlH qGR81nhZVEwPRnSSesLpSHRC1QQVoceBeb7PICr/b2eZiKMX+bQ+Sm9hcXXDrW4g TWFudWVsIEZlcm7DoW5kZXogUXVpbGVzIDxqb2FxdWluQGNhc2FkZWFsYWJhbnph Lm9yZz6IXgQTEQIAHgUCQUj+AAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRBH 677/q7xL4e15AJwNfSpeaXXMH2EjuKblfeBe51MrUgCcCP5jEnpXrDXLWULIW5yD t6VdHlU= =a8BM -----END PGP PUBLIC KEY BLOCK-----

2 1

Re: list.h: document the more convenient iteration method
by Dimi Paun 18 May '05

18 May '05

On Wed, 2005-05-18 at 08:01 -0400, Dimi Paun wrote: > * struct list *cursor; > - * LIST_FOR_EACH( cursor, &global_gadgets ) > + * LIST_FOR_EACH_ENTRY( cursor, &global_gadgets, struct gadget *, > gadget ) > * { Looking at this, why do we need cursor at all for the LIST_FOR_EACH_ENTRY? Also the type and iteration var should come first, to be simiar for loops in pretty much any language out there. I think it should just be: LIST_FOR_EACH_ENTRY( struct gadget *, gadget, &global_gadgets ) Ah, I see now the problem. We would need to end it with LIST_END instead of just doing {...}. Not such a big deal, we do the same for server requests too :) But I can see why we would like to keep cursor. If so, it should come at the end: LIST_FOR_EACH_ENTRY(struct gadget *,gadget,&global_gadgets,cursor) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Small cleanup in list handling
by Robert Shearman 18 May '05

18 May '05

Dimi Paun wrote: >Index: dlls/ntdll/exception.c >=================================================================== >RCS file: /var/cvs/wine/dlls/ntdll/exception.c,v >retrieving revision 1.75 >diff -u -p -r1.75 exception.c >--- dlls/ntdll/exception.c 13 May 2005 13:56:47 -0000 1.75 >+++ dlls/ntdll/exception.c 13 May 2005 19:01:31 -0000 >@@ -480,7 +480,8 @@ ULONG WINAPI RtlRemoveVectoredExceptionH > RtlEnterCriticalSection( &vectored_handlers_section ); > LIST_FOR_EACH( ptr, &vectored_handlers ) > { >- if (ptr == &((VECTORED_HANDLER *)handler)->entry) >+ VECTORED_HANDLER *curr_handler = LIST_ENTRY( ptr, VECTORED_HANDLER, entry ); >+ if (curr_handler == handler) > { > list_remove( ptr ); > ret = TRUE; > > This patch has already been committed, but for future reference code of this form: LIST_FOR_EACH( cursor, list) { TYPE list_entry = LIST_ENTRY( cursor, TYPE, entry ); ... Can be replaced by the following for IMHO, slightly more readable code: LIST_FOR_EACH_ENTRY( list_entry, list, TYPE, entry) { ... Rob

2 1

Re: MSN Webcam
by Maarten Lankhorst 18 May '05

18 May '05

MediaHost (TM) wrote: > Looks interesting! Any idea, when your patches get committed into the > "official" releases? > >> Maarten Lankhorst wrote: >> >>> Status: Nearly complete, need testers. >>> >>> http://wiki.winehq.org/MSN_Messenger_webcam_support >>> >>> You need the native quartz dll, which get installed with internet >>> explorer, as the builtin quartz doesn't work properly when changing >>> media format on initialisation. >> >> Possibly a problem with the code I wrote. Can you provide more >> details on this? >> >>> IFilterGraph Reconnect isn't implemented, and for some reason *looks >>> strangely at Robert* instead of a FIXME() there's a TRACE telling it >>> is a stub... >> >> I didn't write any of the IFilterGraph implementation, but you are >> right that it is crazy. >> >> Rob >> Writing some final bugfixes at the moment, so I think a matter of days before it'll be done in a state that julliard might commit.. There were 2 small reasons why builtin quartz wasn't working 1. if format changed, it would need to reconnect with new size (Quartz, submitted a patch) 2. if format wasn't changed, I used my own optimized code, that wrote 960 bytes to a wrong place, so it crashed. (Totally my fault) btw, nice name and signature...

1 0

Re: [WINEDOCS] Add missing tag
by Dimi Paun 18 May '05

18 May '05

On Wed, 2005-05-18 at 10:37 +0200, Francois Gouget wrote: > Add missing <qandaentry> tag. Oops, too late, I've already committed the fix last night. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: comctl32: Move mouse tracking to MouseMove [RESEND]
by Dimi Paun 18 May '05

18 May '05

On Wed, 2005-05-18 at 00:31 -0500, James Hawkins wrote: > + LVHITTESTINFO lvHitTestInfo; > + INT nItem; > + > + if (infoPtr->bLButtonDown) > + { > + lvHitTestInfo.pt = infoPtr->ptClickPos; > + nItem = LISTVIEW_HitTest(infoPtr, &lvHitTestInfo, TRUE, > TRUE); > + > + if (DragDetect(infoPtr->hwndSelf, infoPtr->ptClickPos)) > + { > + NMLISTVIEW nmlv; > + > + ZeroMemory(&nmlv, sizeof(nmlv)); Why not move the lvHitTestInfo and nItem into the inner scope: if (infoPtr->bLButtonDown && DragDetect(infoPtr->hwndSelf, infoPtr->ptClickPos)) { LVHITTESTINFO lvHitTestInfo; NMLISTVIEW nmlv; ZeroMemory(&nmlv, sizeof(nmlv)); lvHitTestInfo.pt = infoPtr->ptClickPos; nmlv.iItem = LISTVIEW_HitTest(infoPtr, &lvHitTestInfo, TRUE, TRUE); .... } -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

MSN Webcam
by Maarten Lankhorst 18 May '05

18 May '05

Status: Nearly complete, need testers. http://wiki.winehq.org/MSN_Messenger_webcam_support You need the native quartz dll, which get installed with internet explorer, as the builtin quartz doesn't work properly when changing media format on initialisation. IFilterGraph Reconnect isn't implemented, and for some reason *looks strangely at Robert* instead of a FIXME() there's a TRACE telling it is a stub...

2 1

Re: [crypt32] implementation of CryptProtectData/CryptUnprotectData
by Mike McCormack 18 May '05

18 May '05

Kees Cook wrote: > Hi, I'm back again. :) This implements the crypt32 functions > CryptProtectData and CryptUnprotectData, using a best-guess at the true > Windows opaque data format and encryption methods. It attempts to > follow the "details" in the MSDN article that described > CryptProtectData. > > Please let me know how this all looks. Hopefully I've got it mostly > right this time. If there is a more sane way to handle the structure > serialization/unserialization, I'm all ears. > > (Anyone paying really close attention will note that I uncovered some > crash bugs in rsaenh as a result of my crypt32 test cases. Make sure > you've done a "cvs update" to catch those changes before running them.) > > ChangeLog: > Implements a best-guess of CryptProtectData/CryptUnprotectData. Hi Kees, Wow. That's alot of work :) It's usually easier to review these things in smaller chunks. An easy way to do that is to submit header changes first, then stub functions, implementation of each function and a test program, all as seperate patches. A further way for your patch would be to seperate CryptProtectData and CryptUnprotectData data into to two seperate patches, though I understand they are dependent on each other to some extent. This patch looks OK to me at a quick glance, but if it's not applied, please consider breaking it up. At least that way, you'll have less to submit next time round. Mike

3 2

Re: winecfg: Add handling for drive options
by Mike McCormack 18 May '05

18 May '05

James Hawkins wrote: > case WM_COMMAND: > - if (HIWORD(wParam) == EN_CHANGE) > + switch (HIWORD(wParam)) > { I don't know if it's just my opinion, but case statements within case statements make the code more difficult to read. Would you consider creating a new function instead? eg. case WM_COMMAND: OnCommand( dialog, HIWORD(wParam), LOWORD(wParam) ); break; Mike

1 0

Re: comctl32: Move mouse tracking to MouseMove
by Dimi Paun 18 May '05

18 May '05

On Tue, 2005-05-17 at 23:18 -0500, James Hawkins wrote: > Changelog > * Store the click point in LISTVIEW_INFO. > * Move mouse tracking to MouseMove. > * Use DragDetect instead of TrackMouse. > * Remove the unused TrackMouse function. I think you've sent the wrong patch... -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: Corrected the priority of operators for LISTVIEW_GetNextItem function.
by Dmitry Timoshkov 18 May '05

18 May '05

<taro-x(a)justsystem.co.jp> wrote: > Changelog: > > * dlls/comctl32/listview.c > > Corrected the priority of operators for LISTVIEW_GetNextItem function. > --- dlls/comctl32/listview.c 2005-04-14 22:58:24.000000000 +0900 > +++ dlls/comctl32/listview.c 2005-05-16 11:29:08.003084512 +0900 > @@ -5665,7 +5665,7 @@ > * so it's worth optimizing */ > if (uFlags & LVNI_FOCUSED) > { > - if (!(LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask) return -1; > + if (!((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) == uMask)) return -1; Wouldn't it be more readable and less confusing in the below form? if ((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) != uMask) return -1; -- Dmitry.

1 0

Re: storage32.c fix for big endian arch
by Phil Krylov 17 May '05

17 May '05

Please disregard, Pierre d'Herbemont already sent the same few hours before :) -- Ph. On Tue, 17 May 2005 21:41:41 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > ChangeLog: > > Fixed storage32.c compilation in big endian architectures. > > Patch: > > Index: dlls/ole32/storage32.c > =================================================================== > RCS file: /home/wine/wine/dlls/ole32/storage32.c,v > retrieving revision 1.87 > diff -p -u -r1.87 storage32.c > --- dlls/ole32/storage32.c 14 May 2005 11:06:44 -0000 1.87 > +++ dlls/ole32/storage32.c 17 May 2005 17:20:06 -0000 > @@ -4130,8 +4130,8 @@ void StorageUtl_ReadULargeInteger(const > ULARGE_INTEGER tmp; > > memcpy(&tmp, buffer + offset, sizeof(ULARGE_INTEGER)); > - value->LowPart = htole32(tmp.HighPart); > - value->HighPart = htole32(tmp.LowPart); > + value->u.LowPart = htole32(tmp.u.HighPart); > + value->u.HighPart = htole32(tmp.u.LowPart); > #else > memcpy(value, buffer + offset, sizeof(ULARGE_INTEGER)); > #endif > @@ -4143,8 +4143,8 @@ void StorageUtl_WriteULargeInteger(BYTE* > #ifdef WORDS_BIGENDIAN > ULARGE_INTEGER tmp; > > - tmp.LowPart = htole32(value->HighPart); > - tmp.HighPart = htole32(value->LowPart); > + tmp.u.LowPart = htole32(value->u.HighPart); > + tmp.u.HighPart = htole32(value->u.LowPart); > memcpy(buffer + offset, &tmp, sizeof(ULARGE_INTEGER)); > #else > memcpy(buffer + offset, value, sizeof(ULARGE_INTEGER)); > >

1 0

[Fwd: Relationship between Wine and the proprietary versions.]
by Dimi Paun 17 May '05

17 May '05

Hi folks, I've got this request on wine-faq list (deleted the name, don't know if they want to be on wine-devel). Anyone care to write a small blurb about this? -------- Forwarded Message -------- From: XXXXX To: wine-faq(a)winehq.org Subject: Relationship between Wine and the proprietary versions. Date: Mon, 16 May 2005 21:45:11 +0200 Hi Seing Wine, Crossoveroffice and Cedega, i was wondering about the relationship between the projects. I find the concepts they are pursueing important, but i don't like their licenses. I would like Wine to be all that, so i would rather give my support to Wine than to the proprietairy projects. That is not a question of money, but out of licensing issues. So i was wondering if you could explain that in the FAQ also? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

3 4

Wiki
by Robert van Herk 17 May '05

17 May '05

Just wanted to say, that the wiki is great! It makes it much easier to pick a project to work on. Robert

1 0

Re: A better Beep
by Marcelo Duarte 17 May '05

17 May '05

Whats happens if a program calls bepp with invalid values for dwFreq and dwDur on a linux console? (the programmer thinks that dwFreq and dwDur are ignored by Win95). David Lee Lambert escreveu: >Changelog: > Support beeping with the PC speaker when running from the Linux console > > > >------------------------------------------------------------------------ > >--- dlls/kernel/console.c.v1_39 Fri May 13 15:38:16 2005 >+++ dlls/kernel/console.c Fri May 13 21:02:19 2005 >@@ -193,9 +193,19 @@ > */ > BOOL WINAPI Beep( DWORD dwFreq, DWORD dwDur ) > { >- static const char beep = '\a'; >- /* dwFreq and dwDur are ignored by Win95 */ >- if (isatty(2)) write( 2, &beep, 1 ); >+ if (strcmp(getenv("TERM"),"linux")==0 && isatty(2)) { >+ /* the Linux console supports setting frequency and duration */ >+ char szBeep[50]; >+ snprintf(szBeep,50,"\x1B[10;%d]\x1B[11;%d]\a",(int)dwFreq,(int)dwDur); >+ write( 2, szBeep, strlen(szBeep) ); >+ usleep(dwDur*1000); >+ } else if (isatty(2)) { >+ /* dwFreq and dwDur are ignored by Win95 */ >+ static const char beep = '\a'; >+ write( 2, &beep, 1 ); >+ } else { >+ /* TODO: we could play a .wav file instead... */ >+ } > return TRUE; > } > > >

1 0

exeCryptor
by Kenneth Porter 17 May '05

17 May '05

<http://www.strongbit.com/execryptor.asp> Anyone have experience with this on WINE? Another developer pointed this out to me for use with a Windows binary, and is not releasing Linux betas because there's no native Linux equivalent. (The app works fine native in Linux, but the dev want's to prevent unauthorized use until GA.)

3 4

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink 17 May '05

17 May '05

The user interface is what the user has to do to use the program. This is not supported in Wine. You will find links from winehq to several lists of things that run under Wine. When you attempt to use these lists you will find that many if not most of the programs do not run as is. The user outside the Wine world sees a totally false picture of Wine. He loads Wine and finds there are NO current instructions on how to use it so he presumes Wine to be worthless and goes away. Even if he persists there is still the problem of figuring out exactly how to make many if not most of the programs in the will run database work. The public simply won't put up with this. You can't have Wine so that a user must be a priest to load a special dll or to find out what special dll is necessary. Currently, there needs to be a short document written and KEPT up to date. To install and use Wine do ....... This document needs to point to somewhere where the user can get more help. There needs to be a WIKI where postings can be made specifically concerning what is necessary to make a program work on Wine. How do you currently make Office or Acrobat work on Wine? To my knowledge there are currently no large or complicated programs that you just load and run under Wine. You must set them all up first. It doesn't make any difference to the user if a program fails because of a sound driver. Waiting for all this to be fixed perfectly means a wait forever and serves no purpose without at least simple instructions on how to use Wine now.

4 4

DirectX and Games
by Ivan Gyurdiev 16 May '05

16 May '05

Out of curiosity, why hasn't Oliver's swapchains and stateblocks patch been merged? I saw that in wine-patches about 10 days ago, but it hasn't been merged, and there's no comments at all. ===== On an unrelated note, what is causing this bug: http://bugs.winehq.org/show_bug.cgi?id=2082 As I understand, this is a regression, since Diablo used to work a long time ago, and then some patch broke it. The bug was opened sometime in March... -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

3 3

Re: edit: no not use LOCAL_*() functions
by Alexandre Julliard 16 May '05

16 May '05

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > @@ -426,19 +425,21 @@ static LRESULT WINAPI EditWndProc_common > { > EDITSTATE *es = (EDITSTATE *)GetWindowLongW( hwnd, 0 ); > LRESULT result = 0; > + STACK16FRAME *stack16; > + HANDLE16 oldDS; > > TRACE("hwnd=%p msg=%x (%s) wparam=%x lparam=%lx\n", hwnd, msg, SPY_GetMsgName(msg, hwnd), wParam, lParam); > > if (!es && msg != WM_NCCREATE) > return DefWindowProcT(hwnd, msg, wParam, lParam, unicode); > - else if (msg == WM_NCCREATE) > - return EDIT_WM_NCCreate(hwnd, (LPCREATESTRUCTW)lParam, unicode); > - else if (msg == WM_DESTROY) > - return EDIT_WM_Destroy(es); > > + if (es && (msg != WM_DESTROY)) EDIT_LockBuffer(es); > + > + /* Make sure DS points to hInstance for 16-bit apps */ > + stack16 = (STACK16FRAME*)MapSL((SEGPTR)NtCurrentTeb()->WOW32Reserved); > + oldDS = stack16->ds; > + stack16->ds = GetWindowLongPtrW( hwnd, GWLP_HINSTANCE ); It seems dangerous to set DS for the whole window procedure, it will be calling a lot of other functions that may end up depending on DS. It's especially dangerous here since the window instance won't be a valid DS for 32-bit windows. I think you really want to set it only around the Local* calls and restore it as soon as possible. -- Alexandre Julliard julliard(a)winehq.org

2 1

Unknown stab type in crashes
by James Hawkins 16 May '05

16 May '05

Hey, Whenever wine crashes, I get a long stream of err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e Does everyone else get that too? Does anyone have info on this? It's understandable to output an unknown type, but it does make the backtrace pretty much useless. After a couple parts of the bt, the error message files a couple hundred lines, then another couple lines of the bt, so I can't see the whole bt at once. Sometimes parts of the bt are scrolled up past my history limit. I don't mean to complain, but it is hampering debugging a bit. -- James Hawkins

4 6

Re: comctl32: Move TrackMouse handling to MouseMove
by Alexandre Julliard 16 May '05

16 May '05

James Hawkins <truiken(a)gmail.com> writes: > This patch also fixes the WM_LBUTTONUP bug, and the new behavior with > listview is even better. The logic behind this is that we only want > to track the mouse by calling TrackMouse when the mouse moves. What you really want is to only start tracking if it moves by more than a certain amount, which is what LISTVIEW_TrackMouse already tries to do in a very inefficient way. So you should probably move all the logic from LISTVIEW_TrackMouse to the MouseMove handler. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: test-and-dereference: a common problem?
by Alexandre Julliard 16 May '05

16 May '05

Paul Millar <paul(a)astro.gla.ac.uk> writes: > Anyway, I noticed that the dlls/advapi32/crypt.c tests were bombing out > for me. This turned out to be due to dlls/advapi32/crypt.c:1649 > > > if (!key || !pbData || !key->pProvider || key->pProvider->dwMagic != MAGIC_CRYPTPROV) > > CRYPT_ReturnLastError(ERROR_INVALID_PARAMETER); > > [...] > So, this makes sense. Its that old chestnut of compiler being free to > evaluate if clauses in any order it chooses (for optimisation). The && and || operators in C are short-circuit operators, meaning they are always evaluated left to right, and further tests are not executed if the first ones fail. I'm afraid you wasted your time with that patch, there's nothing to fix here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Make winelib resource data writeable
by Dmitry Timoshkov 16 May '05

16 May '05

"Felix Nawothnig" <felix.nawothnig(a)t-online.de> wrote: > For PE files there is a hack in kernel/except.c which does COW for > resource data - but winelib apps crash when they try to write to it. > (If this is a design-decision please tell me) As it's clearly indicated in the error message in kernel/except.c only broken apps try to write to the resources. What your application is trying to do? -- Dmitry.

3 2

Re: PATCH: hglobalstream static
by Dmitry Timoshkov 16 May '05

16 May '05

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > /*** > + * This implements the IUnknown method AddRef for this > + * class > + */ > +static ULONG WINAPI HGLOBALStreamImpl_AddRef( > + IStream* iface) > +{ > + HGLOBALStreamImpl* const This=(HGLOBALStreamImpl*)iface; > + return InterlockedIncrement(&This->ref); > +} I understand that this is an existing code, but calling InterlockedIncrement for a 'const' pointer looks very suspicious. Same for HGLOBALStreamImpl_Release, HGLOBALStreamImpl_Read and other interfaces which actually change the pointed data. -- Dmitry.

2 1

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards 16 May '05

16 May '05

Hi Michael, --- Michael Lin <mlin(a)corvu.com.au> wrote: > If your target platform is windows, don't define the WINE_UNIX_PATHS > flag when you compile and it will all behave > the same as before. It's only when you define WINE_UNIX_PATHS flag that > GetOpenFileNameW() will be mapped > to UnixFSGetOpenFileNameW() for example. Else it will call the same > function as before and shouldn't break on Windows. > WINE_UNIX_PATHS is currently not defined anywhere in WINE, so no one > should see any difference. To see the change, > you have to define that flag in your winelib application's makefile. But your defining UnixFSGetOpenFileNameW in the spec file so the import library will still have that function listed so if I link a dll to that import library its going to fail on Windows even if I am not calling that function. The Windows Linker/Loader is not forgiving like the Unix loader if the symbol is not found in the import table. It seems like Winebuild will need some magic as well if you don't want these function exported all the time. Thanks Steven Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html

4 3

Game sound problem with wine 20050310 (Debian testing)
by J. Grant 15 May '05

15 May '05

Hello, I have been trying to get audio working in sync with the game I am playing (Activision Call of Duty) I get this error: err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: "HardwareAcceleration" = "Emulation" in the [dsound] section of your config If I use the suggestion i get 1sec lag on in-game sounds. Someone #winehq gave me some tips. I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please? [dsound] ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE "Drivers" = "winealsa.drv" ; for ALSA users ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. "HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Forces emulation mode (using wave api) "HardwareAcceleration" = "Emulation" ;; Sets default playback device (0 - number of devices - 1) ;"DefaultPlayback" = "0" ; use first device (/dev/dsp) ;"DefaultPlayback" = "1" ; use second device (/dev/dsp1) ;"DefaultPlayback" = "2" ; use third device (/dev/dsp2) ;; Sets default capture device (0 - number of devices - 1) ;"DefaultCapture" = "0" ; use first device (/dev/dsp) ;"DefaultCapture" = "1" ; use second device (/dev/dsp1) ;"DefaultCapture" = "2" ; use third device (/dev/dsp2) Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh "Emulation" bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise) I wonder if this is a known problem (bug)? Is there a work around? Or a fix please? I am not on this list, so please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

4 8

Re: dlls/msvcrt/time.c build breakage
by Juan Lang 15 May '05

15 May '05

Oops, I mistakenly assumed daylight and timezone were available in FreeBSD too. I'll take a look this week when I get a crack at my FreeBSD box. --Juan --- Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> wrote: > The following change to dlls/msvcrt/time.c > > revision 1.22 > date: 2005/05/14 11:07:10; author: julliard; state: Exp; lines: +31 > -4 > Juan Lang <juan_lang(a)yahoo.com> > - move _timezone to time.c, and correct its type > - implement _tzset, and initialize _daylight, _timezone, and _tzname > from libc values > > breaks the build on FreeBSD 4.10: > > time.c: In function `MSVCRT__tzset': > time.c:351: error: `daylight' undeclared (first use in this function) > time.c:351: error: (Each undeclared identifier is reported only once > time.c:351: error: for each function it appears in.) > time.c:352: warning: assignment makes integer from pointer without a > cast > > Would you mind fixing this? > > Gerald > Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

1 0

dlls/msvcrt/time.c build breakage
by Gerald Pfeifer 15 May '05

15 May '05

The following change to dlls/msvcrt/time.c revision 1.22 date: 2005/05/14 11:07:10; author: julliard; state: Exp; lines: +31 -4 Juan Lang <juan_lang(a)yahoo.com> - move _timezone to time.c, and correct its type - implement _tzset, and initialize _daylight, _timezone, and _tzname from libc values breaks the build on FreeBSD 4.10: time.c: In function `MSVCRT__tzset': time.c:351: error: `daylight' undeclared (first use in this function) time.c:351: error: (Each undeclared identifier is reported only once time.c:351: error: for each function it appears in.) time.c:352: warning: assignment makes integer from pointer without a cast Would you mind fixing this? Gerald

1 0

Debugging remotely from Visual studio
by David Hemmo 15 May '05

15 May '05

Hello, After reading a mail exchanges about ptrace on Linux, I decided to switch to a newer Linux kernel to see how it modified my problem. Things got worse. Restarting a program from Visual studio stopped working. Is there anyone that can explain me how things are supposed to work ? I think I know the basics. To start, the debugger set the bit 0x100 in EFlags ot the current context, then wine test this bit to check what parameter to send to ptrace to restart the process. It gets blurry after that ... What happens after the traced instruction executes ? At least three parts are involved: - Linux that handle the first part of the exception - Wineserver - msvcmon. It is the visual C++ remote debugging program, but I think it could be any debugger. There may be a 4th player with the exception handling part of the debugged application but I am not sure. Thanks David

2 5

Re: comctl32: Move TrackMouse handling to MouseMove
by Dimi Paun 15 May '05

15 May '05

On Sat, 2005-05-14 at 11:12 -0500, James Hawkins wrote: > + LVHITTESTINFO lvHitTestInfo; > + INT nItem; > + > + if (infoPtr->bLButtonDown) { > + lvHitTestInfo.pt = infoPtr->ptClickPos; > + nItem = LISTVIEW_HitTest(infoPtr, &lvHitTestInfo, TRUE, TRUE); > + > + if (LISTVIEW_TrackMouse(infoPtr, infoPtr->ptClickPos)) { > + NMLISTVIEW nmlv; > + > + ZeroMemory(&nmlv, sizeof(nmlv)); > + nmlv.iItem = nItem; > + nmlv.ptAction.x = infoPtr->ptClickPos.x; > + nmlv.ptAction.y = infoPtr->ptClickPos.y; > + > + notify_listview(infoPtr, LVN_BEGINDRAG, &nmlv); > + > + return 0; > + } Please use 4-space indentation for new code. Currently listview is a mixture of 2/4 space indentation, but we should be moving towards 4 spaces if it's not a problem. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Re: Video Capturing under Wine
by Maarten Lankhorst 14 May '05

14 May '05

> Basically applications have two obvious ways to use video capture > services in Windows. One is avicap32.dll which is basically the Video > for Windows way of doing this and the other one is > ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it > seems. > Avicap32 implements two functions, one is for the enumeration of the VfW > devices registered in the system. For this it does enumerate all entries in > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvideo > and for compatibilty reasons with 16bit Windows also in the Drivers32 > section in system.ini. I have an untested version of this code already. > The enumeration function does not try to detect any devices other than > what it finds in above mentioned places. I assume that a webcam driver > installation would have to do that. > The second function in Avicap32.dll creates a (hidden) window which > handles the actual interaction with the video device as well as being an > optional user interface for the video data. The communication with the > video device is always by so called installable drivers, like wineoss, > etc. is used for audio devices. The interface to these installable video > drivers is for the video device specific parts declared in a header file > msviddrv.h which is really part of the DDK. (How would we add that to > the Wine headers?) > In modern Windows systems there is one MS provided installable driver > vfwwdm32.dll, which is basically a translation layer between the > installable interface and modern WDM stream based video drivers. We are not windows, using HKLM/SYSTEM/.../msvideo would not be an option imho, because when should we write it? And what if you just connected your webcam and modprobe'd the drivers for it, it would make things too difficult. I think the best way is to use winmm like dsound/etc uses, and add a configure option in ~/.wine/config so you can select what video driver you want to use. Since I don't exactly know how winmm works, some insight in how (for example) the sound drivers in winmm are called/used would be more then welcome, since, unlike the rest of the stuff I worked upon until now was well documented, but I doubt winmm is... Maarten Lankhorst

2 2

Video capturing under Wine, some overview
by Rolf Kalbermatter 14 May '05

14 May '05

Prompted by the recent work by Maarten Lankhorst on getting his video cam to work in Wine, I did some in depth investigations on how Windows actually does this stuff. This is a summary of what I found and some thoughts about it. I would like some comments on how to progress. Basically applications have two obvious ways to use video capture services in Windows. One is avicap32.dll which is basically the Video for Windows way of doing this and the other one is ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it seems. Avicap32 implements two functions, one is for the enumeration of the VfW devices registered in the system. For this it does enumerate all entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvid eo and for compatibilty reasons with 16bit Windows also in the Drivers32 section in system.ini. I have an untested version of this code already. The enumeration function does not try to detect any devices other than what it finds in above mentioned places. I assume that a webcam driver installation would have to do that. The second function in Avicap32.dll creates a (hidden) window which handles the actual interaction with the video device as well as being an optional user interface for the video data. The communication with the video device is always by so called installable drivers, like wineoss, etc. is used for audio devices. The interface to these installable video drivers is for the video device specific parts declared in a header file msviddrv.h which is really part of the DDK. (How would we add that to the Wine headers?) In modern Windows systems there is one MS provided installable driver vfwwdm32.dll, which is basically a translation layer between the installable interface and modern WDM stream based video drivers. Devenum uses the avicap enumeration function to find all registered VfW video sources and provide them to an application. Presumably there are other possible video source objects which would provide a direct interface to WDM stream class devices somehow and could be enumerated by devenum as well. DirectShow seems to be somwhat complicated. Video sources can be provided from VfW again, which is provided by the "VfW Capture Filter" class in qcap.dll. This is basically a DirectShow filter wrapper around the same installable driver interface as is used in avicap32.dll (and through above mentioned vfwwdm32.dll driver an application can also access WDM stream class video capture sources indirectly. How the direct interface to WDM stream class devices is provide I haven't found out yet but according to MSDN it should be possible somehow. For Wine purposes the VfW path seems the most interesting one. Separating the Video4Linux interface into an installable multimedia driver such as winev4l would cleanly separate platform specific code from the rest of the Wine DirectShow and Avicap implementation. Trying to emulate direct access to WDM based drivers would not be possible anyhow, as that would seem to require kernel driver support, which is mostly absent in Wine. I could probably hack an experimental winev4l driver together based on the work already done by Maarten Lankhorst, but would first want to make sure that this is considered the way to go, before investing more time into this. While the current implementation by Maarten is not as clean and nice because of the direct V4L dependency in standard Wine DLLs, it is something which already works somehow and could be integrated into Wine in quite a short time. What are the thoughts about this? Rolf Kalbermatter

5 4

sonicstage
by wino＠piments.com 14 May '05

14 May '05

Hi , I have just bought a NH900 and wanted to try to get it to communicate with linux, I did a quick search before buying and found a ref to someone who reckoned to have got this working. I believe sonicstage2 under wine. Seem to have lost the link and google is not helping today. Anyone got any info on this ? TIA

1 0

Re: [WINEDOCS] Add French translation for Wine's FAQ
by Dimi Paun 14 May '05

14 May '05

On Thu, 2005-05-12 at 16:49 +0200, Francois Gouget wrote: > This patch adds the framework for translating Wine's documentation and > adds a translation of the FAQ to French as a demonstration. No compressed patches, please. Also, the patch is big, and some things are cleaner than others. Let's break it down a bit. > Here is what the framework does: > > * first it moves most of en/Makefile.in to Make.rules.in so that this > code can be shared across the various translations. Well, the reason I didn't do that is for cases like incomplete translations. We can move to Make.rules.in: -- DB2* defines -- the targets (docs, pdf, etc) -- the tar rules The rest we can keep local, see how things evolve. We can always refactor it up. > * the actual translation is stored in a po file, one per documentation > document. So for French we currently have fr/wine-faq.po and later we > will also have wineusr-guide.po and winelib-guide.po. I'm not too hot about it to be honest. SGML is hard on the eye, this .po stuff seems to be even worse. But maybe it's easier to work with due to the various tools. If it makes it easier for you to maintain the translation, I'm cool with it. However, I'm not sure this will be the preferred way for all translators out there, so we shouldn't force it on everybody. > * Using po files lets us track exactly which translation paragraphs > are up to date and which are not. It also lets us leverage the tools > that have been developed around that format such as KBabel and maybe > even make it possible for contributors to translate the documentation > online using tools like Pootle (http://pootle.wordforge.org/), Kartouche > (http://i18n.kde.org/tools/kartouche/) or Rosetta > (https://launchpad.ubuntu.com/rosetta). This is great, but I doubt such tools can tell you *what* changed when something did change (the *what* here is "how did paragraph change") > * The link between the SGML files and the PO files and back is handled > by PO4A (http://po4a.alioth.debian.org/). I'm a bit worried about this one. It's new, debian specific, etc. There's no .rpm for it, and that makes me nervous. Tools like this must be easily available. Even if we go for it, maybe we'll have to keep the generated .sgml in CVS (just like configure). > * So configure.ac checks for the po4a tools. If they are missing then > the translated documentation cannot be built. I also added a > Makepo.rules.in that should be used by Makefiles building translated > documentation. What it does is just include the main Make.rules.in file > and add a couple of rules for generating SGML using PO files, and > extending the 'clean' target. This last bit cannot be put in the > top-level Make.rules.in because it does '$(RM) $(ALLBOOKS:%=%.sgml)' > which would be unfortunate in the en directory. The $(RM)... can remain local, and the rules can go in Make.rules.in. It would be confusing to have too many rule files. > sed -e 's/^<$article .*$ lang="en">$/<\1 lang="fr">/' -e > 's/^<$book .*$ lang="en">$/<\1 lang="fr">/' wine-faq.posgml > >wine-faq.sgml || (rm -f wine-faq.sgml && false) Nasty. BTW, the 'lang="en"' part of the patch can go in separately too. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

3 5

winefile
by Martin Fuchs 14 May '05

14 May '05

Hi, I want to merge some Robert Dickenson's version of winfile (derived from the old winefile code in 2002) in the next time into winefile. At the same time I want to keep the code it in sync between the ReactOS code base and Wine. What do you think about splitting the source file into several smaller modules? winefile.c is quite large with its 4223 lines. Martin

3 4

Winelib's role in converting Windows applications
by Ira Krakow 14 May '05

14 May '05

As many of you know, Brian and I are writing a book on Wine and Winelib for Prentice Hall. Brian's doing the Wine part; I'm doing the Winelib part. At Wineconf, I had a number of conversations about Winelib's role in converting Windows apps. The consensus seems to be that the most efficient conversion path is for much of the Windows app to stay in Visual C++ (or whatever) and that only the modules that specifically require native Linux calls should be recompiled, via MinGW/Dev-C++ on the Windows side, and Winemaker on the Linux side, into Winelib objects. For example, if the application requires PAM authentication, or a Linux-based help system, these modules would be separated out and encapsulated as Winelib objects. I was thinking of using PAM authentication as a good example, since it works for any authentication scheme that the application requires. This is the approach I plan to take. I welcome all feedback. Thanks. Ira

6 5

Re: Assertion fails in riched20; relay debug segfaults
by Adrian Harvey 14 May '05

14 May '05

> On Wed, 11 May 2005 23:01:17 +1200, Adrian Harvey wrote: > > Well, I got some output at least! Never used strace before, but it > > looks kinda like a +relay trace for the kernel :-) > > Yep, that's exactly what it is :) > > > I also happened to be tailing the syslog (I was looking at something > > completely different) and I noticed that the following was written: > > > > May 11 22:50:55 orac kernel: strace[7749] trap stack segment rip:410c86 rsp:800000007b20 error:0 > > May 11 22:50:55 orac kernel: wine-preloader[7750]: segfault at 000000005575b624 rip 000000005575b624 rsp 00000000ffffc824 error 15 > > > > I doubt it's much use, but I thought any information might help here.... > > Somehow you managed to compile Wine as 64-bits, which isn't going to work. > I think you need to remove your current Wine installation and > install/compile it as 32 bits. > > thanks -mike OK, I've removed that install of wine form my system, updated to the latest CVS, re-run configure, make depend, make and make install, and still I get the same problem. I piped all the make output to a file, and the all the gcc commands have the -m32 flag after them (the winegcc ones don't, but these seem to all be linking rather than compiling.) I have run file over the binaries, and they all say ELF 32-bit LSB executable (or shared object, for the libraries). Out of interest, how did you know it had been compiled as 64 bit? Any ideas how I can track down which bit is being mis-compiled as 64 bit, so I can tidy up the build for that part? And is anyone else seeing the same symptoms (ie: WINEDEBUG="+relay" wine crashing)? I've got a pretty vanilla Fedora install, apart from being AMD64, so I shouldn't be unique.... thanks, Adrian

1 0

Re: Firefox 1.0.4 Installation
by Juan Lang 13 May '05

13 May '05

Andrew wrote: > Firefox appeared to install correctly, but it won't start. Trying to > install under winedbg with WINDEBUG=+trace winedbg to terminate the > application after I typed "next": Hmm, works for me here. I assume you mean WINEDEBUG=, not WINDEBUG=. And, do you mean WINEDEBUG=trace or WINEDEBUG=trace+all? I think +trace will have no effect, as trace isn't the name of a debug channel. --Juan __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

1 0

Firefox 1.0.4 Installation
by Andrew Neil Ramage 13 May '05

13 May '05

When I tried to install Firefox 1.0.4 for Windows, I got the following output in the shell window I started wine from. andrew@zeus:~/Download/Software> wine Firefox\ Setup\ 1.0.4.exe fixme:win:SetWindowTextW cannot set text L"Extracting" of other process window 0x7002e err:static:STATIC_SetIcon huh? hicon!=0, but info=0??? err:static:STATIC_SetIcon huh? hicon!=0, but info=0??? err:ntdll:NtQueryInformationToken Unhandled Token Information class! fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:shell:Stream_WriteLocationInfo writing empty location info fixme:exec:ShellExecuteExW32 flags ignored: 0x00000340 andrew@zeus:~/Download/Software> err:ntdll:NtQueryInformationToken Unhandled Token Information class! fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 andrew@zeus:~/Download/Software> Firefox appeared to install correctly, but it won't start. Trying to install under winedbg with WINDEBUG=+trace winedbg to terminate the application after I typed "next": andrew@zeus:~/Download/Software> winedbg Firefox\ Setup\ 1.0.4.exe fixme:console:SetConsoleCtrlHandler (0x405ef3e0,1) - no error checking or testing yet WineDbg starting on pid 0x15 In 32 bit mode. Wine-dbg>next Process of pid=0x00000015 has terminated Wine-dbg> Does anyone know what is going wrong ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards 13 May '05

13 May '05

Hi, --- Francois Gouget <fgouget(a)free.fr> wrote: > No, that should not happen. If an application links with a library that > exports funcA() and funcB() but it only calls funcA(), then it will only > import funcA() and it will work on a system where that library only > exports funcA(). OK maybe I am thinking of a bug in binutils or something. There were a few of them caused problems when building on mingw which result in me having to hack Winebuild a bit. Thanks Steven Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

1 0

Re: winefile temporary allocations
by Francois Gouget 13 May '05

13 May '05

On Fri, 13 May 2005, Martin Fuchs wrote: > Changelog > use macros for platform dependent temporary allocations [...] > +#define TMP_ALLOC(s) HeapAlloc(GetProcessHeap(), 0, s) > +#define TMP_FREE(p) HeapFree(GetProcessHeap(), 0, p) > +#else > +#define TMP_ALLOC(s) alloca(s) > +#define TMP_FREE(p) > #endif Why is this needed? Doesn't HeapAlloc work on any 'Win32' platform? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

3 2

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink 13 May '05

13 May '05

Peter wrote: > I see. > Of course I have Acrobat 7 installed. The problem is Adobe does not > supply the DRM plugin (Yea I know some of you do not like DRM and I have > too some reservations but we should have the choice, shouldn't we?) > Since the only other way to get DRM support beside wine is VMware wich > is more ugly to set up. > > I would like to have a working Acrobat reader with DRM support on wine > since this is less trouble (and more efficent) then the VMware solution > people use atm. > > Maybe I can get Acrobat reader 5 with DRM support up and running. > Adobe has a very confusing policy of giving away information what > Version can on which Plattform. > I send them a note already but i fear (like always) I am ignored. :( > > cheers > Peter > > Am Donnerstag, den 12.05.2005, 11:46 -0400 schrieb gslink: > >>Use the native Linux Reader 7 from the Adobe web site. Running Reader 7 >>under Wine isn't worth the trouble. Acrobat Professional is a different >>matter. The latest Acrobat Professional that will work on Wine is 5. >>Both 6 and 7 require dlls that must be supplied from Windows. Seven has >>copy protect features that actually discourage use on any machine. With >>some trouble you can probably get 6 to work. It will currently install >>and with the addition of the missing dlls almost work. If someone wants >>to patch Wine so that 6 runs it would probably see considerable use. >> > > > The only difference between talking to a telephone pole and talking to Adobe is that if you drink enough the telephone pole will answer. In reality almost nothing of any importance currently runs on Wine without some setup. What you probably need to do is to experiment with replacing some of the dlls or adding some from Windows. This is usually what is necessary. You may also need to install the software in a Windows machine and then copy it over. Start trying things and something will probably work. I have been getting on the Wine people because this feature of Wine makes it useless for the average user. There needs to be some easy way for someone to report what is necessary to get a new version of something running or there needs to be a good configurator written. Wine is a very good program but the Wine group is making a classic programming error in forgetting the user interface. It doesn't make any difference how good it is if you can't get at it! In this case you can't.

2 1

Re: Looking for win9x/ME testers
by Saulius Krasuckas 13 May '05

13 May '05

* On Thu, 12 May 2005, Hans Leidekker wrote: > * On Thursday 12 May 2005 00:14, Kevin Koltzau wrote: > > The ole32_test.exe file is linked to missing export NTDLL.DLL:atoi. > > This patch fixes it. ... > Changelog: > Don't import from ntdll. Can someone explain me, please, where would atoi() function be linked now to? I still have not installed MinGW package, so cannot cross-compile winetest and cannot check this myself. :-/

2 1

Re: Extending File Dialog to include unix file paths [4/4]
by Steven Edwards 13 May '05

13 May '05

Hi Michael, I really like the idea of trying to tie the apps in better for users of Winelib applications but I have a few problems. (I should have spoken up when the first of the Unixfs stuff was going in to shell32 because I feel it should have been a shellext outsite of shell32 but now I am off the subject) --- Michael Lin <mlin(a)corvu.com.au> wrote: --- dlls/commdlg/comdlg32.spec +@ stdcall UnixFSGetOpenFileNameA(ptr) +@ stdcall UnixFSGetOpenFileN Is there anyway for us to have these functions inlined or something rather than exported all the time is there? The reason I ask is that being able to build applications using Wine on Windows and Mingw helps with testing and if we building on Windows using Wine headers and link to the Wine import libs the application will fail running the application on Windows because the Windows dll wont export these functions. +BOOL WINAPI UnixFSGetSaveFileNameW( + LPOPENFILENAMEW ofn) /* [in/out] address of init structure */ +{ + BOOL win16look = FALSE; + + if (ofn->Flags & (OFN_ALLOWMULTISELECT|OFN_ENABLEHOOK|OFN_ENABLETEMPLATE)) + win16look = (ofn->Flags & OFN_EXPLORER) ? FALSE : TRUE; + + if (win16look) + return GetFileName31W(ofn, SAVE_DIALOG); + else You should not need any of this for a Winelib app. Office97 does this where it creates a 32bit dialog with a Win16 look and its needed for backwards compatiblity only. No new application should depend on this behavior and clearly not one that you have the source code to in Winelib. I already broke this in Wine once. Just return GetFileDialog95W. + return GetFileDialog95W(ofn, SAVE_DIALOG, TRUE); } Thanks Steven Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

2 1

ERROR_NOT_READY (21) in ne_module.c
by Felix Nawothnig 13 May '05

13 May '05

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

3 5

Re: Support for binaries that were abandoned by M$, and maintenance hell?
by Steven Edwards 13 May '05

13 May '05

--- Francois Gouget <fgouget(a)free.fr> wrote: > Furthermore a lot of '32bit applications' actually use 16bit code either > directly or indirectly (although that may be getting less common these > days). What this means is that if you remove 16bit support it's quite > likely a lot of 32bit applications will stop working. I do wish we could change it though. We could share more code with ReactOS with less hassle on merges if we could figure out a way to split the Win16 code out better for say the edit control. Thanks Steven Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/

1 0

Re: [?? Probable Spam] user32.dll Add redraw and WM_WINDOWPOS* notifications to SetActiveWindow [1]
by Dmitry Timoshkov 13 May '05

13 May '05

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > According to native messages sent to app we should redraw window > inside SetActiveWindow. If you have a test app then it should be converted into a Wine message test, there is no other way to prove that your patch is correct. > @@ -152,7 +232,7 @@ static BOOL set_active_window( HWND hwnd > > if (IsWindow(hwnd)) > { > - SendMessageW( hwnd, WM_NCACTIVATE, (hwnd == GetForegroundWindow()), (LPARAM)previous ); > + SendMessageW( hwnd, WM_NCACTIVATE, TRUE, (LPARAM)previous ); Active and foreground windows in win32 are not necessary the same window. -- Dmitry.

3 4

Support for binaries that were abandoned by M$, and maintenance hell?
by Dustin Navea 12 May '05

12 May '05

The discussion on 16-bit support for cards.dll led me to an interesting theory. If the big name vendors are dropping support for 16-bit programs, they must be doing it for a reason, right? The only reason I can come up with is because they dont have the resources (or maybe just the desire) to maintain 2 separate trees (1 16-bit and 1 32-bit), and soon to be 3 trees including 64-bit.. We have the desire to allow any windows program to run, whether it runs in a current version of windows or not. The problem with this is that over time, dos support has faded damatically, as well as win16 support. Soon we will start writing more win64 conformance code, and less win32. Where will that leave all of the people that dont jump on the 64-bit bandwagon any time soon? <flame war first shot> I think we are getting to that point, from a maintenance perspective, where we should seriously consider reorganizing the project into a more hierarchal (sp?) structure, where we have some people that can take some time off from contributing 32 or 64-bit code when need be, to contribute some 16-bit code for a user who wants to use an older program. Possibly (just an idea) we should make a dedicated project page on sourceforge specifically for 16-bits. As I said, soon we will be not necessarily abandoning 32-bits, but writing more 64-bits.. Sure we have separation to keep things apart, but wine is starting to get loaded down with things that only a small minority of users need anymore.. Perhaps it is time (just another idea) to copy out the 16-bit code into it's own project? That way we can organize things more efficiently, and at the same time, reduce 1) download time of wine, and 2) compile time. Of course, we would still leave 16-bit support in the main project, but we would no longer maintain it there.. We could maintain it in wine16.... </flame war first shot> Comments? Suggestions? Flames??? Bring it ;-) Dustin

4 3

Bug 2931 (again)
by Dustin Navea 12 May '05

12 May '05

Ok, the author has posted a link to the commit.. http://www.winehq.org/hypermail/wine-cvs/2004/10/0376.html Seems to be what broke it, per regression testing. I dunno if this maybe caused a bug somewhere else to show up or what, but I figure someone could look at it.. Dustin

5 8

CVS compilation problem
by Uwe Bonnes 12 May '05

12 May '05

Hallo, I updated yesterday and today. Compiling with todays CVS gives: ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole joystick.o keyboard.o mouse.o testlist.o -o dinput_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/dinput -L../../../dlls/ole32 -L../../../dlls/version -L../../../dlls/user32 -L../../../dlls/kernel32 -L../../../libs -ldinput -lole32 -lversion -luser32 -lkernel32 -ldxguid -luuid -ldxerr8 joystick.o(.text+0x543): In function `EnumJoysticks': /spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:165: undefined reference to `c_dfDIJoystick' joystick.o(.text+0x592):/spare/bon/wine-realclean/wine/dlls/dinput/tests/joystick.c:169: undefined reference to `c_dfDIJoystick2' collect2: ld returned 1 exit status Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

Re: info please part 2
by Dustin Navea 12 May '05

12 May '05

juan melgarejo wrote: > Is there any document or how-to showing: > how to run a backtrace using the wine debugger > how set debug parameters for wine tracing of program execution > how to submit bugs to bugzilla (how to report, content) > How to Know proper settings for bugs > (when a bug should be a blocker, which bug depends on which other bug, > etc) ? I should mention that the wine documentation is somewhat out of date, so generally if you don't already know how to do the things mentioned above, they will give you a rough idea, but some of the parameters have changed (especially on setting debug flags for tracing). While you can still apply, the users who already know how to do the above will obviously have a greater chance to be recruited. Dustin

1 0

Re: info please
by Dustin Navea 12 May '05

12 May '05

juan melgarejo wrote: > Is there any document or how-to showing: > how to run a backtrace using the wine debugger > how set debug parameters for wine tracing of program execution > how to submit bugs to bugzilla (how to report, content) > How to Know proper settings for bugs > (when a bug should be a blocker, which bug depends on which other bug, > etc) ? > > Regards, > Juan > The Wine FAQ at http://winehq.org/site/docs/wine-faq/index The Wine User Guide at http://winehq.org/site/docs/wine-user/index The Wine Developers Guide at http://winehq.org/site/docs/wine-devel/index How to help get applications working in Wine at http://winehq.org/site/helping-applications Getting Started with Wine Development at http://winehq.org/site/developer-cheatsheet Those are the best resources. You can also check the wine wiki (although I don't have the address).. Dustin

1 0

Re: Installing Acrobat Reader 7 and Acrobat in general
by gslink 12 May '05

12 May '05

Use the native Linux Reader 7 from the Adobe web site. Running Reader 7 under Wine isn't worth the trouble. Acrobat Professional is a different matter. The latest Acrobat Professional that will work on Wine is 5. Both 6 and 7 require dlls that must be supplied from Windows. Seven has copy protect features that actually discourage use on any machine. With some trouble you can probably get 6 to work. It will currently install and with the addition of the missing dlls almost work. If someone wants to patch Wine so that 6 runs it would probably see considerable use.

1 0

Now Recruiting
by Dustin Navea 12 May '05

12 May '05

Please do not reply to this email with this same subject line unless you are notifying myself that you would like to have an interview. If you need to discuss this more with me, use a subject of "Discuss - Now Recruiting" Attention all users of wine! Have you ever run into a situation where "it worked before, but now it doesnt"? Have you ever wanted to help out the wine project, but either don't know how to program, or don't know how to get started? Have you reported bugs on bugs.winehq.com and gotten frustrated because of the response time? You are not alone! The Wine Project is proud to announce that we are now recruiting for Maintainer/Janitor positions on the Bugzilla Database! Bugzilla Maintainers should: Have a good working knowledge of Linux Know how to run a backtrace using the wine debugger Know how set debug parameters for wine tracing of program execution Know how to submit bugs to bugzilla Know proper settings for bugs (when a bug should be a blocker, which bug depends on which other bug, etc) Have strong interpersonal communication skills, and outstanding customer service skills Programming knowledge/experience is a BIG Plus, but is not required Being able to set aside a minimum of 7 hours a _week_ to work on bugs is a BIG Plus, but is not required This position is for the most part unsupervised, and strictly voluntary, meaning you will not be compensated/paid in any way. An interview does not create any form of contract either express or implied between you and The Wine Project, nor any of it's developers, contributors, subsidiaries, sister projects, or other users. If you feel that you have what it takes, and would like to apply, please reply to this message, and send it to Dustin Navea (Speeddymon at gmail dot com) Thanks and good luck! Wine Developers

1 0

Re: comctl32: Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg
by Rein Klazes 12 May '05

12 May '05

On Thu, 12 May 2005 02:59:38 -0500, you wrote: > Hey, > > This is a patch for the WM_LBUTTONUP msg problem, but I've taken the > advice of Dmitry and now all messages are dispatched. > > Changelog > * Make sure all msg's are dispatched while tracking a WM_LBUTTONDOWN msg. Patches like this have been proposed before. They are wrong: Windows *does* eat the WM_LBUTTONUP in the mouse track message loop. There are cases when in Wine this mouse tracking is entered, where they are not under Windows thus causing loss of messages. http://www.winehq.org/hypermail/wine-devel/2004/05/0159.html http://www.winehq.org/hypermail/wine-devel/2004/09/0072.html Rein.

1 0

Re: comctl32: Make sure a WM_LBUTTONUP msg is dispatched while after a WM_LBUTTONDOWN msg
by Dmitry Timoshkov 12 May '05

12 May '05

"James Hawkins" <truiken(a)gmail.com> wrote: > You were right about having the NM_CLICK msg sent in > LISTVIEW_LButtonUp, and the problem was that a WM_LBUTTONUP msg was > never sent. This fixes the problem where you had to double click an > item in the drives list to select it. > > Changelog > * Make sure a WM_LBUTTONUP msg is dispatched after tracking a WM_LBUTTONDOWN msg > --- dlls/comctl32/listview.c 6 May 2005 15:44:32 -0000 1.409 > +++ dlls/comctl32/listview.c 12 May 2005 05:04:06 -0000 > @@ -7948,6 +7948,9 @@ static LRESULT LISTVIEW_TrackMouse(LISTV > else if (msg.message >= WM_LBUTTONDOWN && > msg.message <= WM_RBUTTONDBLCLK) > { > + if (msg.message == WM_LBUTTONUP) > + DispatchMessageW(&msg); Why WM_LBUTTONUP should be different from other kinds of messages? I.e. why all messages could not be passed to DispatchMessage? What if just move DispatchMessageW call right right after PeekMessageW? -- Dmitry.

2 1

Getting rid of LOCAL_ exports
by Dimi Paun 12 May '05

12 May '05

>From a cursory look at the problem, it seems we can turn things upside down. Right now LOCAL_*() functions (Wine specific) are equivalent to the Local*16() functions (Windows exports), with the exception that they take a selector as first argument (which makes them more general). As a result, Local*16() functions are implemented on top of the LOCAL_*() ones. This is only half of the story. In fact, the Local*16() functions do take the segment as input, but in a more awkward manner: as the value of the DS register. So we can actually implement the LOCAL_*() functions on top of the Local*16() ones by messing with the DS register. Doing so would hopefully get rid of the LOCAL_*() exports from kernel. I've taken a stab (prototype level) at the LOCAL_Alloc() function (patch included below). Would such an approach be acceptable? Index: include/local.h =================================================================== RCS file: /var/cvs/wine/include/local.h,v retrieving revision 1.6 diff -u -p -r1.6 local.h --- include/local.h 28 Aug 2003 21:43:35 -0000 1.6 +++ include/local.h 10 May 2005 18:20:03 -0000 @@ -23,12 +23,22 @@ #include <windef.h> #include <wine/windef16.h> +#include <stackframe.h> /* These function are equivalent to the Local* API functions, */ /* excepted that they need DS as the first parameter. This */ /* allows managing several heaps from the emulation library. */ +static inline HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD size ) +{ + HANDLE16 oldDS = CURRENT_DS; + HLOCAL16 ret; + + CURRENT_DS = ds; + ret = LocalAlloc16 (flags, size); + CURRENT_DS = oldDS; + return ret; +} -extern HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD size ); extern HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle, WORD size, UINT16 flags ); extern HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL16 handle ); Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /var/cvs/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.148 diff -u -p -r1.148 kernel32.spec --- dlls/kernel/kernel32.spec 10 May 2005 15:22:10 -0000 1.148 +++ dlls/kernel/kernel32.spec 10 May 2005 18:22:10 -0000 @@ -1167,7 +1167,6 @@ # Wine dll separation hacks, these will go away, don't use them # @ cdecl DOSMEM_AllocSelector(long) -@ cdecl LOCAL_Alloc(long long long) @ cdecl LOCAL_Compact(long long long) @ cdecl LOCAL_CountFree(long) @ cdecl LOCAL_Free(long long) Index: dlls/kernel/local16.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/local16.c,v retrieving revision 1.10 diff -u -p -r1.10 local16.c --- dlls/kernel/local16.c 24 Mar 2005 21:01:38 -0000 1.10 +++ dlls/kernel/local16.c 10 May 2005 17:56:15 -0000 @@ -1150,15 +1150,13 @@ HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL /*********************************************************************** - * LOCAL_Alloc - * - * Implementation of LocalAlloc(). - * + * LocalAlloc (KERNEL.5) */ -HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD flags, WORD size ) +HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size ) { + HANDLE16 ds = CURRENT_DS; + HLOCAL16 handle = 0; char *ptr; - HLOCAL16 handle; TRACE("%04x %d ds=%04x\n", flags, size, ds ); @@ -1171,7 +1169,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD if(size) { if (!(hmem = LOCAL_GetBlock( ds, size + MOVEABLE_PREFIX, flags ))) - return 0; + goto exit; } else /* We just need to allocate a discarded handle */ hmem = 0; @@ -1180,7 +1178,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD WARN("Couldn't get handle.\n"); if(hmem) LOCAL_FreeArena( ds, ARENA_HEADER(hmem) ); - return 0; + goto exit; } ptr = MapSL( MAKESEGPTR( ds, 0 ) ); plhe = (LOCALHANDLEENTRY *)(ptr + handle); @@ -1199,10 +1197,11 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD } else /* FIXED */ { - if(!size) - return 0; - handle = LOCAL_GetBlock( ds, size, flags ); + if(size) handle = LOCAL_GetBlock( ds, size, flags ); } + +exit: + CURRENT_STACK16->ecx = handle; /* must be returned in cx too */ return handle; } @@ -1595,17 +1594,6 @@ HLOCAL16 LOCAL_Handle( HANDLE16 ds, WORD /*********************************************************************** - * LocalAlloc (KERNEL.5) - */ -HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size ) -{ - HLOCAL16 ret = LOCAL_Alloc( CURRENT_DS, flags, size ); - CURRENT_STACK16->ecx = ret; /* must be returned in cx too */ - return ret; -} - - -/*********************************************************************** * LocalReAlloc (KERNEL.6) */ HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16 flags ) -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

Installing Adobes Acrobat Reader 7.0 (Windows XP Version I think)
by Peter 12 May '05

12 May '05

Hello, I try to install the Adobes Acrobatreader 7.0. Now this didn't work it gave me a quite odd message that an unexpected error occured with a long number. I tried to run wine with the debug Variable +all. I never done this before so can anybody help me? Is the ntdll missing something or is it an bug? thx in advance Peter winedebug geave me at the same point this: 0009:Ret PE DLL (proc=0x7f510000,module=0x7f500000 L"imm32.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x76de7698,module=0x76de0000 L"gdi32.dll",reason=PROCESS_ DETACH,res=0x1) 0009:Call kernel32.__wine_unregister_dll_16(76e39680) ret=76de7872 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000007 ret=76de7872 0009:Call kernel32.__wine_unregister_dll_16(76e39698) ret=76deaa02 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000008 ret=76deaa02 0009:Call kernel32.__wine_unregister_dll_16(76e396b0) ret=76deace2 0009:Ret kernel32.__wine_unregister_dll_16() retval=00000009 ret=76deace2 0009:Ret PE DLL (proc=0x76de7698,module=0x76de0000 L"gdi32.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x7705ebd0,module=0x77050000 L"advapi32.dll",reason=PROCE SS_DETACH,res=0x1) 0009:Ret PE DLL (proc=0x7705ebd0,module=0x77050000 L"advapi32.dll",reason=PROCE SS_DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x77b02f00,module=0x77af0000 L"kernel32.dll",reason=PROCE SS_DETACH,res=0x1) 0009:Call ntdll.RtlEnterCriticalSection(77bde5c0) ret=77b4e3e5 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b4e3e5 0009:Call ntdll.RtlLeaveCriticalSection(77bde5c0) ret=77b4e3f5 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b4e3f5 0009:Ret PE DLL (proc=0x77b02f00,module=0x77af0000 L"kernel32.dll",reason=PROCE SS_DETACH,res=0x1) retval=1 0009:Call PE DLL (proc=0x77eb535c,module=0x77ea0000 L"ntdll.dll",reason=PROCESS_ DETACH,res=0x1) 0009:Ret PE DLL (proc=0x77eb535c,module=0x77ea0000 L"ntdll.dll",reason=PROCESS_ DETACH,res=0x1) retval=1 0009:Ret ntdll.LdrShutdownProcess() retval=00000000 ret=77b484a2 0009: terminate_process( handle=0xffffffff, exit_code=1150 ) 0009: terminate_process() = 0 { self=1 } 0009: *killed* exit_code=1150

2 1

Re: msvcrt: implement signals, take 2
by Alexandre Julliard 12 May '05

12 May '05

Juan Lang <juan_lang(a)yahoo.com> writes: > + switch (sig) > + { > + /* Cases that fall through to signal(2) */ > + case SIGABRT: > + case SIGFPE: > + case SIGILL: > + case SIGSEGV: > + ret = signal(sig, func); > + break; You can't do that, this will cause major trouble. MSVCRT signals should be generated from Win32 exceptions. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: tools/widl
by Ge van Geldorp 12 May '05

12 May '05

I'm wondering what happened to the reworked widl patch at http://www.winehq.org/hypermail/wine-patches/2005/04/0371.html? It hasn't been applied yet, does that mean there's no interest on the Wine side and I can drop it from my TODO list? Best regards, Ge van Geldorp.

2 1

Re: user32.dll fix and test ShowOwnedPopups
by Dmitry Timoshkov 12 May '05

12 May '05

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > ShowOwnedPopups should handle none WS_POPUP style windows as well. > And actually show/hide windows. > Match names for WM_SHOWWINDOW status codes to MSDN > @@ -2701,6 +2701,7 @@ BOOL WINAPI ShowOwnedPopups( HWND owner, > * regardless of the state of the owner > */ > SendMessageW(win_array[count], WM_SHOWWINDOW, SW_SHOW, SW_PARENTOPENING); > + ShowWindow(win_array[count], SW_SHOW); > continue; > } > } > @@ -2715,6 +2716,7 @@ BOOL WINAPI ShowOwnedPopups( HWND owner, > * regardless of the state of the owner > */ > SendMessageW(win_array[count], WM_SHOWWINDOW, SW_HIDE, SW_PARENTCLOSING); > + ShowWindow(win_array[count], SW_HIDE); Then each owned window will receive 2 WM_SHOWWINDOW messages. Are you sure that Windows does it that way? I'd advise to write a message test to verify it. -- Dmitry.

2 2

[Bug 2932] - copy / paste to openoffice
by Dustin Navea 12 May '05

12 May '05

Basically, before 01/11/05, copying and pasting to OO worked, and after said date, it doesn't. The Bug is at: http://bugs.winehq.org/show_bug.cgi?id=2932 The patch causing it is at: http://www.winehq.org/hypermail/wine-cvs/2005/01/0276.html It looks like the patch removed W->A calls from the clipboard code. All other relevant information is posted in the bug Dustin

2 1

Borland software patent restricting Wine development
by Ingrid Marson 12 May '05

12 May '05

I'm writing an article today following Dimitri O. Paun's talk at the Wine Developer conference in Stuttgart. He said that Winelib development is restricted due to a Borland software patent. Borland's software patent means that an important feature to the Gnu Compiler Collection project cannot be applied. Winelib support would depend on that patch. The FFII has written an article on this: http://wiki.ffii.org/WineConf050501En I am keen to find out more about this issue. Does anyone know about this issue, or know how I can contact Dimitri? (I have tried to find his email address using Google but haven't had any success). Thanks for your help. Regards, Ingrid Ingrid Marson Reporter ZDNet UK www.zdnet.co.uk T: +44 (0)20 7903 6835

3 2

Wine test question: How to test for messages send?
by Tobias Burnus 12 May '05

12 May '05

Hello, I'm trying to write a conformance test for user/edit.c: EDIT_EM_ReplaceSel(). While I figured out how to send messages, call functions etc. I don't know how to check whether a message has been sent. But I need to know whether Windows sends one as a EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT") causes my Origin to crash. Background: Origin crashes since a patch was introduced in Wine which sends this message. Origin (at least under Wine) seems to create a 7px wide edit control which is then trys to fill with "10" (being 20px wide). Since not even "1" fits in there, the content of the edit control is "" and a EN_MAXTEXT is sent. While removing the EDIT_NOTIFY_PARENT line helps, this is surely not the right solution; Lauri Tulmin (author of mentioned patch) suggested to test for it: "From what I understand, the program crashes when it receives EN_MAXTEXT notification. You should figure out why the textbox is too small to contain the text. Or maybe this notification shouldn't be sent at all, although MSDN says it should be, but maybe there are some exceptions. Probably you'll need to write some test's to figure out what exactly goes wrong." For details, see bug 2813. http://bugs.winehq.org/show_bug.cgi?id=2813 Tobias

2 1

SEH and gcc again
by Daniel Kegel 11 May '05

11 May '05

The old SEH / gcc question came up again on the gcc mailing list; see http://gcc.gnu.org/ml/gcc/2005-05/msg00511.html and followups. If anyone has anything constructive to add to that thread, this is a good chance to get the story right before it shows up on ZDNet.

1 0

Looking for win9x/ME testers
by Stefan Leichter 11 May '05

11 May '05

Hello, the ole32 tests are working now for WinNT again: But they do not load on win9x/ME. Can someone with a Win9x/ME system run ole32_test.exe manualy and report the text displayed in the message box when it is started. ole32_test.exe is included in winetest-latest.exe. You can download winetest-latest.exe from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ You will find ole32_test.exe in c:\temp\wct when the tests are performed. Thanks for your help Stefan

2 1

Flattening of ddraw directory and renaming of files
by Christian Costa 11 May '05

11 May '05

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

5 9

Re: [QCAP] patch 3, Adding enumMediaType object
by Robert Shearman 11 May '05

11 May '05

Rolf Kalbermatter wrote: >Changelog > - dlls/qcap/Makefile.in > - dlls/qcap/qcap_main.h > dlls/qcap/enummedia.c > Add IEnumMediaType object for use by other class objects. This is >taken > from quartz with only minor adaptions. > > We should be putting these files into a static library that we can link to from quartz, qcap & other DirectShow dependent DLLs. Rob

2 1

Bug 2398
by Dustin Navea 11 May '05

11 May '05

Lionel, it appears that bug 2398 is up your alley. sigh :) I was hoping it would be an easy fix.. Oh well. Its got something to do with the window/gl rewrite, if you could look at it and the regression causing patch when you get time, it would be appreciated. Thanks Dustin

3 2

(no subject)
by Jason Couture 11 May '05

11 May '05

http://www.FreeMiniMacs.com/?r=18190345

1 0

Re: Commercial support
by Shachar Shemesh 11 May '05

11 May '05

MediaHost (TM) wrote: > Hi All, > > I'm not sure, if winehq should be a platform for advertisements of > commercial services (except maybe codeweavers), otherwise there will > be a very long list there, very soon. That's good, in principle. The problem brought up during wineconf was that the lack of commercial support is viewed by potential deployers as a minus, making wine a dangerous technology. Saying "here is a list of companies willing to take your money and give you support" is actually a good thing for Wine. > And who to include and who not? Ah, there you have hit a more serious problem. For example, there is no doubt that CodeWeavers has been both a^Hthe major wine driving force, AND a financial sponsor. However, if we don't allow other companies room, we are unfair towards the other companies, towards CodeWeavers (why should they continue to be practically the only ones carrying the load), and towards Wine (and we don't want Wine to become a CodeWeavers subproject, do we?). I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to "in the past year". At the moment, I believe only three companies pass that criteria (CodeWeavers, Lingnu, and Dimi's company, whose name he has successfully kept secret, for some reason). Alternatively, we can have several lists. A "Gold" list, which includes companies that have the means to produce fixes to wine itself if necessary (as judged by the above criteria), and a normal list, which merely includes anyone who declares that they are willing to provide commercial support. I would have suggested a nominal fee (i.e. - a $50 contribution to the wine fund per year, or some such thing) from the last list. On the up side, it allows us to know the company is still active in this field. On the down side, I don't think we have the resources to start tracking who paid and who didn't. I could even suggest a platinum list, which would include any company that employs the equivalent of a full time Wine developer or up. Of course, this currently only includes CodeWeavers. The idea I'm trying to push here is that we can do such a list, so long as we keep clear objective criterias for who gets listed where. > Are there such plans to include such links on the website, except for > community based support? That's what we talked about over wineconf. It seems that such a list gives credibility to a project, and as such is a wanted thing. A company considering wine deployment is more likely to accept wine if they know they can get support for it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html

16 46

Re: Unknown stab type in crashes
by James Hawkins 11 May '05

11 May '05

On 5/11/05, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > Why not try grepping out the err:debug_help lines, so that you can read > the backtracve ? > I could do that, but the real question is do we have to display all of the debug_help error lines. The output occurrs every crash whether I'm using anything native or not. It seems to me that we could look into why we're running into unknown stab types or whether we can add handlers for these types so they wouldnt be unknown. -- James Hawkins

1 0

Re: listview: Send NM_CLICK notification when listview is clicked
by Alexandre Julliard 11 May '05

11 May '05

James Hawkins <truiken(a)gmail.com> writes: > Hi, > > I verified this with native comctl32. > > Changelog > * Send NM_CLICK notification when listview is clicked. We already send NM_CLICK on button up, it doesn't look right to do it twice... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/msvcrt/files.c: Flush stdio buffers
by Alexandre Julliard 11 May '05

11 May '05

wine.larry.engholm(a)xoxy.net writes: > One of the changes to file.c for revision 1.66 (2004/05/12) moved the > code to flush output buffers from _close() to MSVCRT_fclose(). The > latter function isn't called by msvcrt_free_io() which is called by > DllMain() for DLL_PROCESS_DETACH, so buffers are no longer flushed > when a program exits. Then it's msvcrt_free_io() that should be fixed, not _close(). -- Alexandre Julliard julliard(a)winehq.org

1 0

Bug 2660
by Dustin Navea 11 May '05

11 May '05

Bug 2660 is a regression, and the patch causing it is here: http://www.winehq.org/hypermail/wine-cvs/2004/12/0100.html Could someone take a look at the patch to see what may be wrong? Multiple (over 3) users are having this same problem on multiple versions of lotus notes..

4 3

Re: Assertion fails in riched20; relay debug segfaults
by Adrian Harvey 11 May '05

11 May '05

> On Mon, 09 May 2005 21:44:58 +1200, Adrian Harvey wrote: > > If I try to GDB wine I get all sorts of ugly errors > > Try an strace in "follow forks mode". Does that help? > > thanks -mike Ok, here goes: $ WINEDEBUG=+relay strace -f wine execve("/usr/local/bin/wine", ["wine"], [/* 34 vars */]) = 0 [ Process PID=7877 runs in 32 bit mode. ] uname({sys="Linux", node="orac", ...}) = 0 brk(0) = 0x804a000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(0x3, 0xffffce38) = 0 old_mmap(0x1e7c500000000, 8589934593, PROT_READ|PROT_WRITE, 0xf /* MAP_??? */|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE|MAP_POPULATE| MAP_NONBLOCK|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|MAP_LOCKED| 0xfffe06c0, 770, 0x2075c00000000) = 0x55555000 close(3) = 0 open("/usr/local/lib/libwine.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\31"..., 512) = 512 fstat64(0x3, 0xffffcecc) = 0 old_mmap(0x100000000000, 146028888067, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, 0x4 /* MAP_??? */|MAP_FIXED| MAP_ANONYMOUS|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0x560680, 5645560, 0x80055b415) = 0x55574000 old_mmap(0x1888000000000, 8804682956805, PROT_READ|PROT_WRITE, 0x5 /* MAP_??? */|MAP_FIXED|MAP_POPULATE|MAP_NONBLOCK|MAP_EXECUTABLE| MAP_LOCKED|0x540400, 28, 0x5543b5ffffce10) = 0x55575000 old_mmap(0x10005557b000, 8873402433539, PROT_READ|PROT_WRITE, 0x5 /* MAP_??? */|MAP_FIXED|MAP_POPULATE|MAP_NONBLOCK|MAP_EXECUTABLE| MAP_LOCKED|0x540400, 28, 0x5543b5ffffce10) = 0x5557b000 old_mmap(0x118805557c000, 214748364803, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, 0x5 /* MAP_??? */|MAP_FIXED| MAP_POPULATE|MAP_NONBLOCK|MAP_EXECUTABLE|MAP_LOCKED|0x540400, 28, 0x5543b5ffffce10) = 0x5557c000 close(3) = 0 open("/lib/tls/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\10l"..., 512) = 512 fstat64(0x3, 0xffffceb0) = 0 old_mmap(0x111dc006bc000, 8804682956805, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x6bc000 old_mmap(0x2000006ca000, 8873402433539, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x6ca000 old_mmap(0x11dc006cc000, 214748364803, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, MAP_FILE, 0, 0) = 0x6cc000 close(3) = 0 open("/lib/tls/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\237"..., 512) = 512 fstat64(0x3, 0xffffce94) = 0 old_mmap(0x129c9c00565000, 8804682956805, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0x6cb12400000000) = 0x565000 mprotect(0x688000, 27804, PROT_NONE) = 0 old_mmap(0x400000689000, 8873402433539, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0x6cb12400000000) = 0x689000 old_mmap(0x1c9c0068d000, 214748364803, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, MAP_FILE, 0, 0x6cb12400000000) = 0x68d000 close(3) = 0 open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\33"..., 512) = 512 fstat64(0x3, 0xffffcdf8) = 0 old_mmap(0x306400691000, 8804682956805, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x691000 old_mmap(0x200000693000, 8873402433539, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0) = 0x693000 close(3) = 0 old_mmap(0x100000000000, 146028888067, PROT_READ|PROT_WRITE|PROT_EXEC| PROT_GROWSDOWN|PROT_GROWSUP|0xfcfffff8, 0x4 /* MAP_??? */|MAP_FIXED| MAP_ANONYMOUS|MAP_GROWSDOWN|MAP_DENYWRITE|MAP_EXECUTABLE|0x560680, 512, 0x80055b415) = 0x5558e000 mprotect(0x693000, 4096, PROT_READ) = 0 mprotect(0x689000, 8192, PROT_READ) = 0 mprotect(0x6ca000, 4096, PROT_READ) = 0 mprotect(0x561000, 4096, PROT_READ) = 0 set_thread_area(0xffffd644) = 0 munmap(0x55555000, 124869) = 0 set_tid_address(0x5558e928) = 7877 rt_sigaction(SIGRTMIN, {0x4006c0380, [], 0x56d6f8}, NULL, 0) = 0 rt_sigaction(SIGRT_1, {0x10000004006c03f0, [], 0x56d6f8}, NULL, 0) = 0 rt_sigprocmask(SIG_UNBLOCK, [], NULL, 0) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=-4284481536, rlim_max=0}) = 0 Bus error $ 0009:Call kernel32.__wine_kernel_init() ret=55727d9e Well, I got some output at least! Never used strace before, but it looks kinda like a +relay trace for the kernel :-) Not sure what to make of the results, and I won't have time to look into it further til tomorrow... I also happened to be tailing the syslog (I was looking at something completely different) and I noticed that the following was written: May 11 22:50:55 orac kernel: strace[7749] trap stack segment rip:410c86 rsp:800000007b20 error:0 May 11 22:50:55 orac kernel: wine-preloader[7750]: segfault at 000000005575b624 rip 000000005575b624 rsp 00000000ffffc824 error 15 I doubt it's much use, but I thought any information might help here.... Adrian

2 1

Bug 2608 - shrinker compressed dll's cause error
by Dustin Navea 11 May '05

11 May '05

This has been reported on Might and Magic 6. The file mss32.dll is compressed with a program called shrinker, when the game is installed. If another program called DeShrinker is not run on that file, MM6 refuses to run with an error. Once that is run, the game runs fine. According to the notes, there is an extra piece of information in the header in the shrinker compressed dll's called .shrink . I think this has something to do with it, but I am not totally sure. Dustin

2 1

Bug 2919
by Dustin Navea 11 May '05

11 May '05

Bug 2919 is beyond my area, but there is a backtrace posted. Could someone take a look and guide me on what logs to get? Thanks P.S. If you could also tell me how to determine this information for myself, it would save the list and myself a lot of time and typing. :-) Dustin

2 1

Initial popup window and window manager
by Jose Alonso 11 May '05

11 May '05

I have a problem with an application that creates a initial popup window and starts another application. The window for the second application is completely covered by the initial popup window. Investigating the problem, I found that the popup window is not managed by the window manager and no other wine or gnome window can go on top of this window (even on top windows). Making the popup window managed works for me (Fedora core 3, gnome, metacity). I don't know in other configurations. See attached patch. I am attaching also a small program to create the popup window. -- alonso

2 1

New debugging tutorials
by Mike Hearn 11 May '05

11 May '05

Hi, I've added the first of what will hopefully become many debugging tutorials to the wiki: http://wiki.winehq.com/DebuggingTutorials Sometimes fixing Wine can be a bit hard to get into. Hopefully these short "show me" guides will give people a taste for what it involves and help newbies start. Please feel free to add more! They shouldn't be too advanced (so no copy protection, WM or DCOM debugging ;) but multiple levels of difficulty is fine. Ideally they should all be based on real apps. thanks -mike

2 1

Docs at SourceForge
by Dimi Paun 11 May '05

11 May '05

Hi folks, As most of you already noticed, the SGML docs have moved over to the CVS SourceForge: http://sourceforge.net/cvs/?group_id=6241 They clearly did not belong in the tree, and we decided at WineConf05 to move them out of there. So we did. I have renamed the files for a more uniform naming, and dropped couple of unused files in the process. We still need to change WineHQ's scripts to point them to the new location. Help with this would be appreciated. I'll be managing that tree for now (unless Alexandre wants to do it :)). Please send your patches as you usually do to wine-patches(a)winehq.org, but make sure to prefix the subject with '[WINEDOCS]' so I can more easily spot them. Discussions should take place on wine-devel(a)winehq.org as per normal. The new repository is set up with translations in mind, so hopefully will be able to handle them better in the future. I'll be working with Francois to integrate the French translation shortly. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: shell32 - ShellDDEInit
by Dmitry Timoshkov 11 May '05

11 May '05

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > The ReactOS guys are tired of seeing the fixme message. > > Changelog: > Implement ShellDDEInit > > Index: lib/shell32/shell32_main.c > =================================================================== > --- lib/shell32/shell32_main.c (revision 14808) > +++ lib/shell32/shell32_main.c (working copy) > @@ -979,13 +979,66 @@ > FIXME("%lx: stub\n",dw); > } > > - > +ATOM ProgmanAtom; > +DWORD hDde; > +UINT hProgmanTopic, hProgmanService, hStar, hShell, hAppProps, hFolders; > + > /************************************************************************* > * ShellDDEInit (SHELL32.@) > */ > -void WINAPI ShellDDEInit(BOOL start) > +void WINAPI ShellDDEInit(BOOL Start) > { > - FIXME("stub: %d\n", start); > + WCHAR wszSHELL_PROGMAN[] = {'P','R','O','G','M','A','N',0}; > + WCHAR wszSHELL_TOPIC[] = {'P','r','o','g','m','a','n',0}; > + WCHAR wszSHELL_SERVICE[] = {'P','r','o','g','m','a','n',0}; > + WCHAR wszSHELL_STAR[] = {'*',0}; > + WCHAR wszSHELL_SHELL[] = {'S','h','e','l','l',0}; > + WCHAR wszSHELL_APPPROPS[] = {'A','p','p','P','r','o','p', 'e', 'r', 't', 'i', 'e', 's',0}; > + WCHAR wszSHELL_FOLDERS[] = {'F','o','l','d','e','r','s',0}; > + > + if (Start) > + { > + /* Create Atom */ > + ProgmanAtom = GlobalAddAtomW(wszSHELL_PROGMAN); > + > + /* Initialize DDE */ > + DdeInitializeW(&hDde, NULL, CBF_FAIL_POKES | CBF_FAIL_ADVISES, 0L); > + > + /* Register the Strings */ > + hProgmanTopic = DdeCreateStringHandleW(hDde, wszSHELL_TOPIC, CP_WINUNICODE); > + hProgmanService = DdeCreateStringHandleW(hDde, wszSHELL_SERVICE, CP_WINUNICODE); > + hStar = DdeCreateStringHandleW(hDde, wszSHELL_STAR, CP_WINUNICODE); > + hShell = DdeCreateStringHandleW(hDde, wszSHELL_SHELL, CP_WINUNICODE); > + hAppProps = DdeCreateStringHandleW(hDde, wszSHELL_APPPROPS, CP_WINUNICODE); > + hFolders = DdeCreateStringHandleW(hDde, wszSHELL_FOLDERS, CP_WINUNICODE); > + > + /* Register the Service Names */ > + DdeNameService(hDde, hFolders, 0, DNS_REGISTER); > + DdeNameService(hDde, hProgmanService, 0, DNS_REGISTER); > + DdeNameService(hDde, hShell, 0, DNS_REGISTER); > + } > + else > + { > + /* Unregister the Service Names */ > + DdeNameService(hDde, hFolders, 0, DNS_UNREGISTER); > + DdeNameService(hDde, hProgmanService, 0, DNS_UNREGISTER); > + DdeNameService(hDde, hShell, 0, DNS_UNREGISTER); > + > + /* Free the Handles */ > + DdeFreeStringHandle(hDde, hProgmanTopic); > + DdeFreeStringHandle(hDde, hProgmanService); > + DdeFreeStringHandle(hDde, hStar); > + DdeFreeStringHandle(hDde, hShell); > + DdeFreeStringHandle(hDde, hAppProps); > + DdeFreeStringHandle(hDde, hFolders); > + > + /* Uninitialize DDE */ > + DdeUninitialize(hDde); > + hDde = 0; > + > + /* Delete the Atom */ > + if (ProgmanAtom) ProgmanAtom = GlobalDeleteAtom(ProgmanAtom); > + } > } If ReactOS guys could use 'static const' for unicode strings, make global variables visible inside of the single source file static, check whether DDE connection is being already [de]initialed and a little bit of error checking that would be even better :-) -- Dmitry.

1 0

Bug 2131 - 16-bit support?
by Dustin Navea 11 May '05

11 May '05

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. 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? Dustin

7 11

Bug 2947
by Dustin Navea 11 May '05

11 May '05

Bug 2947 is 2 issues in one, but they appear to coincide, so I didn't have him report them separately.. The patch causing this is at: http://www.winehq.org/hypermail/wine-cvs/2005/04/0290.html Its a big one too.. SO Basically, before this patch, the window did not show decorations (titlebar, etc), and the game closed fine using the exit button within the game. After this patch, though, the window shows decorations (which is preferred obviously), but the game hangs when you try to exit.. SO, reverting the patch would fix one issue, but bring back another, and you can see where I am going with this, so I don't have to say it... Dustin

1 0

[AppDB] - Application votes cleared
by Chris Morgan 11 May '05

11 May '05

I cleared out the votes on the appdb tonight after fixing a few bugs with the voting system. The next step is to put into place a system that will expire votes that are older than some value, perhaps a year or two. I'll try to get that into place in the next week or two. Chris

1 0

ExtTextOut() for paths
by Felix Nawothnig 10 May '05

10 May '05

Hi. The attached patch implements ExtTextOut() for "open" paths. It seems to be working correctly for my tests but... well, the code I copied from xrender.c is a total mess IMHO. Calculating cell deltas and calculating the base line origin has to be done for all kind of TrueType rendering (and most of the stuff for all other text rendering too) so most of it should maybe be put into ExtTextOutW() in gdi/font.c instead of duplicating it all over the place. But I'm not sure if this would require the drv API to be changed (which looks like it's modelled after the Win32 API on purpose) or maybe tie gdi to x11drv. Also from looking at the code it seems to me that the ExtTextOut() implementation in x11drv/text.c behaves - well - different than x11drv/xrender.c in several cases. (TA_*, rotation and break-char handling...) I really don't like the attached code but I don't feel like messing around with it more so I'll just post it here - maybe someone else can use it as a starting-point. -flx ? gdi32.spec.def Index: font.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/font.c,v retrieving revision 1.10 diff -u -r1.10 font.c --- font.c 18 Apr 2005 10:30:56 -0000 1.10 +++ font.c 10 May 2005 23:28:05 -0000 @@ -1719,35 +1719,40 @@ { BOOL ret = FALSE; DC * dc = DC_GetDCUpdate( hdc ); - if (dc) + LPWSTR lpReorderedString = NULL; + + if (!dc) return FALSE; + + if (flags&(ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY)) + FIXME("flags ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY unimplemented\n"); + + if( !(flags&(ETO_GLYPH_INDEX|ETO_IGNORELANGUAGE)) && BidiAvail && count>0 ) { - if (flags&(ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY)) - FIXME("flags ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY unimplemented\n"); + /* The caller did not specify that language processing was already done. */ + DWORD dir = WINE_GCPW_FORCE_LTR; - if(PATH_IsPathOpen(dc->path)) - FIXME("called on an open path\n"); - else if(dc->funcs->pExtTextOut) - { - if( !(flags&(ETO_GLYPH_INDEX|ETO_IGNORELANGUAGE)) && BidiAvail && count>0 ) - { - /* The caller did not specify that language processing was already done. - */ - LPWSTR lpReorderedString=HeapAlloc(GetProcessHeap(), 0, count*sizeof(WCHAR)); - - BIDI_Reorder( str, count, GCP_REORDER, - ((flags&ETO_RTLREADING)!=0 || (GetTextAlign(hdc)&TA_RTLREADING)!=0)? - WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR, - lpReorderedString, count, NULL ); - - ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags|ETO_IGNORELANGUAGE, - lprect,lpReorderedString,count,lpDx,dc->breakExtra); - HeapFree(GetProcessHeap(), 0, lpReorderedString); - } else - ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags,lprect,str,count, - lpDx,dc->breakExtra); - } - GDI_ReleaseObj( hdc ); + if((flags&ETO_RTLREADING)!=0 || (GetTextAlign(hdc)&TA_RTLREADING)!=0) + dir = WINE_GCPW_FORCE_RTL; + + lpReorderedString=HeapAlloc(GetProcessHeap(), 0, count*sizeof(WCHAR)); + + BIDI_Reorder( str, count, GCP_REORDER, dir, lpReorderedString, count, NULL ); + + flags |= ETO_IGNORELANGUAGE; + str = lpReorderedString; } + + if(PATH_IsPathOpen(dc->path)) + ret = PATH_ExtTextOut(dc,x,y,flags,lprect,str,count,lpDx); + else if(dc->funcs->pExtTextOut) + ret = dc->funcs->pExtTextOut(dc->physDev,x,y,flags,lprect,str,count, + lpDx,dc->breakExtra); + + if(lpReorderedString) + HeapFree(GetProcessHeap(), 0, lpReorderedString); + + GDI_ReleaseObj( hdc ); + return ret; } Index: gdi_private.h =================================================================== RCS file: /home/wine/wine/dlls/gdi/gdi_private.h,v retrieving revision 1.25 diff -u -r1.25 gdi_private.h --- gdi_private.h 13 Apr 2005 16:11:18 -0000 1.25 +++ gdi_private.h 10 May 2005 23:28:10 -0000 @@ -405,6 +405,8 @@ extern BOOL PATH_LineTo(DC *dc, INT x, INT y); extern BOOL PATH_Rectangle(DC *dc, INT x1, INT y1, INT x2, INT y2); extern BOOL PATH_Ellipse(DC *dc, INT x1, INT y1, INT x2, INT y2); +extern BOOL PATH_ExtTextOut(DC *dc, INT x, INT y, UINT flags, const RECT *lprec, + LPCWSTR str, UINT count, const INT *lpDx); extern BOOL PATH_Arc(DC *dc, INT x1, INT y1, INT x2, INT y2, INT xStart, INT yStart, INT xEnd, INT yEnd, INT lines); extern BOOL PATH_PolyBezierTo(DC *dc, const POINT *pt, DWORD cbCount); Index: path.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/path.c,v retrieving revision 1.5 diff -u -r1.5 path.c --- path.c 24 Mar 2005 21:01:38 -0000 1.5 +++ path.c 10 May 2005 23:28:13 -0000 @@ -101,6 +101,7 @@ double y, POINT *pPoint); static void PATH_NormalizePoint(FLOAT_POINT corners[], const FLOAT_POINT *pPoint, double *pX, double *pY); +static void PATH_PTFXtoPT(POINT *base_line, POINTFX *ptfx, POINT *pt); static BOOL PATH_CheckCorners(DC *dc, POINT corners[], INT x1, INT y1, INT x2, INT y2); /* Performs a world-to-viewport transformation on the specified point (which @@ -717,6 +718,287 @@ CloseFigure(dc->hSelf) ); } +/* PATH_ExtTextOut + * + * Should be called when a call to ExtTextOut is performed on a DC that has + * an open path. Returns TRUE if successful, else FALSE. + * + * TODO: Check if TA_* handling is correct + */ +BOOL PATH_ExtTextOut(DC *dc, INT x, INT y, UINT flags, const RECT *lprec, + LPCWSTR str, UINT count, const INT *lpDx) +{ + GdiPath *pPath = &dc->path; + HDC hdc = dc->hSelf; + TEXTMETRICW tm; + LOGFONTW lf; + POINT cell_origin, pt; + UINT align, ggo_format = GGO_BEZIER; + INT char_extra, adjust_origin = 0; + const WORD *glyphs; + double cosEsc, sinEsc; + int i, k, *deltas = NULL; + struct + { + POINT origin; + UINT width, height, length; + } baseline; + + /* Windows seems to do nothing and report success on ETO_CLIPPED */ + if(flags & ETO_CLIPPED) + return TRUE; + + /* This is also observed native behaviour */ + if(flags & ETO_OPAQUE) + PATH_Rectangle(dc, lprec->left, lprec->top, lprec->right, lprec->bottom); + + /* Now we do: + * - GetGlyphIndicesW() if !GGO_GLYPH_INDEX + * - Calculate cell deltas considering lpDx, + * GetTextExtentPointI() and breakExtra + * - Calculate width of the text to be rendered + * - Calculate cos/sin of rotation angle + * - Adjust text origin according to GetTextAlign(), + * the rotation angle and the text width + * + * FIXME: All this is also done in x11drv/xrender.c and much of + * it a third time in x11drv/text.c. And this is a mess. + */ + + GetObjectW(GetCurrentObject(hdc, OBJ_FONT), sizeof(lf), &lf); + GetTextMetricsW(hdc, &tm); + + if(flags & ETO_GLYPH_INDEX) + { + /* Nothing to do, input data is already in the right format */ + ggo_format |= GGO_GLYPH_INDEX; + glyphs = (const WORD *)str; + } + else + { + glyphs = HeapAlloc(GetProcessHeap(), 0, count * sizeof(WCHAR)); + GetGlyphIndicesW(hdc, str, count, (WORD*)glyphs, 0); + } + + char_extra = GetTextCharacterExtra(hdc); + if(char_extra || dc->breakExtra) + { + deltas = HeapAlloc(GetProcessHeap(), 0, count * sizeof(INT)); + for(i = 0; i < count; i++) + { + if(lpDx) + deltas[i] = lpDx[i] + char_extra; + else + { + SIZE sz; + GetTextExtentPointI(hdc, glyphs + i, 1, &sz); + deltas[i] = sz.cx; + } + + if(dc->breakExtra && str[i] == tm.tmBreakChar) + deltas[i] += dc->breakExtra; + } + } + else if(lpDx) + deltas = (INT*)lpDx; + + /* calculate length of the base line */ + if(deltas) + { + baseline.length = 0; + for(i = 0; i < count; i++) + baseline.length += deltas[i]; + } + else + { + SIZE sz; + GetTextExtentPointI(hdc, glyphs, count, &sz); + baseline.length = sz.cx; + } + + if(lf.lfEscapement != 0) + { + cosEsc = cos(lf.lfEscapement * M_PI / 1800); + sinEsc = sin(lf.lfEscapement * M_PI / 1800); + } + else + { + cosEsc = 1; + sinEsc = 0; + } + + pt.x = baseline.length * cosEsc; + pt.y = baseline.length * sinEsc; + LPtoDP(hdc, &pt, 1); + baseline.width = pt.x; + baseline.height = pt.y; + + /* GetGlyphOutline will rotate around the base line - we have to + calculate the base line origin from the text origin if we need + another reference point */ + + align = GetTextAlign(hdc); + + if(align & TA_UPDATECP) + FIXME("TA_UPDATECP not implemented\n"); + + baseline.origin.x = x; + baseline.origin.y = y; + LPtoDP(hdc, &baseline.origin, 1); + + switch(align & (TA_LEFT | TA_RIGHT | TA_CENTER)) + { + case TA_LEFT: + break; + + case TA_CENTER: + x -= baseline.width / 2; + y += baseline.height / 2; + break; + + case TA_RIGHT: + x -= baseline.width; + y += baseline.height; + break; + } + + if((align & TA_TOP) == TA_TOP) + adjust_origin = tm.tmAscent; + else if((align & TA_BOTTOM) == TA_BOTTOM) + adjust_origin = tm.tmDescent; + + if(adjust_origin) + { + baseline.origin.x += adjust_origin * sinEsc; + baseline.origin.y += adjust_origin * cosEsc; + + /* FIXME: when using TA_TOP or TA_BOTTOM and rotating by >0 degrees + windows shifts down the text by some px... we'll probably never + know how microsoft screwed up the stuff we did above but this + seems to come close to native behaviour: */ + + if(lf.lfEscapement) + baseline.origin.y += tm.tmHeight / 8; + } + /* -- end of code duplication */ + + cell_origin = baseline.origin; + + /* For each glyph */ + for(i = 0; i < count; i++) + { + char buf[65536], *p; + GLYPHMETRICS metrics; + MAT2 identity = { { 0, 1 }, { 0, 0 }, { 0, 0 }, { 0, 1 } }; /* no transformation */ + + DWORD n = GetGlyphOutlineW(hdc, str[i], ggo_format, &metrics, sizeof(buf), &buf, &identity); + + if(n == GDI_ERROR) + { + WARN("GetGlyphOutline() failed\n"); + return FALSE; + } + + p = buf; + + /* For each contour */ + while(p < buf + n) + { + TTPOLYGONHEADER *header = (void *)(p); + TTPOLYGONHEADER *next = (void *)(p + header->cb); + POINT start, pt; + + PATH_PTFXtoPT(&cell_origin, &header->pfxStart, &start); + PATH_AddEntry(pPath, &start, PT_MOVETO); + + p += sizeof(TTPOLYGONHEADER); + + /* For each curve */ + while(p < (char *)next) + { + TTPOLYCURVE *curve = (void *)p; + BYTE flags; + + if(curve->wType == TT_PRIM_LINE) + flags = PT_LINETO; + else if(curve->wType == TT_PRIM_CSPLINE) + flags = PT_BEZIERTO; + else + { + /* This should not happen since we passed GGO_BEZIER */ + ERR("GetGlyphOutlineW() retrieved TTPOLYCURVE type %d\n", curve->wType); + return FALSE; + } + + /* For each point */ + for(k = 0; k < curve->cpfx; k++) + { + PATH_PTFXtoPT(&cell_origin, &curve->apfx[k], &pt); + PATH_AddEntry(pPath, &pt, flags); + } + + p += sizeof(TTPOLYCURVE) + sizeof(POINTFX) * (curve->cpfx - 1); + } + + /* Close contour if necessary */ + if(pt.x != start.x || pt.y != start.y) + PATH_AddEntry(pPath, &start, PT_LINETO); + } + + if(!deltas) + { + cell_origin.x += metrics.gmCellIncX; + cell_origin.y += metrics.gmCellIncY; + } + else + { + cell_origin.x += deltas[i] * cosEsc; + cell_origin.y += deltas[i] * -sinEsc; + } + } + + if(tm.tmStruckOut || tm.tmUnderlined) + { + OUTLINETEXTMETRICW otm; + + GetOutlineTextMetricsW(hdc, sizeof(OUTLINETEXTMETRICW), &otm); + + if(tm.tmStruckOut) + { + POINT a = { sinEsc * otm.otmsStrikeoutPosition, + cosEsc * otm.otmsStrikeoutPosition }, + b = { a.x - sinEsc * otm.otmsStrikeoutSize, + a.y - cosEsc * otm.otmsStrikeoutSize }, + pts[4] = { { baseline.origin.x - a.x, baseline.origin.y - a.y }, + { baseline.origin.x - b.x, baseline.origin.y - b.y }, + { cell_origin.x - b.x, cell_origin.y - b.y }, + { cell_origin.x - a.x, cell_origin.y - a.y } }; + + PATH_Polygon(dc, pts, 4); + } + + if(tm.tmUnderlined) + { + POINT a = { sinEsc * otm.otmsUnderscorePosition, + cosEsc * otm.otmsUnderscorePosition }, + b = { a.x - sinEsc * otm.otmsUnderscoreSize, + a.y - cosEsc * otm.otmsUnderscoreSize }, + pts[4] = { { baseline.origin.x - a.x, baseline.origin.y - a.y }, + { baseline.origin.x - b.x, baseline.origin.y - b.y }, + { cell_origin.x - b.x, cell_origin.y - b.y }, + { cell_origin.x - a.x, cell_origin.y - a.y } }; + + PATH_Polygon(dc, pts, 4); + } + } + + if(deltas && !lpDx) + HeapFree(GetProcessHeap(), 0, deltas); + + return TRUE; +} + + /* PATH_Arc * * Should be called when a call to Arc is performed on a DC that has @@ -1403,6 +1685,18 @@ 2.0 - 1.0; } +/* PATH_PTFXtoPT + * + * Convert TrueType glyph coordinates (relative to the left side of the + * glyph's base line) into absolute coordinates. + */ + +static void PATH_PTFXtoPT(POINT *base_line, POINTFX *ptfx, POINT *pt) +{ + pt->x = base_line->x + ptfx->x.value + (ptfx->x.fract >= 0x8000 ? 1 : 0); + pt->y = base_line->y - ptfx->y.value - (ptfx->y.fract >= 0x8000 ? 1 : 0); +} + /******************************************************************* * FlattenPath [GDI32.@]

1 0

Re: UT2003 Windowing Regression - Another nights effort...
by Ann and Jason Edmeades 10 May '05

10 May '05

I think I have reproduced the same problem with a simple testpgm... Instructions... 1. Start Visual Studio, create a default windows application 2. Comment out the code in the WM_PAINT and replace it with return 1 (important) 3. Run it... On windows you can play with the menu etc and it works. The CPU is at 100% but clicking on menu items works, and menu->exit does actually exit the app. (Menu->About causes a hang) On wine you get the infinite loop and the screen/menu never gets as far as being drawn Note:Its important to to return the 1 (or TRUE) - returning 0 works fine on both! Question... Is wine being too proactive - Perhaps in the case where the redraw is unsuccessful then wine should schedule a WM_PAINT rather than performing it? Note: UT2003 seems to just do: CreateWindowEx(AppWindow, Visible+..., ) ShowWindow(show no activate) UpdateWindow(rdw all children, updatenow) **hang** Jason

1 0

widl and #pragma pack(x)
by Dietrich Teickner 10 May '05

10 May '05

Can it be, that widl does not work with any #pragma pack(x) statements in any header-files called from *.idl ? I have problems with mshtml.dl in the odin environment. lineno = (int)strtol(yytext, &cptr, 10); if(!lineno) yyerror("Malformed '#...' line-directive; invalid linenumber"); after #pragma pack(x) line. All widl-generated headers does never containn any #pragma pack(x) statement. Dietrich

1 0

Re: Commercial support
by gslink 10 May '05

10 May '05

> IBM does very well know the existents of Wine (they even acknowledged > that by themselves lately), but may very well not support it, because of > inter-relation with MS. As of now (just a guess), they don't want to get > into more hot water right now.... > Would it be to the advantage of Microsoft to have Wine succeed? They have given Apple much support and at every class for the past several years the instructors have had a copy of Linux on every machine. A very good case can be made for Microsoft supporting Wine especially since the RH secure kernel came via NSA and may very well become a DOD standard. Perhaps Wine should formally contact Microsoft.

2 2

Re: README translations
by Marcelo Duarte 10 May '05

10 May '05

Dimi, there are little typos in README.pt_br, see below: Dimitrie O. Paun escreveu: >ChangeLog > Dimitrie O. Paun <dimi(a)lattica.com> > Update README translations to match the latest > changes to the English README. > > > ... >Index: documentation/README.pt_br >=================================================================== >RCS file: /var/cvs/wine/documentation/README.pt_br,v >retrieving revision 1.8 >diff -u -p -r1.8 README.pt_br >--- documentation/README.pt_br 14 Feb 2005 11:51:05 -0000 1.8 >+++ documentation/README.pt_br 10 May 2005 15:12:04 -0000 >@@ -21,9 +21,8 @@ nível do fonte do Wine (que contém este > > Execute programas conforme "wine [opções] programa". Para maiores > informações e resolução de problemas, leia o restante deste arquivo, >-a página "man" do Wine (man wine), os arquivos incluídos no diretório >-de documentação do fonte do Wine (veja "DOCUMENTATION"), e especialmente >-a abundância de informação encontrada em http://www.winehq.org. >+a página "man" do Wine (man wine), o especialmente a abundância de i >+nformação encontrada em http://www.winehq.org. > > here the correct is: "..e especialmente a abundância de informação..." > > 3.REQUERIMENTOS > >@@ -91,9 +90,6 @@ Bibliotecas de suporte opcionais: > Se desejar o suporte de impressão do CUPS, por favor instale os pacotes > cups e cups-devel. > >-Para os requesitos no caso de ter a intenção de contruir a documentação, veja >-a seção "DOCUMENTAÇÃO". >- > 4.COMPILAÇÃO > > No caso de escolher não usar o wineinstall, execute os comandos a seguir >@@ -131,17 +127,7 @@ Não esqueça de desinstalar primeiramente > Wine que possa confitante. Tente qualquer um dos comandos "dpkg -r wine" ou "rpm -e wine" ou "make uninstall" antes de > instalar. > >-Se você quiser ler a documentação fornecida com a fonte do Wine, >-veja a seção "DOCUMENTAÇÃO". >- >-O Wine requer um arquivo de configuração chamado "config" no diretório >-~/.wine. O formato deste arquivo é explicado em "man wine.conf" >-(documentation/wine.conf.man). >-O arquivo documentation/samples/config contém um exemplo de arquivo de >-configuração para ser adaptado e copiado para a localização anteriormente >-mencionada. >- >-Veja a área de suporte em http://www.winehq.org/ para mais sugestões >+Veja a área de suporte em http://www.winehq.org/ para msugestões > sobre a configuraçao. > > here "msugestões" should be "sugestões" Thanks.

1 0

Re: Menu with multi columns fix take 2
by Felix Nawothnig 10 May '05

10 May '05

Rein Klazes wrote: > + case WM_MEASUREITEM: How about an ok( ((MEASUREITEMSTRUCT*)lparam)->itemHeight > 0, ... ) here? :) -flx

2 1

wine wiki syntax question
by James Hawkins 10 May '05

10 May '05

Hey, I have the following in my wiki page: == DONE Items == (./) Use listview instead of listbox in the drive list (./) Fix random bugs with the drives tab listview The first checkmark works, but the second checkmark and text is on the same line and behind the first one. I don't really want the checkmarks to be tabbed like they're in a list, but is there a way to have them on separate lines? -- James Hawkins

1 0

Re: NtQuerySystemInformation #2] Stubbed SystemHandleInformation
by Mike Hearn 10 May '05

10 May '05

On Tue, 10 May 2005 12:00:11 +0200, Paul Vriens wrote: > I added a stubbed SystemHandleInformation that returns nothing for now :-) > I need to find a way to enumerate all the handles in the system, any > ideas? Kernel handles are maintained in the wineservers handle tables: you could add a new request to handle.c and sum up the handles in the global table and all the process tables. thanks -mike

1 0

Re: APPDB: Half-Life and Counter-Strike with WINE
by Hiji 10 May '05

10 May '05

--- "David F. Colwell" <dfcolwell(a)dfcolwell.com> wrote: > Hiji et al, > > Couldn't find Half-Life or Counter-Strike in the DB > yet they returned... > > Submitted version rejected > ------------------------------------------------------- > The version you submitted ( 1.0.0.0) has been > rejected.This application is already in the > database. If you are interested in helping out with > the howto please sign up to be a maintainer of the > application. Thanks. > We appreciate your help in making the Version > Database better for all users. > > Best regards. > The AppDB team > http://www.winehq.org/ > > > I did my part. :-) > On Monday 09 May 2005 7:40 pm, Hiji wrote: > > Any ideas? (I'm forwarding the message, so, it > > defaults to showing below my message. Sorry!) :( --- Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: > I plugged 'half-life' into the search box and got: > > http://appdb.winehq.org/search.php?q=half-life > > Looks like its working here. What did you search > for? > > I just added 'halflife' as a keyword to the > half-life application so searching > for 'halflife' also returns the appropriate results. > > Chris I found it too, but I believe the problem was that he was trying to add a specific version (1.0.0.0), and he got the error. The versions I see on there are 1.1.0.8 and 1.1.1.0 David, can you elaborate for us? Hiji Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html

3 3

UT2003 regression, Windowing problem
by Ann and Jason Edmeades 10 May '05

10 May '05

Hi all, I'm trying to track down a regression which causes UT2003 (and UT2004 / Unreal2 apparently) to fail, and am getting stuck at the windowing level so would appreciate any thoughts as to possible causes. (And no, I haven't tried to work out what regressed it... Why spoil my fun!) Basically we enter RedrawWindow and continually loop because the window in question never gets repainted 'properly'. The window has just been created, and very little has happened on the window other than being activated. A +tid,+win,+msg,+x11drv,+spy (with various extra debug code in) shows: Initial pass into RedrawWindow is via UpdateWindow which forces a redrawnow 0009:fixme:win:UpdateWindow In updateWindow 0009:trace:win:RedrawWindow 0x1002e whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW 0009:fixme:win:RedrawWindow redraw hrgn Because of flags, we insist we redraw the screen now... 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 256 0009:fixme:win:RedrawWindow @@@> Calling.... (We never leave the update_now routine) 0009:fixme:win:update_now Before wait We wait for outstanding painting related events. The window has just been created, so its just a clear of the whole screen from 0009:trace:x11drv:X11DRV_Expose win 0x1002e (3000006) 0,0 648x507 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e B4 Offset into rect (0,0)-(648,507) 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e Offset into rect (-4,-23)-(644,484) 0009:trace:win:RedrawWindow 0x1002e rect (-4,-23)-(644,484) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN RDW_FRAME 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 So the outstanding event was an invalidate of the whole area 0009:fixme:win:update_now After wait 0009:fixme:win:update_now @@> Calling erase 0009:fixme:win:update_now @@> Called erase The infinite for loop 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x40027bec The window needs redrawing 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_PAINT,wp=00000000,lp=00000000) ***> Nothing happens here as a result of the paint? 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e So the invalid region is still set, so its assumed the updates have failed so we schedule a complete erase 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing 0009:fixme:win:update_now 0x1002e region 0x150c box (4,23)-(644,503) In send_erase 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_ERASEBKGND,wp=000014ac,lp=00000000) 0009:trace:win:RedrawWindow 0x1002e rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 0009:fixme:win:send_erase Out send_erase So we loop again... 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x1002e 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg= WM_PAINT,wp=00000000,lp=00000000) ***> Nothing happens here as a result of the paint? Etc etc 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing etc etc So should there have been an action as a result of the WM_PAINT, and is it valid for it not to occur (ie is wine overdoing the assumption on redrawing) Is updatenow correct for an UpdateWindow call (MSDN states a WM_PAINT should be sent, but doesn't say it will check it gets done). Note there are 2 suspicious patches in painting.c both by AJ - (1.19 and 1.20) - The first tries to handle broken WM_PAINT handlers by avoiding the loop, and the 2nd (1.20) just forces the loop to occur! Adding a 'break' in the case where child==prev and a send ncpaint / send erase has occurred avoids the problem, but what is the correct fix Jason

3 2

games
by Ivan Leo Puoti 10 May '05

10 May '05

If you've got a safedisk1 copy protected game please contact me by private email. All safedisk1 games have a .ICD file in the root of the CD. Ivan.

1 0

[Fwd: Re: Commercial support]
by StartCom Ltd. 10 May '05

10 May '05

Or maybe just because of it, there is a need for commercial support, or somebody might need that support. If it would be running, by just clicking on the executable, no support is really needed, at least not for standard applications. IBM does very well know the existents of Wine (they even acknowledged that by themselves lately), but may very well not support it, because of inter-relation with MS. As of now (just a guess), they don't want to get into more hot water right now.... gslink wrote: > Go to the Wine HQ site and click on applications database. If you > need more applications check the listed links. > This is a problem with every development effort and nobody is blaming > anybody. The larger the effort the worse it gets. This is probably > the worst problem both Microsoft and IBM have with code. If you > change anything in Wine something somewhere will probably quit > running. This is simply the price of progress. My comment, and it is > not a criticism, is that Wine still has rough edges. Eventually these > will go away but for now, you can't simply load Wine into Linux and > blindly start loading in applications. The more complex the > application the more likely it needs setup. As versions progress > setup procedures change and as a result things quit running. > Microsoft Office doesn't run without setup and neither do many of the > older games such as Alice or Rune. Even things like Warcraft come and > go. This is not a criticism it is just the way things are and that is > why I think it is too early to start thinking about commercial support. > What somebody needs to do now is to get a relationship with IBM > similar to the one that Eclipse has. IBM has a problem currently > because there is no native Lotus Notes client for Linux. Wine could > easily solve this problem. I talked to some of the marketing managers > in IBM and most had never heard of Wine. The IBM development labs are > currently starting to develop this native client. If IBM could use > Wine it could save them money and sueing Wine is one thing sueing IBM > is another. > > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390 Import StartCom Public CA <http://cert.startcom.org/index.php?app=109>

2 1

Re: [QCAP] patch 4, Adding enumPins object
by Paul Vriens 10 May '05

10 May '05

> Changelog > - dlls/qcap/Makefile.in > - dlls/qcap/enumpins.c > Add IEnumPins object for use by other class objects. This is taken > from quartz with only minor adaptions. > > Rolf Kalbermatter > > > +WINE_DEFAULT_DEBUG_CHANNEL(quartz); Shouldn't that be qcap ? Cheers, Paul.

1 0

Re: Commercial support
by gslink 10 May '05

10 May '05

I recently took the list of applications from headquarters that are listed as running properly and found that many of these are available for little cost. I bought a few and tried to run them. Not a one ran as is from the box. I was able to get all of them to run with some trouble. One big problem I see with Wine is that there is no good testing. As versions progress things quit running and the author has no way of knowing. I have no good solution for this problem but I suspect that it needs attention. It is, of course, part of the documentation problem. It is not in the nature of programmers to document their work.

3 4

Re: dlls/opengl32: fix WGL_ACCELERATION_ARB queries from applications
by Raphael 10 May '05

10 May '05

On Monday 09 May 2005 11:09, Aric Cyr wrote: > Just a small patch to Raphael's recent CVS commit which added a much > better wglChoosePixelFormatARB() and friends. This patch fixes the > return values that an application will recieve when it queries the > WGL_ACCELERATION_ARB pixel format attribute. good catch :) Regards, Raphael

2 1

Re: Make test status - latest CVS
by Juan Lang 10 May '05

10 May '05

--- Shachar Shemesh <wine-devel(a)shemesh.biz> wrote: > >I don't see the same thing here. Could you send me a heap trace? > > > Aw, man! You were sitting right behind me when that happened. Couldn't > you have taken my laptop and debugged it on the spot then? :-) I wanted to have a chance to run it, read over the code, etc. I'm afraid I don't see the problem still. Maybe a storage,heap trace? --Juan __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

APPDB: Half-Life and Counter-Strike with WINE
by Hiji 09 May '05

09 May '05

Any ideas? (I'm forwarding the message, so, it defaults to showing below my message. Sorry!) :( Note: forwarded message attached. __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

2 1

Window management - what to do next?
by Vitaliy Margolen 09 May '05

09 May '05

Ok, I've been digging this stuff for more then a week now. And I still don't have even a partial understanding of what's going on in there. If someone please explain me these: 1. Where wine stops and passing over to X/window manager? I'm most interested in handling focus changes, minimize/maximize/restore. 2. What are we doing about properly implementing minimize/maximize/restore. Here is what I uncovered so far about SetWindowPos: 1. Wine does not send WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED. 2. Wine does not redraw owner/owned windows (or not in a proper order) when z-order changes. It looks like these heavily depend on focus changes and owner/owned windows relations. Some times native redraws both owner and owned windows. Sometimes none at all. Same goes for messages. I'm kind of stuck here. To go any further I need to know what part should we delegate to WM and what part do ourselves. -- Best regards, Vitaliy

2 1

Regression in start wars jedi knight: jedi academy
by Stefan Dösinger 09 May '05

09 May '05

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:77d00000 EBX:77ef6d8c ECX:77efdb1c EDX:00110000 ESI:77cfff70 EDI:77c3bcb0 Stack dump: 0x77a7e588: 77a7e5c4 77ec198f 77bf0000 77efdb1c 0x77a7e598: 77ec221d 77ef6d8c 00000848 77c3b460 0x77a7e5a8: 77a7e5c4 77ec14a6 77bf0000 77c3bcb0 0x77a7e5b8: 000c42c0 77c3b460 77c3b468 77a7e61c 0x77a7e5c8: 77ec2c3e 77bf0000 77c3b460 00000848 0x77a7e5d8: 00000001 77a7e5ec 77ec2e40 77bf001c Backtrace: =>1 0x77ec1139 HEAP_CreateFreeBlock+0x69(subheap=0x77bf0000, ptr=0x77c3bcb0, size=0xc42c0) [heap.c:447] in ntdll (0x77a7e5a8) 2 0x77ec14a6 HEAP_ShrinkBlock+0x56(subheap=0x77bf0000, pArena=0x77c3b460, size=0x848) [heap.c:543] in ntdll (0x77a7e5c4) 3 0x77ec2c3e RtlReAllocateHeap(heap=0x77bf0000, flags=0xa, ptr=0x77c3a5a8, size=0x848) [heap.c:1348] in ntdll (0x77a7e61c) 4 0x77b33774 HeapReAlloc(heap=0x77bf0000, 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=0xffffffff, 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) (0x0000001f) 18 0x00000000 (0x00000000) 0x77ec1139 HEAP_CreateFreeBlock+0x69 [heap.c:447] in ntdll: movl 0x0 (%esi),%ecx Unable to open file 'heap.c' Modules: Module Address Debug info Name (70 modules) PE 0x00400000-01327000 Export jamp PE 0x10000000-100f2000 Deferred openal32 ELF 0x712fc000-71376000 Deferred libglu.so.1 ELF 0x71376000-71410000 Deferred opengl32<elf> \-PE 0x713b0000-71410000 \ opengl32 ELF 0x71a5b000-71a70000 Deferred midimap.drv<elf> \-PE 0x71a60000-71a70000 \ midimap.drv ELF 0x71b8c000-71bb0000 Deferred msacm32<elf> \-PE 0x71b90000-71bb0000 \ msacm32 ELF 0x71bb0000-71bc9000 Deferred msacm.drv<elf> \-PE 0x71bc0000-71bc9000 \ msacm.drv ELF 0x71bc9000-71c0e000 Deferred wineoss.drv<elf> \-PE 0x71be0000-71c0e000 \ wineoss.drv ELF 0x71c5b000-71c7a000 Deferred imm32<elf> \-PE 0x71c60000-71c7a000 \ imm32 ELF 0x71c7a000-71c7e000 Deferred iso8859-1.so ELF 0x71c85000-71ca2000 Deferred ximcp.so.2 ELF 0x71ca2000-71ca5000 Deferred xlcdef.so.2 ELF 0x71ca5000-71cae000 Deferred libxcursor.so.1.0.2 ELF 0x71cae000-71cb6000 Deferred libxrender.so.1 ELF 0x761e5000-761ed000 Deferred libgcc_s.so.1 ELF 0x761ed000-76201000 Deferred librt.so.1 ELF 0x762d5000-76b65000 Deferred fglrx_dri.so ELF 0x76b65000-76c09000 Deferred libgl.so.1 ELF 0x76c09000-76cd4000 Deferred libx11.so.6 ELF 0x76dd4000-76df6000 Deferred libexpat.so.0 ELF 0x76df6000-76e20000 Deferred libfontconfig.so.1 ELF 0x76e20000-76e34000 Deferred libz.so.1 ELF 0x76e4e000-76ecf000 Deferred libfreetype.so.6 ELF 0x76ecf000-76ef9000 Deferred ws2_32<elf> \-PE 0x76ee0000-76ef9000 \ ws2_32 ELF 0x76ef9000-76f16000 Deferred wsock32<elf> \-PE 0x76f00000-76f16000 \ wsock32 ELF 0x76f16000-76f36000 Deferred iphlpapi<elf> \-PE 0x76f20000-76f36000 \ iphlpapi ELF 0x76f36000-76f80000 Deferred rpcrt4<elf> \-PE 0x76f50000-76f80000 \ rpcrt4 ELF 0x76f80000-7700e000 Deferred ole32<elf> \-PE 0x76fa0000-7700e000 \ ole32 ELF 0x7700e000-7704e000 Deferred advapi32<elf> \-PE 0x77020000-7704e000 \ advapi32 ELF 0x7704e000-770dd000 Deferred gdi32<elf> \-PE 0x77060000-770dd000 \ gdi32 ELF 0x770dd000-7720f000 Stabs user32<elf> \-PE 0x77100000-7720f000 \ user32 ELF 0x7720f000-77290000 Deferred winmm<elf> \-PE 0x77220000-77290000 \ winmm ELF 0x77ad8000-77bf0000 Stabs kernel32<elf> \-PE 0x77b00000-77bf0000 \ kernel32 ELF 0x77d09000-77d13000 Deferred libnss_files.so.2 ELF 0x77d13000-77d1d000 Deferred libnss_nis.so.2 ELF 0x77d1d000-77d32000 Deferred libnsl.so.1 ELF 0x77d32000-77d3b000 Deferred libnss_compat.so.2 ELF 0x77d55000-77d78000 Deferred libm.so.6 ELF 0x77d78000-77e6d000 Deferred libwine_unicode.so.1 ELF 0x77e87000-77f00000 Stabs ntdll<elf> \-PE 0x77ea0000-77f00000 \ ntdll ELF 0x77f00000-77f03000 Deferred <wine-loader> ELF 0x77f41000-77f4f000 Deferred libxext.so.6 ELF 0x77f4f000-77f54000 Deferred libxxf86vm.so.1 ELF 0x77f54000-77f5a000 Deferred libxxf86dga.so.1 ELF 0x77f5a000-77f72000 Deferred libice.so.6 ELF 0x77f72000-77f7b000 Deferred libsm.so.6 ELF 0x77f7b000-78000000 Deferred x11drv<elf> \-PE 0x77f90000-78000000 \ x11drv ELF 0xb7e47000-b7e4b000 Deferred libdl.so.2 ELF 0xb7e4b000-b7f62000 Deferred libc.so.6 ELF 0xb7f62000-b7fb4000 Deferred libpthread.so.0 ELF 0xb7fb4000-b7fcd000 Deferred libwine.so.1 ELF 0xb7fe8000-b8000000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) G:\jedi academy\GameData\jamp.exe 00000009 0 <== WineDbg terminated on pid 0x8

3 6

[Fwd: [Bug 2931] Diablo 2 video test fails]
by Dustin Navea 09 May '05

09 May '05

Bug 2931 is a regression, and we have found the patch which causes it. It is attached to the bug, and I have requested a link to the commit email, so that the appropriate person can know to take a look. Thanks Dustin -------- Original Message -------- Subject: [Bug 2931] Diablo 2 video test fails Date: Mon, 9 May 2005 03:30:31 -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=2931 ------- Additional Comments From rmh(a)debian.org 2005-09-05 03:30 ------- Got it. The commit that broke wine was done between 23:45 and 23:59 (i'm not sure wether UTC or my timezone, UTC+2). I don't need to track it down to the last second because this is the only commit in that interval (made by julliard). The patch that caused this regression is attached. I've verified that the patch can be reverted cleanly on current CVS, and once reverted wine works again for the Diablo 2 installer. -- 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.

1 0

Re: [OpenGL] Fwd: Re: Regression in Half life
by Jesse Allen 09 May '05

09 May '05

On 5/9/05, Raphael <fenix(a)club-internet.fr> wrote: > > while Waiting for a better idea: > > Changelog: > - fix x11drv/ChoosePixelFormat to choose 24 bpp as 32 bpp for depth buffers > (needed as many X11 drivers only support 24bpp) > > Regards, > Raphael > Are there any drivers that don't have 24 bpp but have 32 bpp instead? I think I remember seeing that before.

1 0

Wiki stuff
by Mike Hearn 09 May '05

09 May '05

Hi, It seems some users have started creating pages that are simply intended to dupe the appdb: http://wiki.winehq.com/Running_Errors http://wiki.winehq.com/WindowsGames I doubt it makes any sense to have this sort of info on the wiki. What do others think? thanks -mike

3 5

Re: [?? Probable Spam] notepad: add .LOG feature
by Dmitry Timoshkov 09 May '05

09 May '05

"Kevin Koltzau" <kevin(a)plop.org> wrote: > See http://support.microsoft.com/?kbid=260563 > > Changelog > Handle notepad log feature > + /* If the file starts with .LOG, add a time/date at the end and set cursor after > + * See http://support.microsoft.com/?kbid=260563 > + */ > + if (GetWindowTextW(Globals.hEdit, log, sizeof(log)/sizeof(log[0])) && !lstrcmp(log, dotlog)) Shouldn't it be a case insensitive comparison, i.e. does ".log" work as well? -- Dmitry.

2 1

Commercial support
by gslink 09 May '05

09 May '05

I wouldn't worry about anyone but Microsoft stealing Wine. In order to develop Wine you must be an expert C++ programmer. That requires an enormous amount of work and thieves are usually lazy. A new teacher came to the master. "I have developed some new techniques that make teaching much better." "How can I prevent other teachers from stealing them?" "Your worry is needless", replied the master. "If your techniques are any good you will have to force others to use them." With that the master threw an eraser at him. The same can be said about Wine and Microsoft.

3 3

qcap
by Maarten Lankhorst 09 May '05

09 May '05

this is my qcap dll in its current state, because i dont have much time in the next couple of weeks I' d thought I'd post it, perhaps someone can make it work with the new qcap dll implementation, what i have here is a pretty much complete version of qcap + a near complete version of V4l implementation (if i recall correctly, only YUV formats are missing now.. and V4L2 support but I'm *NOT* going to add that anyway) What files need to be added for vfwcapture? enumpins.c, media.c, null.c, pin.c, v4l.c, vfwcapture.c (+ perhaps some headers..) although julliard doesn't like copying media.c, enumpins.c and pin.c from quartz, it was the only way to make it work.. (I'm still not sure if he believes me though..) I tested this stuff by using msn webcam settings, if you want to transmit to someone else, you need a native version of msvfw32, else it won't work bonus points if you make this work through the wine driver model (dlls/winmm?), and write a patch for avicap32 to use winmm too (at least for capgetdriverdescription), I don't know how wine drivers work but you could try it. (I hope julliard allows the first version to use V4l in qcap..) If there are questions just ask.. I'm off to study for the big exams now.. Maarten

1 0

Revisiting exceptions
by Mike Hearn 09 May '05

09 May '05

Hi Alexandre, I got bored and took a stab at doing proper SEH macros using some GCC extensions I found. These are rather rough, unfinished definitions, and they aren't tested at all but do they look OK? thanks -mike static void __wine_frame_cleanup( __WINE_FRAME *wineframe ) { __wine_pop_frame(&wineframe->frame); } #define __TRY \ { \ __label__ __frame_label; \ __WINE_FRAME __f __attribute__((cleanup(__wine_frame_cleanup))); \ if (0) { \ __frame_label: #define __EXCEPT(func) \ } \ else { \ __f.frame.Handler = __wine_exception_handler; \ __f.u.filter = (func); \ __wine_push_frame( &__f.frame ); \ goto __frame_label; \ } \ }

7 11

Re: winecfg: Add wine configuration tab
by Alexandre Julliard 09 May '05

09 May '05

James Hawkins <truiken(a)gmail.com> writes: > This seemed to get pretty good support in wine-devel. The rest of the > implementation will follow soon. You really only want the dir symlink and hidden file options, and these should most likely be under the Drives tab. It doesn't make sense to let users edit the Windows or System dir, this will break everything. And there's no point in having a "wine" tab, all options in winecfg are about Wine anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Re: Regression in Half life
by fenix＠club-internet.fr 09 May '05

09 May '05

Hi, <snip> >Uh, no, this doesn't help :-( > >Half-life supports only 16bpp(well, I can set it to other values with regedit, >but it seems to have no effect), fglrx supports 24bpp only. No problem here. >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 <snip> > - Depth : 32 <---- Is half-Life still trying to get 32bpp????? Yes, but not 32bpp for frame buffer only for depth buffer (usually Z-buffer) >But even if it worked this way, this wouldn't be a good solution for ATI >users, because playing newer games with the "radeon" driver is horrible. >(e.g. Jedi Academy, gl-117, even tuxracer makes problems). > >Removing the failing check from Wine's opengl code doesn't help, it causes a >hard crash later. Yes because game expect 32bpp for Depth buffer and if game try to read directly into this buffer you'll have some problems Regards, Raphael

3 3

Commercial support
by gslink 09 May '05

09 May '05

I wonder if it isn't a little early to consider the entire issue of commercial support. Most programs do not run under Wine without some sort of setup and things written to XP standards don't run at all. The project hasn't gotten to the 1.0 level yet. The project is coming along very well and sometime in the future will reach a 1.0 level. Might it not be time to consider things like this when the project has progressed a little further. I believe the project could better spend this effort publicizing Wine to groups such as the Smalltalk community. It could be a great help there and in other communities like it. The more involvement the faster Wine will reach the 1.0 level.

2 1

Assertion fails in riched20; relay debug segfaults
by Adrian Harvey 09 May '05

09 May '05

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 fffffdfa, flags 4! err:ole:ITypeInfo_fnInvoke did not find member id fffffdfb, 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

4 8

Quicken/CreateCompatibleBitmap issue revisited
by Carl Sopchak 09 May '05

09 May '05

In the bug found at http://bugs.winehq.org/show_bug.cgi?id=2096 , I have described an issue that I am having with Quicken Deluxe 2000 when running under Wine. The symptom is that Quicken was crashing HARD when trying to print a partial page of checks on a laser printer. Now, I just get fixme's stating that CreateCompatibleBitmap is getting bad parameters. (In lieu of reading the following, you could probably just read the last few posts in bugzilla for this bug...) Long story short, with the help of some others (thanks guys!), it seems that CreateCompatibleBitmap is being called directly from Quicken, and that Quicken seems to be passing an address instead of a value for the height parameter. Now, I would normally just mark the bug as INVALID, and let it go. But, while looking into things, I read the MSDN page describing the function of CreateCompatibleBitmap, and it appears to me that there may be "issues" with Wine's implementation of CreateCompatibleBitmap. To quote my post attached to the bug: "I would have changed this bug entry's resolution to INVALID, except that (a) I wouldn't mind a more knowledgeable (of Wine, Win API, and C) person to verify my findings, and, more importantly, (b) it seems to me that Windows would be handling this scenario differently than Wine (or Intuit/Quicken would have some customer relations problems due to frequent crashes) - should Wine do something different when the parameters are out of whack? The only thing I can see on MSDN under CreateCompatibleBitmap is "Windows 95/98/Me: The created bitmap cannot exceed 16MB in size." "Which I guess brings up another point... dlls/gdi/bitmap.c's CreateCompatibleBitmap shows the aforementioned fixme message if the width or height exceeds 0x10000, and no bitmap is returned. This seems wrong to me on three counts: (1) MSDN states that if either width or height is zero, a 1x1 monochrome bitmap is returned (in my case the height was 0, but the width was "huge", so a 1x1 bitmap should be returned); (2) a 0x11000 by 0x2 bitmap is within the (more restrictive Win95) 16 MB limit and should be valid; and (3) Win NT/2000/XP do not seem to have any restriction on a bitmap's size (except physical and paged memory constraints), so at least in theory, any values for width and height are "valid". So, this begs the question, should Wine's CreateCompatibleBitmap be modified for any (or all?) of the reasons above? Thoughts? Comments? Carl

3 3

Bugs out of my league
by Dustin Navea 08 May '05

08 May '05

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

1 0

Now hiring
by Dustin Navea 08 May '05

08 May '05

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 inverseparadox(a)comcast.net? 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

2 2

LockDIBSection problem
by Rein Klazes 08 May '05

08 May '05

Hi, Here is another problem in BigJig a jigsaw puzzle game (free download at www.lenagames.com). The program calls BitBlt with destination an in memory DIB. Inside BitBlt, the destination bits are set to PAGE_NOACCESS: | 0009:Call kernel32.VirtualProtect(727f0000,00123324,00000001,77a5f7bc) ret=770032ba | 0009:Call ntdll.NtProtectVirtualMemory(ffffffff,77a5f69c,77a5f6a0,00000001,77a5f7bc) ret=77b6929e | trace:virtual:NtProtectVirtualMemory 0xffffffff 0x727f0000 00123324 00000001 | trace:virtual:VIRTUAL_SetProt 0x727f0000-0x72913fff c---- | View: 0x727f0000 - 0x72913fff (valloc) | 0x727f0000 - 0x72913fff c---- | 0009:Ret ntdll.NtProtectVirtualMemory() retval=00000000 ret=77b6929e This memory segment (727f0000,00123324) does not appear in the log anymore until it is written to disk: | 0009:Call kernel32.WriteFile(00000084,727f0000,00123324,77a5f360,00000000) ret=00408ac1 .. The call fails ( not in the log because I fixed it) with error STATUS_INVALID_USER_BUFFER and the program hangs. 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? Rein.

2 2

Re: ignore requested height for non-menubar ownerdraw popups
by Rein Klazes 08 May '05

08 May '05

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 ================== 96 16 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.

2 2

wineconsole exits immediately (Wine 20050310 debian sarge/testing)
by J. Grant 08 May '05

08 May '05

Hello, I was trying to run wcmd, it seems to have been renamed wineconsole. However, unfortunately it exits immediately before producing a DOS command prompt in my terminal like wcmd used to. I think this is a bug, (unless I missed something). $ wineconsole Invoking /usr/lib/wine/wine.bin wineconsole.exe ... Wine exited with a successful status $ I thought that maybe there was an argument I needed to pass, but there isn't a man page, or command line --help /? help unfortunately at present. $ wineconsole --help Invoking /usr/lib/wine/wine.bin wineconsole.exe --help ... err:wineconsole:WinMain Wrong command line options Wine exited with a successful status $ wineconsole /? Invoking /usr/lib/wine/wine.bin wineconsole.exe /? ... Wine exited with a successful status $ I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

3 7

Wine -> WineHQ -> codeweavers
by Derzu 08 May '05

08 May '05

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

2 1

Re: [DInput] Fix 'peek' code for mouse (S3 problem)
by Stefan Dösinger 08 May '05

08 May '05

Am Mittwoch, 4. Mai 2005 20:44 schrieb Lionel Ulmer: > This should fix the mouse issue in S3. > > Lionel > > Changelog: > - do not flush the buffer when the application only wants to peek the > number of elements in the queue > - trace the GetDeviceState values before they are reset No, saidly, it doesn't. I have attached a +dinput log again. Stefan

2 10

Re: ignore requested height for non-menubar ownerdraw popups
by Rein Klazes 08 May '05

08 May '05

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.c 19 Apr 2005 09:47:02 -0000 1.26 > +++ menu.c 8 May 2005 09:09:06 -0000 > @@ -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.

1 0

Stable release builds with fixme output (Wine 20050310 debian sarge/testing)
by J. Grant 08 May '05

08 May '05

Hello, 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? fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

3 3

Re: portability improvements for wineshelllink script
by Dan Kegel 08 May '05

08 May '05

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

1 0

[patch] fix delete key on certain european keyboards
by zhilla 08 May '05

08 May '05

reposting this here, looking for someone to fix a long standing wine bug. text [edited] again: well, this is just this: http://bugs.winehq.org/show_bug.cgi?id=2400 and should apply to today's cvs. i AM NOT the author! it IS kinda urgent, since a lot of european keyboards are affected... like hungarian, croatian, slovenian... all have "delete" key producing "<delete>," instead of "<delete>". this patch is just a "works here" workaround, see url for more details. i got response from some people, so i fixed comments, but what needs to be tuned, according to mr. Dmitry Timoshkov, is that it should use symbolic key(sym) names instead of hardcoded numbers. seems like a trivial task for a programmer (which i am not) so, anybody up to it? Changelog: * dlls/x11drv/keyboard.c Arpad Biro <biro_arpad(a)yahoo.com> (modified to current cvs by Marin Glibic <zhilla(a)spymac.com>) This fixes the problem is that when NumLock is active, both Del keys perform a "delete" action _and_ insert a comma (the decimal character). --- dlls/x11drv/keyboard.c.orig 2005-05-05 23:33:23.000000000 +0200 +++ dlls/x11drv/keyboard.c 2005-05-05 23:38:44.000000000 +0200 @@ -1067,11 +1067,14 @@ else XLookupString(e, NULL, 0, &keysym, NULL); - if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF) - && (e->state & NumLockMask)) - /* Only the Keypad keys 0-9 and . send different keysyms - * depending on the NumLock state */ - return nonchar_key_vkey[keysym & 0xFF]; + if (e->state & NumLockMask) /* NumLock is active */ + { if (keysym == 0xFFAC) /* Numeric Del pressed */ + return keyc2vkey[0x3B]; /* comma */ + if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF)) + /* Only the Keypad keys 0-9 and . send different keysyms + * depending on the NumLock state */ + return nonchar_key_vkey[keysym & 0xFF]; + } TRACE_(key)("e->keycode = %x\n", e->keycode);

1 0

Stack size allocations
by Robert Lunnon 07 May '05

07 May '05

I wish to propose two changes that I currently have in my Solaris patchkit. I'll use two separate e-mails here to avoid confusion. Both changes add environment variables controlling the way wine does things. The first patch addresses a problem I have found where Windows applications under wine exceed the allocated stack. By default wine allocates the same 1MB stack that windows does but wine has a different stack consumption that does windows, adding the wine translation layers, possibly OGL then X calls on top of this. The following patch allows an environment variable WINE_STACK to redefine the minimum stack to give applications and to add extra stack to that declared in the executables header to allow for additional stack consumption. Currently it works like this if WINE_STACK is not set the default semantics are used just like wine does today if WINE_STACK is set then wine allocates the maximum of the value given in the WINE_STACK env var or 1MB. 25% of the value specified in WINE_STACK is added to the value declared in the applications executable header to provide more headroom for wine/X calls. Please excuse the primitive debugging included for now, it'll have to be removed for primetime. Comments anyone ? Index: dlls/ntdll/thread.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/thread.c,v retrieving revision 1.26 diff -u -3 -p -r1.26 thread.c --- dlls/ntdll/thread.c 27 Apr 2005 08:18:20 -0000 1.26 +++ dlls/ntdll/thread.c 6 May 2005 21:21:30 -0000 @@ -25,7 +25,7 @@ #ifdef HAVE_SYS_MMAN_H #include <sys/mman.h> #endif - +#include <stdio.h> #include "ntstatus.h" #include "thread.h" #include "winternl.h" @@ -221,6 +221,9 @@ NTSTATUS WINAPI RtlCreateUserThread( HAN ULONG size; int request_pipe[2]; NTSTATUS status; + unsigned long stack_min=1024*1024; + unsigned long stack_overhead=0; + char stack_mul=0; if( ! is_current_process( process ) ) { @@ -273,23 +276,67 @@ NTSTATUS WINAPI RtlCreateUserThread( HAN MEM_SYSTEM, PAGE_EXECUTE_READWRITE ); info->pthread_info.teb_size = size; info->pthread_info.teb_sel = teb->teb_sel; - + + + /* Allocate the stack: + Allow the user to set an environment variable to specify the stack size + WINE_STACK, allow the user to use multiplier notation + eg K for kilobyts or M for Megabytes or M + example WINE_STCK=2048K or WINE_STACK=2M bithe specify 2 Megabytes + */ + + if(getenv("WINE_STACK")) { + sscanf(getenv("WINE_STACK")," %lu%c ",&stack_min,&stack_mul); + fprintf(stderr,"Got stack spec of %lu %c bytes from environment",stack_min,stack_mul); + } + + switch (stack_mul) { + case 'm': + case 'M': + stack_min=stack_min*1024*1024; + stack_overhead=stack_min/4; + break; + case 'b': + case 'B': + stack_overhead=stack_min/4; + break; + case 'k': + case 'K': + stack_min=stack_min*1024; + stack_overhead=stack_min/4; + break; + + default: + stack_min=1024*1024; + stack_overhead=0; + break; + } + + stack_min=max(stack_min,1024*1024); + fprintf(stderr,"Minimum Stack Set to %lu overhead allowance = %d\n",stack_min,stack_overhead); + /* Get the stack size recommendation from the program prefix (Executible header) + Because this is not "real windows" we have additional stack overheads particularly in xlib + where the user has specified a stack requirement (IE VIA WINE_STACK) add 25% of the minimum + stack over and above the value in the header to allow for this + */ if (!stack_reserve || !stack_commit) { IMAGE_NT_HEADERS *nt = RtlImageNtHeader( NtCurrentTeb()->Peb->ImageBaseAddress ); - if (!stack_reserve) stack_reserve = nt->OptionalHeader.SizeOfStackReserve; + if (!stack_reserve) stack_reserve = nt->OptionalHeader.SizeOfStackReserve+stack_overhead; if (!stack_commit) stack_commit = nt->OptionalHeader.SizeOfStackCommit; } if (stack_reserve < stack_commit) stack_reserve = stack_commit; stack_reserve = (stack_reserve + 0xffff) & ~0xffff; /* round to 64K boundary */ - if (stack_reserve < 1024 * 1024) stack_reserve = 1024 * 1024; /* Xlib needs a large stack */ + if (stack_reserve < stack_min) stack_reserve = stack_min; /* Xlib needs a large stack */ info->pthread_info.stack_base = NULL; info->pthread_info.stack_size = stack_reserve; info->pthread_info.entry = start_thread; info->entry_point = start; info->entry_arg = param; - + + fprintf(stderr,"Allocated thread at %lx Allocated stack of %lu Bytes\n",stack_commit,stack_reserve); + if (wine_pthread_create_thread( &info->pthread_info ) == -1) { status = STATUS_NO_MEMORY;

4 6

Re: Solaris Compatibility -dlls/wineps/driver.c
by Alexandre Julliard 07 May '05

07 May '05

Robert Lunnon <bobl(a)optushome.com.au> writes: > Notes about patch: > PAGESIZE is a risky name for a symbol since it an obvious candidate for use to > define the page size of the OSes VM pages and in fact does Collide under > Solaris We already have a #undef PAGESIZE to work around that problem. If it doesn't work you probably need to tweak the include files order. -- Alexandre Julliard julliard(a)winehq.org

2 1

Bug 2905
by Dustin Navea 07 May '05

07 May '05

Can someone take a look at the attached debug output and let me know what might be the problem? The game crashes under wine, regardless of the winver (could be an old wine version), and also under real Win2k, but not under real Win98.. I doubt there is much hope for getting this working, since it even crashes in Win2k, but since it's reported, I should go ahead and report it to you all anyways.

1 0

Re: Solaris compatibility - libs/wine/loader.c
by Alexandre Julliard 07 May '05

07 May '05

Robert Lunnon <bobl(a)optushome.com.au> writes: > Notes about patch: > Solaris requires RTLD_FIRST flag to dlopen calls to resolve multiple path > expansions properly This doesn't seem to be what RTLD_FIRST does. Could you explain a bit more exactly what the problem is? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: portability improvements for wineshelllink script
by Francois Gouget 07 May '05

07 May '05

On Sat, 7 May 2005, Robert Lunnon wrote: [...] > # diff -u wineshelllink.old wineshelllink > --- wineshelllink.old mer mai 4 11:47:30 2005 > +++ wineshelllink mer mai 4 11:50:03 2005 > @@ -1,4 +1,4 @@ > -#!/bin/sh > +#!/bin/bash This is wrong. Some users may not have bash installed and the script should still work on their systems. So the fix is not to make the script fail to run on any system which does not have bash but to modify it so it works with any standard Bourne shell, including the Solaris one. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

3 4

16 bit hwnd in SendmessageA/W
by Rein Klazes 07 May '05

07 May '05

Hi, Another case where I don't think I know enough of the finer details for a correct solution. MS Visual C++ 1.5 IDE - 16 bit win application - communicates its window handle to WINTEE32.EXE - win32 app - to handle the build process: >> E:\\MSVC\\BIN\\WINTEE32.EXE -h2a -vn 5e is the 16 bit window handle. Here it sends data to the IDE: >> 0035:Call user32.SendMessageA(ffff002a,0000004a,0008004a,77a3fe28) ret=77a51649 That does not work, SendMessageA does only expect full 32 bit win handles. Things work with this patch: ========================================================================== --- wine/dlls/user/message.c 2005-05-05 10:26:28.000000000 +0200 +++ mywine/dlls/user/message.c 2005-05-05 20:07:46.000000000 +0200 @@ -2388,6 +2388,13 @@ LRESULT WINAPI SendMessageTimeoutA( HWND return 1; } + /* if it is not a 32bit window handle */ + if( !IsWindow( hwnd)) { + /* try if it is a 16 bit handle */ + hwnd = WIN_Handle32( (HWND16) hwnd ); + info.hwnd = hwnd; + } + if (!(dest_tid = GetWindowThreadProcessId( hwnd, &dest_pid ))) return 0; if (USER_IsExitingThread( dest_tid )) return 0; ========================================================================== Is anything else needed, I wonder? Rein.

3 4

Re: Enummedia memleak fix
by Alexandre Julliard 07 May '05

07 May '05

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > Fixed 2 small memory leaks in enummedia (my fault, not used to while > loops..) > > Note that there are 2 ways to fix it: > while (--i) .. -> while (i--) .. > while (--i) .. -> while (--i >= 0) .. > > I chose the second, but I don't think it matters ;) In that case it matters a lot, since i is unsigned... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winecfg: Match the new way to use unixfs
by Mike Hearn 07 May '05

07 May '05

On Sat, 2005-05-07 at 09:46 +0200, Michael Jung wrote: > P.S.: What's the reason for disabling the i18n resources in > winecfg.rc? They're out of date and don't reflect the current English GUI. thanks -mike

1 0

Support for multiple threading models
by Robert Lunnon 07 May '05

07 May '05

Some time ago, I wrote code to support native threads instead of lwp for SYSV operating systems, the way I wrote the code all available threading models were compiled into wine and the actual one to be used was selected by setting an environment variable. (Currently WINE_THREADMODE). On OSes that support multiple threading methods, IE Solaris and probably the BSDs this allows for easy development and testing of thread support. It also allows the simulation of no thread support (Not that that seems to be very useful). Originally when I wrote this Solaris 9 was having some problems with crashing in mutexes if native threads were used, but LWPs weren't perfect either, in particular lwps aren't necessarily safe to use with some libraries (There is a warning about this in the Man pages for the _lwp calls, For example. this caused problems with alarm/usleep calls used at the time in winmm). These days however in Solaris 10 the native thread code works quite well. Anyway the fallout was that non winmm code worked best using native threads on certain Solaris MUs and winmm dependent programs worked best using LWPs and having the Threading model selectable made sense. This is still the case for Solaris 8/9 users. I can still see situations where it would be advantageous to be able to select the threading model at runtime and I'd like to leave this support in (Solaris 9 for example). This possibility has received a luke warm reception before but I thought I'd re-raise the possibility now while I'm doing the putback from my latest patch kit. Just as a final point Solaris no longer supports _lwp_create calls, without this patch wine is unable to run on Solaris versions > Solaris 9 Bob Threading patch attached

1 0

Re: [resend] [patch] fix delete key on certain european keyboards
by Dmitry Timoshkov 07 May '05

07 May '05

"zhilla" <zhilla(a)spymac.com> wrote: > ok, this is 3rd time, damn :) this time against wine cvs root, and with, > i hope, fixed comments. > - if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF) > - && (e->state & NumLockMask)) > - /* Only the Keypad keys 0-9 and . send different keysyms > - * depending on the NumLock state */ > - return nonchar_key_vkey[keysym & 0xFF]; > + if (e->state & NumLockMask) /* NumLock is active */ > + { if (keysym == 0xFFAC) /* Numeric Del pressed */ > + return keyc2vkey[0x3B]; /* comma */ > + if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF)) > + /* Only the Keypad keys 0-9 and . send different keysyms > + * depending on the NumLock state */ > + return nonchar_key_vkey[keysym & 0xFF]; > + } > > TRACE_(key)("e->keycode = %x\n", e->keycode); If you could also use symbolic key(sym) names instead of hardcoded numbers the patch would have better chances to be accepted. -- Dmitry.

1 0

re: Winelib's role in converting Windows applications
by Daniel Kegel 07 May '05

07 May '05

Ira Krakow (ikrakow_1999(a)yahoo.com) wrote: > At Wineconf, I had a number of conversations about > Winelib's role in converting Windows apps. The > consensus seems to be that the most efficient > conversion path is for much of the Windows app to stay > in Visual C++ (or whatever) and that only the modules > that specifically require native Linux calls should be > recompiled, via MinGW/Dev-C++ on the Windows side, and > Winemaker on the Linux side, into Winelib objects. > > For example, if the application requires PAM > authentication, or a Linux-based help system, these > modules would be separated out and encapsulated as > Winelib objects. I was thinking of using PAM > authentication as a good example, since it works for > any authentication scheme that the application > requires. There are two other reasons to use winelib: 1) if your code uses SEH (structured exception handling), you have a problem. This technique is patented by Borland, see http://www.google.com/search?q=patent+5628016 or maybe by Sun, see http://www.google.com/search?q=patent+6247169 so the official gnu gcc can't support it. You can apply an unoffical patch (see http://reactos.csh-consult.dk/index.php?page=gccseh, or you may be able to use winelib plus some clever macros (see http://www.winehq.org/hypermail/wine-devel/2005/05/0186.html) 2) if you want to reach non-x86 platforms (e.g. MacOSX/PPC, Solaris/Sparc) winelib is the only way to go until projects like Darwine integrate a CPU emulator. - Dan

1 0

Wine Wiki Status
by Dimitrie O. Paun 06 May '05

06 May '05

A few things: 1. We've been attacked Wed by one or two idiots from Slashdot. They kept replacing the content of the front page with some silly Balmer images :) Not a big deal, since MoinMoin makes it a snap to revert to an older version. However, this episode forced me to at least require that you sign up before you can edit a page. This is probably a good idea anyway, I hope people agree. 2. I've placed the modifications to the code on the Wine CVS repository at SourceForge in the 'wiki' module. Please feel free to check it out and send in patches (sending them to wine-patches(a)winehq.org with a subject prefix of 'Wiki:' is fine, or directly to me if you prefer). 3. Mike is right, the namespacing stuff if not a good idea. I'll try to get rid of it, I'm going to try to rename the page, but first I have to enable the feature. If not, I'll just simply recreate them. As always, you comments, suggestions and complaints are most welcome. -- Dimi.

6 6

Readers' choices: 2004 Desktop Linux survey results in!
by Tom Wickline 06 May '05

06 May '05

Hello All, Here is the results: http://www.desktoplinux.com/articles/AT2127420238.html Wine 34 % Crossover 16.3 % VMWare 13.7 % Win4Lin 6.9 % Other (please email us) 1 % None -- I don't run Windows apps under Linux 27.9 % http://www.desktoplinux.com/cgi-bin/survey/survey.cgi?view=archive&id=02152… What I find interesting is this part. Last year's poll results revealed that about 60 percent of the 3,946 readers polled had both currently used Windows applications under Linux and expected to do so in the future. Tom

2 1

test.winehq.org broken
by Stefan Leichter 06 May '05

06 May '05

Hello, looks like adding the dll name to the output of the tests broke the script that creates the pages on test.winehq.org. Now all test are listed as failed output from winetest-200504301000-paul-mingw.exe crypt: 37 tests executed, 0 marked as todo, 0 failures. output from winetest-200505051000-paul-mingw.exe advapi32/crypt: 37 tests executed, 0 marked as todo, 0 failures. Can someone please fix the script building the summary page. Thanks Stefan

3 3

Incorrect locale used in wine 20050310 (Debian testing)
by J. Grant 06 May '05

06 May '05

Hello, I think I have found a bug in the locale system used by wine. I get (incorrectly) English dialog text, with Japanese on the buttons. For example: =========== Set Optimal Settings? --------------------- Your computer has changed since the last time you ran. Re-configure for new hardware? [はい(Y)] [いいえ(N)] =========== I use English locale, with only Japanese input supported as an option. This is the only program which appears with Japanese text. Everything else is in English. The buttons should not be in Japanese. I am not on this list, so please include my email address in any replies. $ locale LANG=en_GB.UTF-8 LC_CTYPE=ja_JP.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio

1 0

Re: [DSOUND] move initialization (revised patch)
by Robert Reif 06 May '05

06 May '05

Robert Reif wrote: > Move initialization to IDirectSound_Initialize. > Fix error paths to handle a failed IDirectSound_Initialize. > Add tests for IDirectSound_Initialize. > > This patch fixes wine to fail the same way windows does > when run with a defective device driver. This revised patch fixes a problem when trying to initialize an initialized object when creating the object more than once. Index: dlls/dsound/dsound.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/dsound.c,v retrieving revision 1.31 diff -u -p -r1.31 dsound.c --- dlls/dsound/dsound.c 15 Mar 2005 15:40:36 -0000 1.31 +++ dlls/dsound/dsound.c 6 May 2005 16:02:54 -0000 @@ -684,11 +684,107 @@ static HRESULT WINAPI IDirectSoundImpl_I LPCGUID lpcGuid) { IDirectSoundImpl *This = (IDirectSoundImpl *)iface; + HRESULT hr = DS_OK; TRACE("(%p,%s)\n",This,debugstr_guid(lpcGuid)); - This->initialized = TRUE; + if (This->initialized == TRUE) { + WARN("already initialized\n"); + return DSERR_ALREADYINITIALIZED; + } - return DS_OK; + /* If the driver requests being opened through MMSYSTEM + * (which is recommended by the DDK), it is supposed to happen + * before the DirectSound interface is opened */ + if (This->drvdesc.dwFlags & DSDDESC_DOMMSYSTEMOPEN) + { + DWORD flags = CALLBACK_FUNCTION; + + /* disable direct sound if requested */ + if (ds_hw_accel != DS_HW_ACCEL_EMULATION) + flags |= WAVE_DIRECTSOUND; + + hr = mmErr(waveOutOpen(&(This->hwo), + This->drvdesc.dnDevNode, This->pwfx, + (DWORD)DSOUND_callback, (DWORD)This, + flags)); + if (hr != DS_OK) { + WARN("waveOutOpen failed\n"); + return hr; + } + } + + if (This->driver) { + hr = IDsDriver_Open(This->driver); + if (hr != DS_OK) { + WARN("IDsDriver_Open failed\n"); + return hr; + } + + /* the driver is now open, so it's now allowed to call GetCaps */ + hr = IDsDriver_GetCaps(This->driver,&(This->drvcaps)); + if (hr != DS_OK) { + WARN("IDsDriver_GetCaps failed\n"); + return hr; + } + } else { + WAVEOUTCAPSA woc; + hr = mmErr(waveOutGetDevCapsA(This->drvdesc.dnDevNode, &woc, sizeof(woc))); + if (hr != DS_OK) { + WARN("waveOutGetDevCaps failed\n"); + return hr; + } + ZeroMemory(&This->drvcaps, sizeof(This->drvcaps)); + if ((woc.dwFormats & WAVE_FORMAT_1M08) || + (woc.dwFormats & WAVE_FORMAT_2M08) || + (woc.dwFormats & WAVE_FORMAT_4M08) || + (woc.dwFormats & WAVE_FORMAT_48M08) || + (woc.dwFormats & WAVE_FORMAT_96M08)) { + This->drvcaps.dwFlags |= DSCAPS_PRIMARY8BIT; + This->drvcaps.dwFlags |= DSCAPS_PRIMARYMONO; + } + if ((woc.dwFormats & WAVE_FORMAT_1M16) || + (woc.dwFormats & WAVE_FORMAT_2M16) || + (woc.dwFormats & WAVE_FORMAT_4M16) || + (woc.dwFormats & WAVE_FORMAT_48M16) || + (woc.dwFormats & WAVE_FORMAT_96M16)) { + This->drvcaps.dwFlags |= DSCAPS_PRIMARY16BIT; + This->drvcaps.dwFlags |= DSCAPS_PRIMARYMONO; + } + if ((woc.dwFormats & WAVE_FORMAT_1S08) || + (woc.dwFormats & WAVE_FORMAT_2S08) || + (woc.dwFormats & WAVE_FORMAT_4S08) || + (woc.dwFormats & WAVE_FORMAT_48S08) || + (woc.dwFormats & WAVE_FORMAT_96S08)) { + This->drvcaps.dwFlags |= DSCAPS_PRIMARY8BIT; + This->drvcaps.dwFlags |= DSCAPS_PRIMARYSTEREO; + } + if ((woc.dwFormats & WAVE_FORMAT_1S16) || + (woc.dwFormats & WAVE_FORMAT_2S16) || + (woc.dwFormats & WAVE_FORMAT_4S16) || + (woc.dwFormats & WAVE_FORMAT_48S16) || + (woc.dwFormats & WAVE_FORMAT_96S16)) { + This->drvcaps.dwFlags |= DSCAPS_PRIMARY16BIT; + This->drvcaps.dwFlags |= DSCAPS_PRIMARYSTEREO; + } + if (ds_emuldriver) + This->drvcaps.dwFlags |= DSCAPS_EMULDRIVER; + This->drvcaps.dwMinSecondarySampleRate = DSBFREQUENCY_MIN; + This->drvcaps.dwMaxSecondarySampleRate = DSBFREQUENCY_MAX; + This->drvcaps.dwPrimaryBuffers = 1; + } + + hr = DSOUND_PrimaryCreate((IDirectSoundImpl*)This); + if (hr == DS_OK) { + This->initialized = TRUE; + DSOUND_renderer = (IDirectSoundImpl*)This; + timeBeginPeriod(DS_TIME_RES); + DSOUND_renderer->timerID = timeSetEvent(DS_TIME_DEL, DS_TIME_RES, DSOUND_timer, + (DWORD)DSOUND_renderer, TIME_PERIODIC | TIME_CALLBACK_FUNCTION); + } else { + WARN("DSOUND_PrimaryCreate failed\n"); + } + + return hr; } static HRESULT WINAPI IDirectSoundImpl_VerifyCertification( @@ -841,11 +937,11 @@ HRESULT WINAPI IDirectSoundImpl_Create( return DSERR_OUTOFMEMORY; } - pDS->pwfx->wFormatTag = WAVE_FORMAT_PCM; /* We rely on the sound driver to return the actual sound format of * the device if it does not support 22050x8x2 and is given the * WAVE_DIRECTSOUND flag. */ + pDS->pwfx->wFormatTag = WAVE_FORMAT_PCM; pDS->pwfx->nSamplesPerSec = 22050; pDS->pwfx->wBitsPerSample = 8; pDS->pwfx->nChannels = 2; @@ -853,95 +949,6 @@ HRESULT WINAPI IDirectSoundImpl_Create( pDS->pwfx->nAvgBytesPerSec = pDS->pwfx->nSamplesPerSec * pDS->pwfx->nBlockAlign; pDS->pwfx->cbSize = 0; - /* If the driver requests being opened through MMSYSTEM - * (which is recommended by the DDK), it is supposed to happen - * before the DirectSound interface is opened */ - if (pDS->drvdesc.dwFlags & DSDDESC_DOMMSYSTEMOPEN) - { - DWORD flags = CALLBACK_FUNCTION; - - /* disable direct sound if requested */ - if (ds_hw_accel != DS_HW_ACCEL_EMULATION) - flags |= WAVE_DIRECTSOUND; - - err = mmErr(waveOutOpen(&(pDS->hwo), - pDS->drvdesc.dnDevNode, pDS->pwfx, - (DWORD)DSOUND_callback, (DWORD)pDS, - flags)); - if (err != DS_OK) { - WARN("waveOutOpen failed\n"); - HeapFree(GetProcessHeap(),0,pDS); - *ppDS = NULL; - return err; - } - } - - if (drv) { - err = IDsDriver_Open(drv); - if (err != DS_OK) { - WARN("IDsDriver_Open failed\n"); - HeapFree(GetProcessHeap(),0,pDS); - *ppDS = NULL; - return err; - } - - /* the driver is now open, so it's now allowed to call GetCaps */ - err = IDsDriver_GetCaps(drv,&(pDS->drvcaps)); - if (err != DS_OK) { - WARN("IDsDriver_GetCaps failed\n"); - HeapFree(GetProcessHeap(),0,pDS); - *ppDS = NULL; - return err; - } - } else { - WAVEOUTCAPSA woc; - err = mmErr(waveOutGetDevCapsA(pDS->drvdesc.dnDevNode, &woc, sizeof(woc))); - if (err != DS_OK) { - WARN("waveOutGetDevCaps failed\n"); - HeapFree(GetProcessHeap(),0,pDS); - *ppDS = NULL; - return err; - } - ZeroMemory(&pDS->drvcaps, sizeof(pDS->drvcaps)); - if ((woc.dwFormats & WAVE_FORMAT_1M08) || - (woc.dwFormats & WAVE_FORMAT_2M08) || - (woc.dwFormats & WAVE_FORMAT_4M08) || - (woc.dwFormats & WAVE_FORMAT_48M08) || - (woc.dwFormats & WAVE_FORMAT_96M08)) { - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARY8BIT; - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARYMONO; - } - if ((woc.dwFormats & WAVE_FORMAT_1M16) || - (woc.dwFormats & WAVE_FORMAT_2M16) || - (woc.dwFormats & WAVE_FORMAT_4M16) || - (woc.dwFormats & WAVE_FORMAT_48M16) || - (woc.dwFormats & WAVE_FORMAT_96M16)) { - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARY16BIT; - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARYMONO; - } - if ((woc.dwFormats & WAVE_FORMAT_1S08) || - (woc.dwFormats & WAVE_FORMAT_2S08) || - (woc.dwFormats & WAVE_FORMAT_4S08) || - (woc.dwFormats & WAVE_FORMAT_48S08) || - (woc.dwFormats & WAVE_FORMAT_96S08)) { - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARY8BIT; - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARYSTEREO; - } - if ((woc.dwFormats & WAVE_FORMAT_1S16) || - (woc.dwFormats & WAVE_FORMAT_2S16) || - (woc.dwFormats & WAVE_FORMAT_4S16) || - (woc.dwFormats & WAVE_FORMAT_48S16) || - (woc.dwFormats & WAVE_FORMAT_96S16)) { - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARY16BIT; - pDS->drvcaps.dwFlags |= DSCAPS_PRIMARYSTEREO; - } - if (ds_emuldriver) - pDS->drvcaps.dwFlags |= DSCAPS_EMULDRIVER; - pDS->drvcaps.dwMinSecondarySampleRate = DSBFREQUENCY_MIN; - pDS->drvcaps.dwMaxSecondarySampleRate = DSBFREQUENCY_MAX; - pDS->drvcaps.dwPrimaryBuffers = 1; - } - InitializeCriticalSection(&(pDS->mixlock)); pDS->mixlock.DebugInfo->Spare[1] = (DWORD)"DSOUND_mixlock"; @@ -1610,16 +1617,6 @@ HRESULT WINAPI DSOUND_Create( TRACE("(%s,%p,%p)\n",debugstr_guid(lpcGUID),ppDS,pUnkOuter); - if (pUnkOuter != NULL) { - WARN("invalid parameter: pUnkOuter != NULL\n"); - return DSERR_INVALIDPARAM; - } - - if (ppDS == NULL) { - WARN("invalid parameter: ppDS == NULL\n"); - return DSERR_INVALIDPARAM; - } - /* Get dsound configuration */ setup_dsound_options(); @@ -1649,22 +1646,11 @@ HRESULT WINAPI DSOUND_Create( LPDIRECTSOUND8 pDS; hr = IDirectSoundImpl_Create(&devGuid, &pDS); if (hr == DS_OK) { - hr = DSOUND_PrimaryCreate((IDirectSoundImpl*)pDS); - if (hr == DS_OK) { - hr = IDirectSound_IDirectSound_Create(pDS, ppDS); - if (*ppDS) { - IDirectSound_IDirectSound_AddRef(*ppDS); - - DSOUND_renderer = (IDirectSoundImpl*)pDS; - timeBeginPeriod(DS_TIME_RES); - DSOUND_renderer->timerID = timeSetEvent(DS_TIME_DEL, DS_TIME_RES, DSOUND_timer, - (DWORD)DSOUND_renderer, TIME_PERIODIC | TIME_CALLBACK_FUNCTION); - } else { - WARN("IDirectSound_IDirectSound_Create failed\n"); - IDirectSound8_Release(pDS); - } - } else { - WARN("DSOUND_PrimaryCreate failed\n"); + hr = IDirectSound_IDirectSound_Create(pDS, ppDS); + if (*ppDS) + IDirectSound_IDirectSound_AddRef(*ppDS); + else { + WARN("IDirectSound_IDirectSound_Create failed\n"); IDirectSound8_Release(pDS); } } else @@ -1695,12 +1681,33 @@ HRESULT WINAPI DirectSoundCreate( IUnknown *pUnkOuter) { HRESULT hr; + LPDIRECTSOUND pDS; TRACE("(%s,%p,%p)\n",debugstr_guid(lpcGUID),ppDS,pUnkOuter); - hr = DSOUND_Create(lpcGUID, ppDS, pUnkOuter); - if (hr == DS_OK) - IDirectSound_Initialize(*ppDS, lpcGUID); + if (ppDS == NULL) { + WARN("invalid parameter: ppDS == NULL\n"); + return DSERR_INVALIDPARAM; + } + + if (pUnkOuter != NULL) { + WARN("invalid parameter: pUnkOuter != NULL\n"); + *ppDS = 0; + return DSERR_INVALIDPARAM; + } + + hr = DSOUND_Create(lpcGUID, &pDS, pUnkOuter); + if (hr == DS_OK) { + IDirectSound_IDirectSound * pp = (IDirectSound_IDirectSound *)pDS; + IDirectSoundImpl * p = (IDirectSoundImpl *)(pp->pds); + if (!(p->initialized)) { + hr = IDirectSound_Initialize(pDS, lpcGUID); + if (hr != DS_OK) + IDirectSound_Release(pDS); + } + } + + *ppDS = pDS; return hr; } @@ -1715,16 +1722,6 @@ HRESULT WINAPI DSOUND_Create8( TRACE("(%s,%p,%p)\n",debugstr_guid(lpcGUID),ppDS,pUnkOuter); - if (pUnkOuter != NULL) { - WARN("invalid parameter: pUnkOuter != NULL\n"); - return DSERR_INVALIDPARAM; - } - - if (ppDS == NULL) { - WARN("invalid parameter: ppDS == NULL\n"); - return DSERR_INVALIDPARAM; - } - /* Get dsound configuration */ setup_dsound_options(); @@ -1754,22 +1751,11 @@ HRESULT WINAPI DSOUND_Create8( LPDIRECTSOUND8 pDS; hr = IDirectSoundImpl_Create(&devGuid, &pDS); if (hr == DS_OK) { - hr = DSOUND_PrimaryCreate((IDirectSoundImpl*)pDS); - if (hr == DS_OK) { - hr = IDirectSound8_IDirectSound8_Create(pDS, ppDS); - if (*ppDS) { - IDirectSound8_IDirectSound8_AddRef(*ppDS); - - DSOUND_renderer = (IDirectSoundImpl*)pDS; - timeBeginPeriod(DS_TIME_RES); - DSOUND_renderer->timerID = timeSetEvent(DS_TIME_DEL, DS_TIME_RES, DSOUND_timer, - (DWORD)DSOUND_renderer, TIME_PERIODIC | TIME_CALLBACK_FUNCTION); - } else { - WARN("IDirectSound8_IDirectSound8_Create failed\n"); - IDirectSound8_Release(pDS); - } - } else { - WARN("DSOUND_PrimaryCreate failed\n"); + hr = IDirectSound8_IDirectSound8_Create(pDS, ppDS); + if (*ppDS) + IDirectSound8_IDirectSound8_AddRef(*ppDS); + else { + WARN("IDirectSound8_IDirectSound8_Create failed\n"); IDirectSound8_Release(pDS); } } else @@ -1800,12 +1786,33 @@ HRESULT WINAPI DirectSoundCreate8( IUnknown *pUnkOuter) { HRESULT hr; + LPDIRECTSOUND8 pDS; TRACE("(%s,%p,%p)\n",debugstr_guid(lpcGUID),ppDS,pUnkOuter); - hr = DSOUND_Create8(lpcGUID, ppDS, pUnkOuter); - if (hr == DS_OK) - IDirectSound8_Initialize(*ppDS, lpcGUID); + if (ppDS == NULL) { + WARN("invalid parameter: ppDS == NULL\n"); + return DSERR_INVALIDPARAM; + } + + if (pUnkOuter != NULL) { + WARN("invalid parameter: pUnkOuter != NULL\n"); + *ppDS = 0; + return DSERR_INVALIDPARAM; + } + + hr = DSOUND_Create8(lpcGUID, &pDS, pUnkOuter); + if (hr == DS_OK) { + IDirectSound8_IDirectSound8 * pp = (IDirectSound8_IDirectSound8 *)pDS; + IDirectSoundImpl * p = (IDirectSoundImpl *)(pp->pds); + if (!(p->initialized)) { + hr = IDirectSound8_Initialize(pDS, lpcGUID); + if (hr != DS_OK) + IDirectSound8_Release(pDS); + } + } + + *ppDS = pDS; return hr; } Index: dlls/dsound/tests/dsound.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/tests/dsound.c,v retrieving revision 1.52 diff -u -p -r1.52 dsound.c --- dlls/dsound/tests/dsound.c 30 Mar 2005 10:21:44 -0000 1.52 +++ dlls/dsound/tests/dsound.c 6 May 2005 16:02:55 -0000 @@ -93,16 +93,21 @@ static void IDirectSound_test(LPDIRECTSO "IDirectSound_Initialize() failed: %s\n",DXGetErrorString8(rc)); if (rc==DSERR_NODRIVER) { trace(" No Driver\n"); - return; + goto EXIT; } else if (rc==E_FAIL) { trace(" No Device\n"); - return; + goto EXIT; } else if (rc==DSERR_ALLOCATED) { trace(" Already In Use\n"); - return; + goto EXIT; } } + rc=IDirectSound_Initialize(dso,lpGuid); + ok(rc==DSERR_ALREADYINITIALIZED, "IDirectSound_Initialize() " + "should have returned DSERR_ALREADYINITIALIZED: %s\n", + DXGetErrorString8(rc)); + /* DSOUND: Error: Invalid caps buffer */ rc=IDirectSound_GetCaps(dso,0); ok(rc==DSERR_INVALIDPARAM,"IDirectSound_GetCaps(NULL) " @@ -158,6 +163,7 @@ static void IDirectSound_test(LPDIRECTSO speaker_config,new_speaker_config); } +EXIT: ref=IDirectSound_Release(dso); ok(ref==0,"IDirectSound_Release() has %d references, should have 0\n",ref); } @@ -238,6 +244,8 @@ static void IDirectSound_tests() rc=DirectSoundCreate(&DSDEVID_DefaultVoiceCapture,&dso,NULL); ok(rc==DSERR_NODRIVER,"DirectSoundCreate(DSDEVID_DefaultVoiceCapture) " "should have failed: %s\n",DXGetErrorString8(rc)); + if (rc==DS_OK && dso) + IDirectSound_Release(dso); } static HRESULT test_dsound(LPGUID lpGuid) Index: dlls/dsound/tests/dsound8.c =================================================================== RCS file: /home/wine/wine/dlls/dsound/tests/dsound8.c,v retrieving revision 1.21 diff -u -p -r1.21 dsound8.c --- dlls/dsound/tests/dsound8.c 11 Apr 2005 12:52:00 -0000 1.21 +++ dlls/dsound/tests/dsound8.c 6 May 2005 16:02:56 -0000 @@ -108,16 +108,21 @@ static void IDirectSound8_test(LPDIRECTS "IDirectSound8_Initialize() failed: %s\n",DXGetErrorString8(rc)); if (rc==DSERR_NODRIVER) { trace(" No Driver\n"); - return; + goto EXIT; } else if (rc==E_FAIL) { trace(" No Device\n"); - return; + goto EXIT; } else if (rc==DSERR_ALLOCATED) { trace(" Already In Use\n"); - return; + goto EXIT; } } + rc=IDirectSound8_Initialize(dso,lpGuid); + ok(rc==DSERR_ALREADYINITIALIZED, "IDirectSound8_Initialize() " + "should have returned DSERR_ALREADYINITIALIZED: %s\n", + DXGetErrorString8(rc)); + /* DSOUND: Error: Invalid caps buffer */ rc=IDirectSound8_GetCaps(dso,0); ok(rc==DSERR_INVALIDPARAM,"IDirectSound8_GetCaps() " @@ -177,6 +182,7 @@ static void IDirectSound8_test(LPDIRECTS ok(rc==DS_OK||rc==E_NOTIMPL,"IDirectSound8_VerifyCertification() failed: %s\n", DXGetErrorString8(rc)); +EXIT: ref=IDirectSound8_Release(dso); ok(ref==0,"IDirectSound8_Release() has %d references, should have 0\n",ref); }

1 0

Re: Cannot compile man pages outside source directory
by William Poetra Yoga H 06 May '05

06 May '05

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > > Just a detail but you probably want to use -C instead of -D for that > option, it's what the other tools like makedep or winebuild use for > that purpose. > OK, it's -C now. By the way, I think the checks when assigning $opt_source_dir are a bit simpler (maybe too simple?) than those for other command line options... William Poetra Yoga Hadisoeseno __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ Index: dlls/Makedll.rules.in =================================================================== RCS file: /home/wine/wine/dlls/Makedll.rules.in,v retrieving revision 1.71 diff -u -p -r1.71 Makedll.rules.in --- dlls/Makedll.rules.in 8 Mar 2005 16:55:26 -0000 1.71 +++ dlls/Makedll.rules.in 6 May 2005 15:12:52 -0000 @@ -61,13 +61,13 @@ $(MAINSPEC).c: $(MAINSPEC) $(RC_SRCS:.rc # Rules for auto documentation man: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -C$(SRCDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) doc-html: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) $(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) -C$(SRCDIR) $(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) doc-sgml: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR) $(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR) -C$(SRCDIR) $(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) .PHONY: man doc-html doc-sgml Index: tools/c2man.pl =================================================================== RCS file: /home/wine/wine/tools/c2man.pl,v retrieving revision 1.21 diff -u -p -r1.21 c2man.pl --- tools/c2man.pl 7 Jan 2005 17:17:23 -0000 1.21 +++ tools/c2man.pl 6 May 2005 15:12:56 -0000 @@ -42,6 +42,7 @@ my $FLAG_64PAIR = 64; # The 64 bit v # Options my $opt_output_directory = "man3w"; # All default options are for nroff (man pages) my $opt_manual_section = "3w"; +my $opt_source_dir = ""; my $opt_wine_root_dir = ""; my $opt_output_format = ""; # '' = nroff, 'h' = html, 's' = sgml my $opt_output_empty = 0; # Non-zero = Create 'empty' comments (for every implemented function) @@ -120,7 +121,10 @@ sub process_spec_file($) # We allow opening to fail just to cater for the peculiarities of # the Wine build system. This doesn't hurt, in any case - open(SPEC_FILE, "<$spec_name") || return; + open(SPEC_FILE, "<$spec_name") + || (($opt_source_dir ne "") + && open(SPEC_FILE, "<$opt_source_dir/$spec_name")) + || return; while(<SPEC_FILE>) { @@ -236,7 +240,10 @@ sub process_source_file($) { print "Processing ".$source_file."\n"; } - open(SOURCE_FILE,"<$source_file") || die "couldn't open ".$source_file."\n"; + open(SOURCE_FILE,"<$source_file") + || (($opt_source_dir ne "") + && open(SOURCE_FILE,"<$opt_source_dir/$source_file")) + || die "couldn't open ".$source_file."\n"; # Add this source file to the list of source files $source_files{$source_file} = [$source_details]; @@ -2115,6 +2122,9 @@ sub usage() "Options:\n", " -Th : Output HTML instead of a man page\n", " -Ts : Output SGML (Docbook source) instead of a man page\n", + " -C <dir> : Source directory, to find source files if they are not found in the\n", + " current directory. Default is \"",$opt_source_dir,"\"\n", + " -R <dir> : Root of build directory, default is \"",$opt_wine_root_dir,"\"\n", " -o <dir> : Create output in <dir>, default is \"",$opt_output_directory,"\"\n", " -s <sect>: Set manual section to <sect>, default is ",$opt_manual_section,"\n", " -e : Output \"FIXME\" documentation from empty comments.\n", @@ -2156,6 +2166,10 @@ while(defined($_ = shift @ARGV)) } last; }; + s/^C// && do { + if ($_ ne "") { $opt_source_dir = $_; } + last; + }; s/^R// && do { if ($_ =~ /^\//) { $opt_wine_root_dir = $_; } else { $opt_wine_root_dir = `cd $pwd/$_ && pwd`; } $opt_wine_root_dir =~ s/\n//; @@ -2181,8 +2195,9 @@ if ($opt_verbose > 3) { print "Output dir:'".$opt_output_directory."'\n"; print "Section :'".$opt_manual_section."'\n"; - print "Format :'".$opt_output_format."'\n"; - print "Root :'".$opt_wine_root_dir."'\n"; + print "Format :'".$opt_output_format."'\n"; + print "Source dir:'".$opt_source_dir."'\n"; + print "Root :'".$opt_wine_root_dir."'\n"; print "Spec files:'@opt_spec_file_list'\n"; print "Includes :'@opt_header_file_list'\n"; print "Sources :'@opt_source_file_list'\n";

1 0

Re: Cannot compile man pages outside source directory
by William Poetra Yoga H 06 May '05

06 May '05

I've modified the c2man.pl script, now 'make manpages' doesn't exit with an error, but no file is written to documentation/man3w. What's wrong? The diff is attached. William Poetra Yoga Hadisoeseno __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ Index: dlls/Makedll.rules.in =================================================================== RCS file: /home/wine/wine/dlls/Makedll.rules.in,v retrieving revision 1.71 diff -u -p -r1.71 Makedll.rules.in --- dlls/Makedll.rules.in 8 Mar 2005 16:55:26 -0000 1.71 +++ dlls/Makedll.rules.in 6 May 2005 07:35:03 -0000 @@ -61,7 +61,7 @@ $(MAINSPEC).c: $(MAINSPEC) $(RC_SRCS:.rc # Rules for auto documentation man: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -D$(SRCDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) doc-html: $(C_SRCS) $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) $(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) Index: tools/c2man.pl =================================================================== RCS file: /home/wine/wine/tools/c2man.pl,v retrieving revision 1.21 diff -u -p -r1.21 c2man.pl --- tools/c2man.pl 7 Jan 2005 17:17:23 -0000 1.21 +++ tools/c2man.pl 6 May 2005 07:35:06 -0000 @@ -42,6 +42,7 @@ my $FLAG_64PAIR = 64; # The 64 bit v # Options my $opt_output_directory = "man3w"; # All default options are for nroff (man pages) my $opt_manual_section = "3w"; +my $opt_source_dir = ""; my $opt_wine_root_dir = ""; my $opt_output_format = ""; # '' = nroff, 'h' = html, 's' = sgml my $opt_output_empty = 0; # Non-zero = Create 'empty' comments (for every implemented function) @@ -236,7 +237,7 @@ sub process_source_file($) { print "Processing ".$source_file."\n"; } - open(SOURCE_FILE,"<$source_file") || die "couldn't open ".$source_file."\n"; + open(SOURCE_FILE,"<$source_file") || open(SOURCE_FILE,"<$opt_source_dir$source_file") || die "couldn't open ".$source_file."\n"; # Add this source file to the list of source files $source_files{$source_file} = [$source_details]; @@ -2154,6 +2155,10 @@ while(defined($_ = shift @ARGV)) my $have_headers = `ls $include >/dev/null 2>&1`; if ($? >> 8 == 0) { @opt_header_file_list = (@opt_header_file_list, $include); } } + last; + }; + s/^D// && do { + if ($_ ne "") { $opt_source_dir = $_."/"; } last; }; s/^R// && do { if ($_ =~ /^\//) { $opt_wine_root_dir = $_; }

2 2

Re: shell32/brsfolder: returned pidl has to be cloned
by Michael Stefaniuc 06 May '05

06 May '05

On Fri, May 06, 2005 at 03:29:06PM +0200, Michael Jung wrote: > info->pidlRet points directly to a pidl stored in the treeview-item, which > will be free'd when the dialog is closed. Thus we have to clone the pidl > before. MSDN says that the caller of SHBrowseForFolder is responsible for > free'ing the returned pidl. > > Changelog: > Return a cloned PIDL by SHBrowseForFolder to avoid heap corruption And the patch? ;) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: unix filenames in notepad
by Michael Lin 06 May '05

06 May '05

Hi Michael, > Oops, as you see I'm undecided ;) (Anyway, this probably should be GNU ;) > However, in the final version I would like this to appear not at all in the > shell namespace, anyway. I think it would be nice if the '/' appears beside > the wine drive letters under 'My Computer'. I have been extending your work to integrate shfldr_unixfs more with open file dialog. I am modifying open file dialog to accept typed in unix path and through validation checks as well I have also fixed a bug in shfldr_unixfs and extend IPersistFolder to IPersistFolder2. I know you are working on this area as well, so maybe we should coordinate our effort so that there is no duplicate work. I know there will be issues of Windows APIs won't accept unix file path. But at this point, I just want to extend open file dialog optionally accept and return a unix file path. The flag to turn unix path on or off can be in the registry, or simply a extended flag that was passed in to OPENFILENAME struct. Michael Lin

10 13

Re: unix filenames in notepad
by William Poetra Yoga H 06 May '05

06 May '05

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > James, if an application informs us somehow (TBD) that they > can handle Unix paths, there's no reason to force the silly > drive letters on Unix users. Ideally we would even hide the > drive letter combo box in the file dialogs. > Well, maybe I could comment... I think the z: driver letter convention is ok, because: 1. Wine should provide the Windows API on top of Unix, and although extensions are OK, adding unix path handling capability is somehow "incorrect" IMO 2. Unix users using Windows software usually come from Windows 3. Windows apps ported using Winelib are usually desktop applications, and don't touch the root; they usually operate on files in the home directory. So we don't need to add unix path handling here. 4. There's already a z: drive that points to /, and it makes Wine simpler (yes, in design). Ever wondered why Microsoft software are buggy? P.S. Actually the BSD users are already quite familiar with drive letters ;) William Poetra Yoga Hadisoeseno __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

1 0

Re: unix filenames in notepad
by William Poetra Yoga H 06 May '05

06 May '05

--- Troy Rollo <wine(a)troy.rollo.name> wrote: > On Fri, 6 May 2005 09:10, James Hawkins wrote: > > wine wasn't designed to accept unix paths in the apis directly or to > > display them in open file dialogs, > > Linux wasn't designed to run Windows applications either - these things are > subject to change. > Yes, and Windows applications wasn't designed to 'see' Unix paths, whether developed on Windows (like WinZip) or on Linux (winemine). > > This just adds complexity to an already complex beast. Keep it simple. > > If it's too complex for *you* then nobody's asking *you* to implement it. > It's > needed for some uses of WINE, and we have at least one corporate developer > and one individual developer who are willing to implement it. This pretty > much guarantees something will be implemented whether it's beyond your > capabilities or not. The only real question is what is the best *way* to > implement it. > Uh... it's getting hotter here... "... one corporate developer ..." hm... ;) *If* we're at the very least worried about not having an existing z: drive (like with winecfg), I suggest we make z: a default drive for / (or is it already implemented??) So if there's already an existing z: symlink in ~/.wine/dosdevices, we use that, otherwise imply z: -> / William Poetra Yoga Hadisoeseno Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

3 2

wineconf videos on Wiki
by Andreas Mohr 06 May '05

06 May '05

Hi all, I set up a page with various video and presentation sites at http://wiki.winehq.org/WineConf Feel free to add further stuff there! Andreas

1 0

resizing?
by Maarten Lankhorst 06 May '05

06 May '05

static void Resize(CaptureBox * capBox, LPBYTE output, LPBYTE input) { if (!capBox->swresize) { int depth = capBox->bitDepth / 8; int inoffset = 0, outoffset = (capBox->height-1) * capBox->width * depth; int ow = capBox->width * depth; while (outoffset >= 0) { int x; outoffset -= ow; for (x = 0; x < ow; x++) output[outoffset + x] = input[inoffset + x]; inoffset += ow; } } else { FIXME("Software scaling not supported, I got no clue how and no-one wants to help so adding gray instead...\n"); memset(output, 128, capBox->outputwidth * capBox->outputheight * capBox->bitDepth / 8); } } I want to copy from a raw bitmap stream which is (capBox->width) x (capBox->height) (24 bits) to (capBox->outputwidth) x (capBox->outputheight) (also 24 bits), if you can argue about HAVE_V4L2 this should be easy :) I *really* need this fixed, any info is greatly appreciated.. gluScaleImage seemed ideal, but a qcap linking to glu32 would never make it to the wine source.. so a more windows-compliant(TM) solution(R) is required, since I'm a disaster in win32 programming best would be instant code of which i only need to change variable names or something (yet ironically enough i know too much of com, directshow & devenum already :-\ ) THANKS!! Maarten

2 2

wineconf video downloads
by Ivan Leo Puoti 06 May '05

06 May '05

Videos will appear here http://wineconf.geldorp.nl/ enjoy. Ivan.

10 15

[revisited] [OLE #31] Dynamically Allocate the MTA
by Dustin Navea 06 May '05

06 May '05

>Vincent Béron wrote: > >>Le mar 11/01/2005 à 14:03, Robert Shearman a écrit : >> >> >>>Changelog: >>>- Make MTA dynamically allocated so that proxies and other resources are >>>freed at the proper time. >>>- Changed/removed some incorrect comments regarding apartments. >>>---- >>> >>> >>> >> >>This patch broke wineprefixcreate invocation for me. >> >>What happens is I get a: >>X Error of failed request: BadWindow (invalid Window parameter) >> Major opcode of failed request: 18 (X_ChangeProperty) >> Resource id in failed request: 0x77e61740 >> Serial number of failed request: 107 >> Current serial number in output stream: 114 >>error while wineprefixcreate runs "wine rundll32.exe >>setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf". >> >>The error do go away if one of avifil32.dll or devenum.dll is commented >>out in [RegisterDllsSection] in wine.inf. >> >>My personal guess is that one (or both) of those dlls do something which >>they should not, and we end up with using freed or unallocated memory. >> >> > >I don't see the problem on my machine. Do the tests in dlls/ole32/tests >work for you? >Is it possible to capture a +ole log for the wineprefixcreate >invocation? >I'll do a review of the code paths that patch touches anyway, but I >don't see how it could affect things - devenum does not use MTAs and >avifil32 does not use COM. > >Rob Apparently this is affecting more than 1 user (see bug 2398). Was the cause (and a proper fix) ever found for this problem other than commenting out the necessary line? The reporter of that bug was going to do a regression test, and the Jan release was the last official release that worked, so of course this problem affected him until he found that mail. I assume so since we havent gotten any more reports of this, but I want to make sure, and find out when the problem was fixed. Dustin

4 4

Re: unix filenames in notepad
by William Poetra Yoga H 06 May '05

06 May '05

--- James Hawkins <truiken(a)gmail.com> wrote: > On 5/6/05, William Poetra Yoga H <williampoetra(a)yahoo.com> wrote: > > > > *If* we're at the very least worried about not having an existing z: drive > > (like with winecfg), I suggest we make z: a default drive for / (or is it > > already implemented??) So if there's already an existing z: symlink in > > ~/.wine/dosdevices, we use that, otherwise imply z: -> / > > > > That's the beauty of it! wineprefixcreate sets z: to point to / > automatically. Of course the user can always change what z: points > to, but / is the default location. > What I mean is, z: -> / is implied in the source. So even without a z: symlink, the z: drive will appear and contains the files in /. This is an extension by itself, but I think it's better than enabling users to input unix paths in dialog boxes. William Poetra Yoga Hadisoeseno __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Regression in Half life
by Stefan Dösinger 06 May '05

06 May '05

Hello, These two patches cause a regression in Half-Life (Version 1.1.1.0): (1)http://www.winehq.org/hypermail/wine-cvs/2005/04/0307.html (2)http://www.winehq.org/hypermail/wine-cvs/2005/04/0308.html Half-life reports "ChoosePixelFormat failed", followed by "The Selected OpenGL mode is not supported by your card" when starting the engine. Wine prints the following error: err:opengl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0) Reversing the above 2 patches fixes the problem. Reversing patch 1 only causes a crash, if I reverse only patch 2 the problem still exists. Cheers, Stefan Here's a +opengl trace trace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 77 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c71a58)->(00000000,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c71a58)->(00000000,00000013) fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c71a58)->(00000000,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c71a58)->(00010028,00000013) fixme:win:LockWindowUpdate (0x10028), partial stub! fixme:mmtime:timeBeginPeriod Stub; we set our timer resolution at minimum fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c71a58)->(00000000,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x77c71a58)->(00010028,00000013) fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:win:LockWindowUpdate (0x10028), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:win:LockWindowUpdate (0x10028), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 trace:opengl:wgl_ext_initialize_extensions GL version : "1.3.5010 (X4.3.0-8.12.10)". trace:opengl:wgl_ext_initialize_extensions GL exts : "GL_ARB_multitexture GL_EXT_texture_env_add GL_EXT_compiled_vertex_array GL_S3_s3tc GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture".... trace:opengl:wgl_ext_initialize_extensions GLX exts : "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_ARB_get_proc_address GLX_ARB_multisample ". trace:opengl:wgl_ext_initialize_extensions Server GLX exts : "GLX_ARB_multisample GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_OML_swap_method GLX_SGI_make_current_read GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_ARB_get_proc_address ". trace:opengl:wgl_ext_initialize_extensions Client GLX exts : "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_ARB_get_proc_address GLX_ARB_multisample GLX_ATI_pixel_format_float GLX_ATI_render_texture ". fixme:opengl:query_function_pbuffer gl_version is: "1.3.5010 (X4.3.0-8.12.10)" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_ARB_get_proc_address GLX_ARB_multisample" fixme:opengl:query_function_pbuffer gl_version is: "1.3.5010 (X4.3.0-8.12.10)" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_ARB_get_proc_address GLX_ARB_multisample" trace:opengl:wgl_ext_initialize_extensions Supporting following WGL extensions : "WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_ARB_make_current_readWGL_ARB_multisample WGL_ARB_pbuffer WGL_ARB_pixel_format WGL_EXT_swap_control". trace:opengl:X11DRV_ChoosePixelFormat (0x77cc5448,0x1df4964) - size / version : 40 / 1 - dwFlags : PFD_DOUBLEBUFFER PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL - iPixelType : PFD_TYPE_RGBA - Color : 24 - Red : 0 - Green : 0 - Blue : 0 - Alpha : 0 - Accum : 0 - Depth : 32 - Stencil : 0 - Aux : 0 - iLayerType : PFD_MAIN_PLANE err:opengl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0) trace:opengl:wglMakeCurrent ((nil),(nil)) trace:opengl:wglMakeCurrent returning True fixme:win:LockWindowUpdate (0x10028), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 fixme:mmtime:timeEndPeriod Stub; we set our timer resolution at minimum

2 2

Google Web Accelerator
by Matthew Mastracci 06 May '05

06 May '05

To indulge my habit of trying the newest Google software releases under Wine, I decided to give the new Google Web Accelerator a shot with the latest CVS. The first issue that I ran into (patches sent to wine-devel!) was the lack of StgCreateStorageEx and StgOpenStorageEx. This seems to be used by Google to store their extra web cache data. Once I replaced the stubs with proper functions, the application started up and started caching data. From what I can tell, it even contacts the Google server for the compressed updates. It doesn't seem to "save time" in any way - I think this might have something to do with the inefficiency within the structured storage implementation (100% CPU for a short period of time as you request pages). My theory is that the application picks the request that returns first - Google's optimized version or the web page's response. It seems to die after a few minutes of browsing with what appears to be an async IO error. The strange thing is that the error code looks like a memory location rather than a winsock error: fixme:winsock:NtStatusToWSAError Status code 77ce16c0 converted to DOS error code 77ce16c0 fixme:winsock:WS2_async_send status: c0000120 [matthew@epsilon temp]$ cd /tmp/wine/dlls/winsock I tried to trace through what happens in an asynchronous send operation, but I couldn't figure out how the status of the response was translated back to the "->Internal" field of the OVERLAPPED structure. Any hints? Thanks, Matt.

2 1

New program: getsffile
by Vincent Béron 06 May '05

06 May '05

Sent to wine-devel to get feedback on initial idea and implementation. New program in programs/getsffile (Get Sourceforge File). It downloads a file from Sourceforge download section, finding a suitable mirror by itself. This should solve part of the mirroring problem we have for the Mozilla ActiveX control, to make it easy to install on demand, and can most probably be used by other similar things as well. You can also specify a preferred mirror in the registry (Software\\Wine\\getsffile, key SFPreferredMirror. If the file is not available from that mirror (mirror down, not yet synced, etc.), it'll try another one (up to 3 times). The list of mirrors is got from sf.net, it's not maintained in getsffile. Basically, to use it to get the Mozilla ActiveX control, what needs to be done is to actually put the control on sf (along with a zip containing 2 needed dlls, one of them is msvcp60.dll), and change the download logic in shdocvw to call getsffile for both files rather than do the download itself. The installation part is almost the same (it'd be nice if the zip would be installed at the same time, even nicer if it wouldn't be needed but that's Mozilla's part). Note that it's still not 100% proof, some mirrors give a 404 back and it's not properly detected. Is it possible to detect such things while using URLDownloadToFile? The whole dialog is ripped from shdocvw (Mike McCormack's work), the rest is my own development. Vincent

4 4

Re: Commercial support
by Peter Kovacs 06 May '05

06 May '05

>Rather than set threshholds on capacity, there might be a tiered >arrangement >whereby anybody can get a class D listing for nothing. Class C, B and >A >listings would cost $200, $1000, and $10000. The page would then be >ranked by >listing class, and within listing class by geography. How do you want to determine the different classes. If I pay 10.000$ I get listed on the Premium list? Or is it more that If I have more employees working on wine i pay more for being a official supporter? I am not sure if this is what the winhq should aim at. On the market it could work I do not know because I do not know how great the exsisting demand is. But we should be careful with lists. Every list is a official recommandation. And the wine Project should take care that these People do honestly contribute to wine. A general fee for all is better IMHO. We could make a fee 0f 200$ link the List to a profile where the Companies stats is listed. There we could make a Rubrik like the Company donated over X $ to the project. That would state the closeness and the support. You move up in the list if you collect enough points by producing code, patches and donation. Wich you can check on the profile. How bout that? >3) a link back to winehq.org from there site and not twenty pages into >there site. We could make a Button like Offical Wine support for the Commercial supporter. This button can be placed on the homepage. >7) if a banned party wants re-instatement they must pay a fine of >$25,000 and post a written apology to the community for there actions. It would be better if a official Wine Support Company signs a contract where it agrees to an penalty payment if violating the contract. The violation fee could be differ to the severity of the violation. This sounds serious to me. Because this is a two way road. We promise the company to treat them right and they ensure us to be honest on the project. Of course a contract is a bit more demanding then the simple list but they become the OFFICIAL Partner for wine. I think that is more worth then a fee. Greetings Peter

2 1

Re: Winelib's role in converting Windows applications
by Steven Edwards 06 May '05

06 May '05

Hi Ira, --- Ira Krakow <ikrakow_1999(a)yahoo.com> wrote: > For example, if the application requires PAM > authentication, or a Linux-based help system, these > modules would be separated out and encapsulated as > Winelib objects. I was thinking of using PAM > authentication as a good example, since it works for > any authentication scheme that the application > requires. > > This is the approach I plan to take. I welcome all > feedback. Another good example is from the UI point of view where you don't want users to have to deal with drive letters in a Unix env. Using winelib it would be possible to directly call GTK/GDK or KDE and use browse dialogs. Of course some work seems to be going on to add support for this directly to shell32 so someone else might know suggest a better way. Thanks Steven __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

1 0

Re: PATCH: add test for non existing directory during createfile
by Troy Rollo 05 May '05

05 May '05

On Fri, 6 May 2005 02:59, Marcus Meissner wrote: > I would like to have someone test this test on windows... > > I have the suspicion that Windows might create non-existing directories > in the middle. Testing on Win2k I get ERROR_PATH_NOT_FOUND.

1 0

Re: Regression in Half life
by fenix＠club-internet.fr 05 May '05

05 May '05

2 1

Re: Re: Regression in Half life
by fenix＠club-internet.fr 05 May '05

05 May '05

3 2

DCOM patch
by Mike Hearn 05 May '05

05 May '05

Hi Rob, I've attached the patch I was working on at WineConf. The test cases pass now but I haven't checked it against InstallShield yet: can you look it over? Sorry about the extraneous changes. thanks -mike

1 0

Re: Missing HAVE_V4L2 check
by Maarten Lankhorst 05 May '05

05 May '05

Francois Gouget wrote: > > Maarten, could you fix the following winapi_check warnings: > > dlls/avicap32/avicap32_main.c: HAVE_V4L2 is not declared as a conditional > dlls/avicap32/avicap32_main.c: HAVE_V4L2 is not declared as a conditional > > > The problem is that dlls/avicap32/avicap32_main.c checks for HAVE_V4L2 > but we lack the appropriate check in configure.ac and the macro > declaration in include/config.h. > > HAVE_V4L2 is not declared in wine itself, but by /usr/include/linux/videodev.h, which includes videodev2.h and defines HAVE_V4L2 if V4L2 is available, so in my opinion it doesn't need fixing..

3 3

Re: PATCH: add test for non existing directory during createfile
by Stefan Leichter 05 May '05

05 May '05

Am Donnerstag, 5. Mai 2005 18:59 schrieb Marcus Meissner: > Hi, > > I would like to have someone test this test on windows... > > I have the suspicion that Windows might create non-existing directories > in the middle. > > Ciao, Marcus > Hello Markus, the test succeeds on my NT4 box Bye Stefan

2 1

InstallShield status page on the wiki
by Mike Hearn 05 May '05

05 May '05

Hi, I created an InstallShield page on the new wiki: http://wiki.winehq.com/InstallShield Dimi, the <p> tags don't seem to create any bottom padding like they would normally so all the text seems squashed together even if they have newlines between them. Can this stylesheet problem be fixed? thanks -mike

3 5

Re: [patch] fix delete key on certain european keyboards
by Paul van Schayck 05 May '05

05 May '05

On 5/5/05, zhilla <zhilla(a)spymac.com> wrote: > sorry if double, resend... > well, this is just this: > http://bugs.winehq.org/show_bug.cgi?id=2400 > and should apply to today's cvs. > i AM NOT the author! I have no idea how correct this patch is but I see a few things wrong with the patch style. It's missing a Changelog entry. It uses c++/c99 comment style (//). And the patch is made from the dlls/x11drv/ dir and not the cvs root. Paul > --- keyboard.c.orig 2005-05-05 18:22:56.000000000 +0200 > +++ keyboard.c 2005-05-05 17:41:03.000000000 +0200 > @@ -1067,11 +1067,14 @@ > else > XLookupString(e, NULL, 0, &keysym, NULL); > > - if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF) > - && (e->state & NumLockMask)) > - /* Only the Keypad keys 0-9 and . send different keysyms > - * depending on the NumLock state */ > - return nonchar_key_vkey[keysym & 0xFF]; > + if (e->state & NumLockMask) // NumLock is active > + {if (keysym == 0xFFAC) // Numeric Del pressed > + return keyc2vkey[0x3B]; // comma > + if ((keysym >= 0xFFAE) && (keysym <= 0xFFB9) && (keysym != 0xFFAF)) > + /* Only the Keypad keys 0-9 and . send different keysyms > + * depending on the NumLock state */ > + return nonchar_key_vkey[keysym & 0xFF]; > + } > > TRACE_(key)("e->keycode = %x\n", e->keycode); > > >

1 0

Re: Cannot compile man pages outside source directory
by Alexandre Julliard 05 May '05

05 May '05

William Poetra Yoga H <williampoetra(a)yahoo.com> writes: > Why shouldn't we have absolute paths in makefiles? It makes it impossible to copy or move build trees around, that's very annoying. -- Alexandre Julliard julliard(a)winehq.org

1 0

Missing HAVE_V4L2 check
by Francois Gouget 05 May '05

05 May '05

Maarten, could you fix the following winapi_check warnings: dlls/avicap32/avicap32_main.c: HAVE_V4L2 is not declared as a conditional dlls/avicap32/avicap32_main.c: HAVE_V4L2 is not declared as a conditional The problem is that dlls/avicap32/avicap32_main.c checks for HAVE_V4L2 but we lack the appropriate check in configure.ac and the macro declaration in include/config.h. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Dieu dit: "M-x Lumi\xE8re". Et la lumi\xE8re fut.

1 0

Re: Cannot compile man pages outside source directory
by William Poetra Yoga H 05 May '05

05 May '05

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > > No, you don't want to put absolute paths in makefiles. c2man should be > fixed to load files from the source directory if they are not found in > the build directory. > Why shouldn't we have absolute paths in makefiles? OK, I'll take a look at c2man.pl and see what I can do (though I've never spoken Perl before). Or maybe someone more fluent in Perl can fix this? What I have in mind is add an option -S that gives the source directory (shouldn't be too difficult, right?) William Poetra Yoga Hadisoeseno __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

Re: winecfg: Add wine configuration tab
by Dimitrie O. Paun 05 May '05

05 May '05

On Thu, May 05, 2005 at 12:50:50AM -0500, James Hawkins wrote: > I used the options specified for [wine] in the Wine Options Status > page [1] to create a new wine options tab for winecfg. I think we intentionally omitted such a page before. The thinking is that these are really low-level settings that normal users shouldn't touch. Those who *need* to for whatever strange reason can use regedit to do so. This is why it is important to have an up-to-date status_options page to begin with, so that people at least have a chance of knowing what options are available (for those not accessible via winecfg). -- Dimi.

3 2

Re: winecfg: Add wine configuration tab
by Dimitrie O. Paun 05 May '05

05 May '05

On Thu, May 05, 2005 at 12:50:50AM -0500, James Hawkins wrote: > [1] http://winehq.org/site/status_options I'm afraid this page is a bit out of date. It needs lots of love, and I think it would be a worthwhile project to update it. -- Dimi.

1 0

Better PolyLine drawing
by Rein Klazes 05 May '05

05 May '05

Hi, cc to wine-devel: I may overlooked something here. The patch fixes a problem in BigJig a jigsaw puzzle game (free download at www.lenagames.com) when it generates the pieces. The jigsaw piece shapes are generated with a series of short (5-7 points) Polyline calls, followed by a call to FloodFill. Unfortunately in Wine there are sometimes gaps between the polyline segments, leaking the floodfill. In Windows if a line or polyline is drawn from x1,y1 to xn,yn , the pixel at x1,y1 is always painted and the one at xn,yn not (unless it is also painted as another part of the segment), that guarantees that there are no gaps. X11DRV_PolyLine refuses to use the pen if the pen width is zero, it changes the width to 1 instead. This causes 'X' to use an alternate line drawing algorithm, more focused on pleasing appearance then on details like mentioned above. Setting the pen width to zero make all the problems go away. I do not know why the pen width is set to zero, this came into wine somewhere in 1998 before the change to cvs. Arguments against it are: - line drawing with pen width 1 are not like in Windows, in contrast to width 0 are very much like in Windows; - line drawing with pen width 1 is slower; - PolyPolyLine, LineTo and all other algorithms in wine do not do this; - Xlib programming manual recommends not to mix pen with 0 and pen width 1 drawing. I have looked at this both on a Debian XFree86 system and a Suse 9.2 with XOrg. Changelog: dlls/x11drv : graphics.c, pen.c Don't set the pen width to 1 in X11DRV_PolyLine. Rein.

1 0

GetExitCodeProcess always returns 1
by Igor Sysoev 05 May '05

05 May '05

2 years ago I reported that on FreeBSD Wine-20030508's GetExitCodeProcess() always returns 1: http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html It was fixed by patch: http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html and I used the patched Wine-20030508 all the time to run MSVC, OpenWatcom C, and Borland C in a command line. However, when I try to run dmc.exe, sc.exe, or make.exe from Digital Mars C/C++ Compiler, I always see the message: wine: Unhandled exception (thread 0009), starting debugger... I build Wine-20050310, but it has the same two problems: 1) GetExitCodeProcess() always returns 1 on FreeBSD 5.3, 2) and wine could not run Digital Mars C/C++ Compiler. Digital Mars C/C++ Compiler is could be downloaded here: http://www.digitalmars.com/download/freecompiler.html Igor Sysoev http://sysoev.ru/en/

2 1

Cannot compile man pages outside source directory
by William Poetra Yoga H 05 May '05

05 May '05

I realized today that we can't compile man pages outside the source directory, c2man complains about being unable to find .c files. I modified a line in dlls/Makedll.in: $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) so that it becomes: cd $(SRCDIR) && $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) Then, because documentation/man3w should be in the build directory, we have to modify TOPSRCDIR and TOPOBJDIR for the makefiles. I modified them to: TOPSRCDIR = @abs_top_srcdir@ TOPOBJDIR = @abs_top_builddir@ Is this correct? I'm testing it (my machine's slow) to see if it breaks anything. I've just done for i in `find -name Makefile.in` do cat $i | sed \ -e s/TOPSRCDIR = .*/TOPSRCDIR = @abs_top_srcdir@/ \ -e s/TOPOBJDIR = .*/TOPOBJDIR = @abs_top_builddir@/ \ > $i.new cat $i.new > $i rm $i.new done and the patch is quite large, about 130k, so maybe I won't post it here (straight to wine-patches if it's ok). Just the first 2: Index: Makefile.in =================================================================== RCS file: /home/wine/wine/Makefile.in,v retrieving revision 1.161 diff -u -p -r1.161 Makefile.in --- Makefile.in 2 Mar 2005 12:18:55 -0000 1.161 +++ Makefile.in 4 May 2005 10:19:18 -0000 @@ -17,8 +17,8 @@ # Directories -TOPSRCDIR = @top_srcdir@ -TOPOBJDIR = . +TOPSRCDIR = @abs_top_srcdir@ +TOPOBJDIR = @abs_top_builddir@ SRCDIR = @srcdir@ VPATH = @srcdir@ LIBEXT = @LIBEXT@ Index: dlls/Makedll.rules.in =================================================================== RCS file: /home/wine/wine/dlls/Makedll.rules.in,v retrieving revision 1.71 diff -u -p -r1.71 Makedll.rules.in --- dlls/Makedll.rules.in 8 Mar 2005 16:55:26 -0000 1.71 +++ dlls/Makedll.rules.in 4 May 2005 10:19:18 -0000 @@ -61,13 +61,13 @@ $(MAINSPEC).c: $(MAINSPEC) $(RC_SRCS:.rc # Rules for auto documentation man: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + cd $(SRCDIR) && $(C2MAN) -o $(TOPOBJDIR)/documentation/man$(api_manext) -R$(TOPOBJDIR) -S$(api_manext) $(INCLUDES) $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) doc-html: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) $(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + cd $(SRCDIR) && $(C2MAN) -o $(TOPOBJDIR)/documentation/html -R$(TOPSRCDIR) $(INCLUDES) -Th $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) doc-sgml: $(C_SRCS) - $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR) $(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) + cd $(SRCDIR) && $(C2MAN) -o $(TOPOBJDIR)/documentation/api-guide -R$(TOPSRCDIR) $(INCLUDES) -Ts $(MAINSPEC:%=-w %) $(SPEC_SRCS16:%=-w %) $(C_SRCS) $(C_SRCS16) .PHONY: man doc-html doc-sgml William Poetra Yoga Hadisoeseno __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 3

Re: unix filenames in notepad
by William Poetra Yoga H 05 May '05

05 May '05

--- Paul van Schayck <polleke(a)gmail.com> wrote: > We do need this for winecfg. If you want to setup virtual drive you do > want to see the full unix fs. Winecfg needs to have to unix paths. > Putting conversion code in winecfg was not really acceptable, an > extension to was. > > This extension will become even more valuable because we want winecfg > (or wine in particular) to start without having any virtual drive. > People might have removed all drives (with winecfg). > > Paul > But surely, for this particular winecfg program we don't need to add extensions to all of wine, right? I mean, if we extend the API this way, more will come. And it's actually easier to extend than to trim down, so I say we'd better not add this extension. About winecfg, why not have a unix, text-based version of winecfg? More like Linux's make config IMO. Then when the drives are already set up, we can run the 'real' winecfg. William Poetra Yoga Hadisoeseno __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

problems with electronics workbench (ewb)
by Zé 05 May '05

05 May '05

When i run Electronic work bench exe with wine i get this: ]$ wine WEWB32.EXE Loading required GL library /usr/X11R6/lib/libGL.so.1.2 fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name "WEST", bias=-60 and dst=1 to an entry in TZ_INFO. Please add appropriate entry to TZ_INFO and submit as patch to wine-patches fixme:font:WineEngRemoveFontResourceEx :stub And when using it, if i click in some icon then it stays black. Any help? Note: im using last wine release -- Zé Linux user #378762

1 0

Re: DirectX 9 patches
by Vincent Béron 05 May '05

05 May '05

Hi Jesse, The failures you see are only whitespace changes. Either make patch skip whitespace changes, or apply the following patch to Olivier's patch prior to apply it to your tree. Vincent

3 6

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