wine-devel January 2005

wine-devel@winehq.org

149 participants
343 discussions

Re: [LostWages] Resurrection of the AddRef and Release code cleanup.
by James Hawkins 08 Jan '05

08 Jan '05

On Sat, 08 Jan 2005 16:00:38 +0100, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > Hi, > > this Project was apparently not finished. > > Changelog: > make the AddRef and Release code cleanup active again. > > Cheers, > > Paul Vriens > It would be nice to add back in the two other workers (me and Joris). -- James Hawkins

1 0

Re: [dx9-20] RenderTarget support
by Oliver Stieber 08 Jan '05

08 Jan '05

--- Ann and Jason Edmeades <us(a)the-edmeades.demon.co.uk> wrote: > This clears out the next blocking part of the d3d9 / > wined3d support and has > been a real pain to implement. I think I've got it > right now, and it adds > support for render targets but more importantly the > beginnings of a front > and back buffer which lots of the code relied upon. > > Unfortunately I couldn't get this next step any > smaller than the patch > attached.... > > Major areas still to go - textures and pixel / > vertex shader support. I'm > moving onto the textures next... > > Changelog > > Add render target support, and ensure there is a > front and back buffer > created during device creation > > Jason > > Hi, I've just done more-or-less exactly the same this weekend with a couple of differences. I've merged all the creation surface code into a single createSurface function that is called with different parameters/flags to create a backbuffer, PlainOffscreenSurface or rendertarget etc... This should mean that you only require one call-back function for CreateDevice in WineD3D. I'll merge your patch with what I've got and see how it goes. As soon as I'm happy with how wine's and directX work I can stop duplicating what you've done and start moving onto a more co-operative development, or moving DirectX8 over to using WineD3d. So far I can run Pirates! and a few of the demos from http://www.codesampler.com/dx9src.htm, but without textures. Pirates uses DirectX 9c but doesn't do anything too fancy and runs without crashing so it seems good for testing. Many of the demos at http://www.codesampler.com/dx9src.htm have OpenGL versions and since I don't know OpenGL or DirectX (but can hack a good Dos demo) it seemed a good place to start. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

directX 9.
by Oliver Stieber 08 Jan '05

08 Jan '05

Hi, I've been having a look at DirectX 9 over the weekend as a bit of a learning excersize. So far I've managed to get enough implemented in d3d9 to run Pirates! [without textured polygons] and have stated moving everything over to wined3d so that the textures will work. Unfortunatly I've become stuck assigning a DirectX 9 parent to a surface created in wined3d. Can anybody help? ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

Re: Native unix style paths in wine common dialogs
by Dimitrie O. Paun 08 Jan '05

08 Jan '05

On Tue, Jan 04, 2005 at 11:22:00AM -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. This would be much better as a registry setting, not a compile time option. -- Dimi.

3 5

Re: windows/clipboard.c: Get rid of W->A calls
by Dmitry Timoshkov 08 Jan '05

08 Jan '05

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -310,15 +335,24 @@ static void intern_atoms(void) > names = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*names) ); > atoms = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*atoms) ); > > - for (format = ClipFormats, i = 0; format; format = format->NextFormat) > - if (!format->drvData) names[i++] = format->Name; > + for (format = ClipFormats, i = 0; format; format = format->NextFormat) { > + if (!format->drvData) { > + len = WideCharToMultiByte(CP_ACP, 0, format->Name, -1, NULL, -1, 0, 0); > + names[i] = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); > + WideCharToMultiByte(CP_ACP, 0, format->Name, -1, names[i++], len, 0, 0); You have to use CP_UNIXCP to convert unicode strings in order to pass them to the X11/unix system (here and everywhere else). -- Dmitry.

1 0

Re: windows/winproc.c: Get rid of HEAP_strdupWtoA calls
by Dmitry Timoshkov 08 Jan '05

08 Jan '05

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -1010,9 +1009,15 @@ static INT WINPROC_MapMsg32WTo32A( HWND > case LB_DIR: > case LB_ADDFILE: > case EM_REPLACESEL: > - if(!*plparam) return 0; > - *plparam = (LPARAM)HEAP_strdupWtoA( GetProcessHeap(), 0, (LPCWSTR)*plparam ); > - return (*plparam ? 1 : -1); > + if(*plparam) { > + LPSTR buf; > + int len = WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, NULL, 0, 0, 0); > + buf = HeapAlloc(GetProcessHeap(), 0, len*sizeof(CHAR)); > + WideCharToMultiByte(CP_ACP, 0, (LPWSTR)*plparam, -1, buf, len, 0, 0); > + *plparam = (LPARAM)buf; > + return 1; > + } > + return 0; It would be helpful to keep the test in the case of a buffer allocation failure here and everywhere else (and perhaps add the missing tests). -- Dmitry.

1 0

Re: USER32: GetScrollBarInfo
by Alexandre Julliard 08 Jan '05

08 Jan '05

Vitaly Lipatov <lav(a)etersoft.ru> writes: > --- scroll.c 8 Dec 2004 18:06:15 -0000 1.3 > +++ dlls/user/scroll.c 4 Jan 2005 14:27:08 -0000 > @@ -27,7 +27,7 @@ > * the specification mentioned above. > * If you discover missing features, or bugs, please note them below. > * > - * TODO: > + * TODO: needs check follow realized functions: > * - GetScrollBarInfo > * - SBM_GETSCROLLBARINFO > * - SCROLLBARINFO > @@ -1424,10 +1461,12 @@ > case SBM_GETSCROLLINFO: > return SCROLL_GetScrollInfo(hwnd, SB_CTL, (SCROLLINFO *)lParam); > > + case SBM_GETSCROLLBARINFO: > + return GetScrollBarInfo(hwnd, SB_CTL, (SCROLLBARINFO *)lParam); You have to do that the other way around, GetScrollBarInfo should send a SBM_GETSCROLLBARINFO message, similar to what GetScrollInfo does. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: wine/ include/Makefile.in dlls/user/user32.spe ... (CVS compile fix)
by Mike McCormack 08 Jan '05

08 Jan '05

This patch adds GetScrollBarInfo to user32.spec, but adds no implementation... Here's a temporary fix for those wondering why the CVS won't compile until the rest of Vitaly's scrollbar patch is committed. Mike Alexandre Julliard wrote: > ChangeSet ID: 15265 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2005/01/07 11:15:30 > > Modified files: > include : Makefile.in > dlls/user : user32.spec misc.c > Added files: > include : winnls32.h > > Log message: > Diego Pettenò <flameeyes(a)users.berlios.de> > Added stub implementation for WINNLS* functions. > > Patch: http://cvs.winehq.org/patch.py?id=15265 > > Old revision New revision Changes Path > 1.151 1.152 +1 -0 wine/include/Makefile.in > 1.92 1.93 +4 -4 wine/dlls/user/user32.spec > 1.19 1.20 +34 -3 wine/dlls/user/misc.c > Added 1.1 +0 -0 wine/include/winnls32.h ? dlls/user/timer.c ? dlls/user/tests/child.c ? dlls/user/tests/child.ok ? dlls/user/tests/timer.c ? dlls/user/tests/timer.ok Index: dlls/user/painting.c =================================================================== RCS file: /home/wine/wine/dlls/user/painting.c,v retrieving revision 1.16 diff -u -r1.16 painting.c --- dlls/user/painting.c 4 Jan 2005 12:11:09 -0000 1.16 +++ dlls/user/painting.c 8 Jan 2005 02:53:48 -0000 @@ -570,3 +570,10 @@ } return ret; } + +BOOL WINAPI SetLayeredWindowAttributes(HWND hwnd, COLORREF crKey, + BYTE bAlpha, DWORD dwFlags) +{ + FIXME("%p %08lx %02x %08lx\n", hwnd, crKey, bAlpha, dwFlags); + return TRUE; +} Index: dlls/user/user32.spec =================================================================== RCS file: /home/wine/wine/dlls/user/user32.spec,v retrieving revision 1.93 diff -u -r1.93 user32.spec --- dlls/user/user32.spec 7 Jan 2005 17:15:30 -0000 1.93 +++ dlls/user/user32.spec 8 Jan 2005 02:53:49 -0000 @@ -294,7 +294,7 @@ @ stdcall GetPropA(long str) @ stdcall GetPropW(long wstr) @ stdcall GetQueueStatus(long) -@ stdcall GetScrollBarInfo(long long ptr) +#@ stdcall GetScrollBarInfo(long long ptr) @ stdcall GetScrollInfo(long long ptr) @ stdcall GetScrollPos(long long) @ stdcall GetScrollRange(long long ptr ptr) @@ -521,6 +521,7 @@ @ stdcall SetInternalWindowPos(long long ptr ptr) @ stdcall SetKeyboardState(ptr) @ stdcall SetLastErrorEx(long long) +@ stdcall SetLayeredWindowAttributes(long long long long) @ stdcall SetLogonNotifyWindow(long long) @ stdcall SetMenu(long long) @ stdcall SetMenuContextHelpId(long long) Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.39 diff -u -r1.39 win.c --- dlls/user/tests/win.c 27 Dec 2004 17:26:37 -0000 1.39 +++ dlls/user/tests/win.c 8 Jan 2005 02:53:49 -0000 @@ -2114,6 +2114,82 @@ ok( !ret, "message %04x available\n", msg.message); } +static void test_child_window() +{ + WNDCLASSA cls,child_cls; + char className[] = "parentclass"; /* To make sure className >= 0x10000 */ + char winName[] = "parent window"; + char childclassName[] = "childclass"; /* To make sure className >= 0x10000 */ + char childwinName[] = "child window"; + HWND hWnd, hChild; + HINSTANCE hInstance = GetModuleHandleA( NULL ); + + cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + cls.lpfnWndProc = DefWindowProcA; + cls.cbClsExtra = 0; + cls.cbWndExtra = 0; + cls.hInstance = 0; + cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + cls.hbrBackground = GetStockObject (WHITE_BRUSH); + cls.lpszMenuName = 0; + cls.lpszClassName = className; + + ok (RegisterClassA (&cls), "unable to register class") ; + + hWnd = CreateWindowA (className, winName, + WS_OVERLAPPEDWINDOW , + CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, + 0, + hInstance, 0); + + ok(hWnd != 0, "Couldn't create parent window"); + + child_cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; + child_cls.lpfnWndProc = DefWindowProcA; + child_cls.cbClsExtra = 0; + child_cls.cbWndExtra = 0; + child_cls.hInstance = 0; + child_cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION); + child_cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW); + child_cls.hbrBackground = GetStockObject (GRAY_BRUSH); + child_cls.lpszMenuName = 0; + child_cls.lpszClassName = childclassName; + + ok (RegisterClassA (&child_cls) , "unable to register child class"); + + /* NOTE: WS_POPUP should override WS_CHILD */ + + hChild = CreateWindowExA ( + 0, childclassName, childwinName, + WS_POPUP | WS_CHILD | WS_CLIPCHILDREN, + 50, 50, 50, 100, hWnd, + 0, hInstance, 0); + + ok(hChild != 0, "Couldn't create child window"); + + ok(!SetActiveWindow(hChild), + "Can activate without parent window"); + + ok(GetAncestor(hChild, GA_PARENT) == GetDesktopWindow(), + "ancestor is not the desktop window"); + + ShowWindow (hWnd, SW_SHOW); + UpdateWindow (hWnd); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + ShowWindow (hChild, SW_SHOW); + UpdateWindow (hChild); + + ok(SetActiveWindow(hChild) != 0, + "Can't activate window with parent active"); + + DestroyWindow(hChild); + DestroyWindow(hWnd); +} + static void test_mouse_input(HWND hwnd) { RECT rc; @@ -2179,6 +2255,8 @@ START_TEST(win) { + test_child_window(); + pGetAncestor = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetAncestor" ); pGetWindowInfo = (void *)GetProcAddress( GetModuleHandleA("user32.dll"), "GetWindowInfo" );

1 0

Re: wineloader: call wineprefixcreate with explicit WINEPREFIX
by Tobias Burnus 07 Jan '05

07 Jan '05

Hello, Crestez Leonard wrote: > +if [ -z $WINEPREFIX ] > +then While my bash accepts this, Tru64 UNIX's POSIX shell does not. Please use "$WINEPREFIX" instead. Tobias

2 1

Re: MSVCRT: Re-implement *printf
by Juan Lang 07 Jan '05

07 Jan '05

Style point: (*pointer).whatever is written a bit more easily as pointer->whatever. That'd make your new patch a good bit more readable. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

4 3

re: Announcing security hardened kernels for testing
by Mike Hearn 07 Jan '05

07 Jan '05

Hi, Thanks for the great info. I'll CC this to wine-devel as I think it's of general interest, I hope you don't mind. For context, PaX is a set of security patches for Linux which lock down the system in a similar manner to exec-shield and SELinux. I say similar manner, because PaX seems to go further than these systems do - in fact from what I've read it seems to be the 'gold standard' in security patches. I'll quote the whole email and reply inline. This thread started on ubuntu-devel after one Ubuntu developer said they were experimenting with PaX, and I asked what the differences were between it and exec- shield (with which the community seems to have more experience) and why it was chosen. So I was pointed towards this thread: http://lists.debian.org/debian-devel/2003/11/msg00206.html in which the PaX author and Ingo Molnar who did exec-shield discuss the differences. On Wed, 2005-01-05 at 13:37 +0100, pageexec(a)freemail.hu wrote: > Hello, > > just ran across this thread on the ubuntu-devel list and have > a few observations: > > 1. PaX cares about backwards compatibility as much as it cares about > security, the best compromise we could make is that one can mark > executables to be exempt from PaX enforcements (and you should > have known about this as we'd talked about PaX+wine last year...). OK. I don't remember this thread I'm afraid but I do recall that you can exempt particular programs from PaX, so if a distribution wanted to integrate that it'd have to mark Wine as exempt by default. Presumably if WineHQ/CodeWeavers were to ship binary packages we'd have to do the same to work on such a distribution. But it's just an ELF flag right? > 2. as of the 20041201 snapshot of wine, it needs to be exempt from > at least ASLR [1], because it still makes some invalid assumptions > about the address space: > > - the highest mapping in the address space may not be the stack, > nor is the highest mapping (be that the stack or something > else) supposed to extend to the end of the userland address > space. the end result of this assumption is that some piece > of code in the preloader enters an infinite loop requesting > (but never getting) anon mappings above TASK_SIZE (0xc0000000 > typically). excerpt from an strace: > > mmap2(0xbffe0000, 262144, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ec0000 > munmap(0x77ec0000, 262144) = 0 > mmap2(0xbffe0000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xbffe0000 > mmap2(0xc0000000, 131072, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ee0000 > munmap(0x77ee0000, 131072) = 0 > mmap2(0xc0000000, 65536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x77ef0000 > munmap(0x77ef0000, 65536) = 0 > > the last lines then repeat indefinitely as the kernel would > never give out the request address, even with MAP_FIXED. We do this because some Windows programs and DLLs cannot cope with getting pointers >2gig, so we need to ensure that the kernel does not give us mappings above this point. The only way to do this currently is to do an iterative reservation to map as much of this address space as possible which is what you're seeing here. > - the above mentioned infinite loop also highlighted another bad > assumption wine makes: mmap() without MAP_FIXED but with a non-0 > hint is under no obligation to observe the hint and give you a > mapping at that address, under PaX it doesn't do so explicitly. > excerpt from an strace: > > mmap2(0x81000000, 1034813440, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3a420000 > munmap(0x3a420000, 1034813440) = 0 > mmap2(0x81000000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x81000000 > mmap2(0x9fd70000, 517406720, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x59190000 > munmap(0x59190000, 517406720) = 0 > mmap2(0x9fd70000, 258670592, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x9fd70000 > > as you can see, wine insists on an address until it gets it, > without using MAP_FIXED. We have no choice in the matter, I think we can't use MAP_FIXED as that'd risk blowing away any mappings already made above the 2gig boundary. Actually this code was originally written to support the 4G/4G VM patch that was put into Fedora for a while (it's gone now). > 3. there's at least /usr/lib/wine/ntdll.dll.so which is marked with > an executable PT_GNU_STACK program header, suggesting that it > needs an executable stack (or there's some build problem). Last time I looked documentation on exactly what triggers this flag is scarce or non-existant. I remember asking Ingo if inline assembly still generated it and the answer back then was no, but I have no idea why gcc has decided it's needed now. If you look at ntdll in the sources: http://source.winehq.org/source/dlls/ntdll/ It's fairly harmless, there is some assembly in there but I don't remember seeing any code which assumed an executable stack. > this > alone would make wine fail under a PaX kernel as PT_GNU_STACK is > completely ignored there (because it's the wrong solution for the > wrong problem), nor is it allowed to generate code at runtime > (this applies to apps on which PaX is enforced of course, one can > always disable these on a per-executable basis). I'm afraid Wine cannot operate in an environment that doesn't allow us to map pages as executable and fill them with generated code. This technique is: a) Used by some Windows programs b) Used by the Wine DLL loader c) Required to implement DCOM universal interface proxies So if PaX denies this as a matter of course then it will never work. Having read the thread with Ingo I must say I agree with him that runtime code generation is a legitimate technique and not a bug. > i also have memories from about a year ago that kernel32.so had > some executable code snippets (some thunking code?) in .data or > some other otherwise non-executable area, that of course wouldn't > (and didn't) work under PaX either. back then Alexandre Julliard > suggested that this wasn't easy to rewrite (by also making the > now static code text reloc free) - has this been done since then? I don't think so, but I don't remember this thread either. > i also have strace excerpts that show how wine wanted to create > writable and executable memory, suggesting that it still wants to > generate code at runtime and this is how it fails under PaX (which > prevents runtime code generation by default): > > mmap2(NULL, 1179648, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fee0000 > munmap(0x7fff0000, 65536) = 0 > mprotect(0x7fee0000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EACCES (Permission denied) > munmap(0x7fee0000, 1114112) = 0 > write(2, "wine: failed to create the proce"..., 40wine: failed to create the process heap > ) = 40 > > on a sidenote, XP SP2 makes the default heap non-executable as > well, so if the above is the result of wanting to be compatible > with Windows, you may want to rethink it for the future. I'm not sure why it is, but yes I expect it's because some programs rely on it. Service Pack 2 may well make the default process heap NX but it also has a huge infrastructure in place to deal with backwards compatibility concerns, including a large database of badly behaved apps, user-accessible GUIs to disable the protections and I believe it also has code to catch NX faults (on hardware that supports that) and ask the user if they wish to disable the protections for that application. > 4. it would be nice if wine-preloader and wine-pthread had a configurable > base address, the current default makes them impossible to use > under the faster non-executable method of PaX/i386 (which halves > the userland address space, [2]). They have to be fixed otherwise the kernel may place them in the middle of a reserved area which would cause initialisation to fail. This cannot be changed. > so, right now wine can't run with a randomized address space, i have > yet to test if it can get away without generating code at runtime > and/or having writable/executable memory. It can't and I don't see any way to make it able to operate under such conditions in future. Is there a way to brand the binaries as excluded from PaX at build time without a special tool? If not would you be willing to submit a build system patch to detect the branding tool on PaX systems and use it on the relevant binaries automatically? thanks -mike

4 8

Re: winecfg fixes, now with actual patch
by Mike Hearn 07 Jan '05

07 Jan '05

Crestez and I talked about this patch on #winehackers, and there are a few things that need to be changed (let's ignore the formatting changes here): - There was code to avoid a crash when the desktop value read from the registry doesn't have an x in it for some reason (yes this does happen) but this patch deletes it - mode_to_label is for translated, UI strings, not for stuff to be put in the registry. It does say this in a comment but I can appreciate that it looks at first glance like pointlessly duplicated code. We should fix this, especially as right now winecfgs translation support is weak. But for now the replacement of a case statement with a mode_to_label call is incorrect. thanks -mike On Fri, 07 Jan 2005 16:44:11 +0200, Crestez Leonard wrote: > This patch makes a bunch of small winecfg fixes. Since most of them are > just a few lines in length I don't think it's worth splitting them. > > Sorry for forgetting the attachment. > > Changelog: > winecfg: fix add application (memory error) > winecfg: fix apply button lighting up in audio tab > winecfg: fix video tab(crash when checking desktop, apply button not > lighting up > winecfg: fix apply button in libraries tab, fix memory leak in > parse_override, remove horrible abuse of macros in set_dllmode

1 0

Re: [winegcc] Include .so files when calling winebuild
by Dimitrie O. Paun 07 Jan '05

07 Jan '05

On Wed, Jan 05, 2005 at 01:58:45PM +0100, Peter Berg Larsen wrote: > +void strarray_set(strarray* arr, int index, const char* str) > +{ > + if (index >= arr->maximum) > + { > + arr->maximum = index+10; > + arr->base = xrealloc(arr->base, sizeof(*(arr->base)) * arr->maximum); > + memset(&(arr->base[arr->size]),0,sizeof(*(arr->base)) * (arr->maximum - arr->size)); > + } > + arr->base[index] = str; > + if (arr->size <= index) > + arr->size = index+1; > +} Do we really need this strarray_set() function? Even if you do, it should _not_ shorten the array. -- Dimi.

2 3

tools/widl/write_msft.c warnings
by Gerald Pfeifer 07 Jan '05

07 Jan '05

The addition of tools/widl/write_msft.c added the following four warnings, basically doubling the number of warnings we are getting with GCC 3.4. write_msft.c:582: warning: `ctl2_alloc_importinfo' defined but not used write_msft.c:620: warning: `ctl2_alloc_importfile' defined but not used write_msft.c:918: warning: `ctl2_find_nth_reference' defined but not used write_msft.c:1382: warning: `set_help_file_name' defined but not used Would you mind looking into this? Gerald

1 0

Re: [AppDB] remove even more unused functions
by Tony Lambregts 07 Jan '05

07 Jan '05

Jonathan Ernst wrote: > This patch removes unused functions from include/util.php > > Changelog: > - remove unused functions in include/util.php > > Files changed: > - include/util.php I believe you got carried away... two of those functions are used by make_bugzilla_version_list(): openbugzilladb() and closebugzilladb() values() is used in qclass.php which is used in stdquery.php which is used by query_appbyvendor.php, pn_buttons.php, appversion,php and a few others. If those files are not used then we should remove them first.

1 0

MSVCRT printf functions
by Aneurin Price 07 Jan '05

07 Jan '05

I've gone over this patch again, fixed any bugs I could find, and tried to address the points made regarding readability. Hopefully the coding style should now be much improved, so could anyone who knows about such things give it a look over? If there's not too much of a problem there I'll fix up any points made and submit to wine-patches with the appropriate notes. I am still a little unsure about a couple of points; ones I can remember off the top of my head: probably insufficient attribution for code derived from file.c, since I have no idea who wrote the functions I used (these are specified in the copyright notice for printf.c, BTW). It's also pretty big; I presume it's okay to have this much in one file, but maybe not. Either way it can't be broken down into smaller patches since it's one big change. Thanks, Aneurin Price

2 1

Re: MSVCRT printf functions
by Juan Lang 06 Jan '05

06 Jan '05

Hi Aneurin, some style comments on your patch: +<<<<<<< file.c +======= This shouldn't be in your patch. +typedef struct +{ + int flags; + unsigned int width; + __int64 precision; + const MSVCRT_wchar_t *input; + MSVCRT_wchar_t *output; + int HeapAlloced; + union + { + int intIn; + double doubleIn; + }; +} PRINTF_SPECIFIER; The HeapAlloced flag shouldn't be upper-cased. A BOOL may make more sense too. +PRINTF_SPECIFIER integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER specifier) This calling convention is a little strange. It's more typical in C not to return "large" things on the stack, but to use pointers instead. Since you use the specifier in the following way: + specifier = charprocessw(va_arg(*args, int),specifier); you may want to make the specifier an in/out parameter passed by pointer instead, e.g. void integertostringw(va_list *args, MSVCRT_wchar_t digits[], PRINTF_SPECIFIER *specifier) The calls would then look like: + charprocessw(va_arg(*args, int),&specifier); Finally, your internal functions should be made static. --Juan __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

1 0

RC file translation via winehq?
by Mike McCormack 06 Jan '05

06 Jan '05

Hey All you web programmers out there! How hard to you think it would be to rig up a web page for people to do translations for wine on? Have a web page (translate.winehq.org?) into which we feed in all the .rc files and maybe even parts of WineHQ, and show the translations for each language and bits that are missing ... then accumulate all the bits of translation somehow so they can be sumbitted back to wine-patches. I think there's plenty of people who'd do translation work for us if they didn't have to bother learning about how to submit patches or understand how .rc files work. Mike

7 8

questions for safedisc implementation (AJ pleas read)
by Ivan Leo Puoti 06 Jan '05

06 Jan '05

Chances are I'll be quite busy during the next week, but Laurent Pinchart, the guy who originally reverse engineered safedisc, asked a few questions on IRC about implementing support for the native safedisc driver, feedback, particularly from AJ, would be very appreciated, here is the IRC log. peter_pan is Laurent. < peter_pan> I'm trying to figure out how to implement "kernel services" in wine. a kernel service is a device driver which is loaded by StartService and runs in kernel space. the driver has a DriverEntry entry point, which, unlike regular services, seem to return immediately after registering callbacks. this might not always be the case though 23:41 < peter_pan> after DriverEntry returns, the process started by StartService currently exits. how should I handle calls to the callbacks registered by IoCreateDevice inside DriverEntry ? should they run in the calling process space, the wine server space or the service process space ? 23:41 < peter_pan> in the first case, I have to map the kernel service in all wine processes space, as the service can make use of global data (in windows the kernel service only exists once inside the kernel) 23:41 < peter_pan> in the third case, I will have to find a way to keep the service process alive (in a stopped state) after DriverEntry returns, and use wineserver and ptrace to call the callbacks from the user processes. this will imply inter process communication and inter process synchronization. or maybe I could just use IPC and keep the kernel space process waiting on a pipe or something. this wouldn't work for a kernel service which doesn't return from DriverEntry immediately, but I don't know if those exist. 23:41 < peter_pan> does anyone have any thought to share ? 23:47 <@Thunderbird> hi 23:47 <@Thunderbird> guess it needs to happen in wineserver 23:47 <@Thunderbird> better ask julliard about it 23:47 <@Thunderbird> if he is still awake 23:48 < peter_pan> he's been idling for 1 hour and 45 minutes 23:49 < peter_pan> are you there alexandre ? 23:50 <@Thunderbird> td might be online too .. 23:51 * TD is gone to a film, like NOW 23:51 <@TD> bye .... 23:51 < peter_pan> no luck either 23:51 < peter_pan> lol 23:52 <@Thunderbird> isn't there some function in wineserver that runs all the time? 23:53 < peter_pan> my opinion is that DriverEntry should be called in a separate process like it is now, as it can block, and that IoCreateDevice should map the image in the wineserver process space and update the callback table. the problem is that the changes to data sections made in DriverEntry must be somehow shared with wineserver. 23:55 < peter_pan> StartService will have to be modified to handle kernel services. it uses CreateProcess now, which calls DriverEntry (the entry point) with wrong parameters. we would need a way to mark a process as being a kernel process or a user process 23:57 <@Thunderbird> I guess that is good but I'm not qualified enough to say something about that 23:58 < peter_pan> using wineserver to host the driver callbacks would serialize the calls, which might not be a good thing to do. in windows, syscalls are executed in kernel space, but in the context of the calling process. it might be a good idea to do that here too. is the windows kernel interruptible ? can a process call a driver function while another process sleeps in the same functions, or while another process executes inside that function on another CPU ? 23:59 <@Thunderbird> how is this stuff handled in reactos? 23:59 < peter_pan> I have no idea 23:59 < peter_pan> maybe I should ask them

2 1

Re: WPP: Fixed 'out of tree' compilation
by Alexandre Julliard 06 Jan '05

06 Jan '05

Jacek Caban <jack(a)itma.pwr.wroc.pl> writes: > --- libs/wpp/ppy.y 1 May 2003 03:16:21 -0000 1.1 > +++ libs/wpp/ppy.y 30 Dec 2004 10:11:39 -0000 > @@ -537,7 +537,10 @@ static int boolean(cval_t *v) > static marg_t *new_marg(char *str, def_arg_t type) > { > marg_t *ma = pp_xmalloc(sizeof(marg_t)); > - ma->arg = str; > + if(str) > + ma->arg = pp_xstrdup(str); > + else > + ma->arg = NULL; > ma->type = type; > ma->nnl = 0; > return ma; > @@ -569,7 +572,7 @@ static mtext_t *new_mtext(char *str, int > if(str == NULL) > mt->subst.argidx = idx; > else > - mt->subst.text = str; > + mt->subst.text = pp_xstrdup(str); AFAICS the string is already duplicated everywhere these functions are called, so you are adding a memory leak here. Does this patch really make a difference in the behavior? -- Alexandre Julliard julliard(a)winehq.org

3 4

DCOM roadmap
by Mike Hearn 06 Jan '05

06 Jan '05

I thought I'd post an update on where Rob and I are up to, and where we're going. This is the plan that I have in my head, Rob may want to do things in a slightly different order etc so don't be surprised if we change some stuff around as a result of this email. We're currently reworking, extending and in some cases rewriting the code Marcus wrote originally to work more like native DCOM does. This means that new features and major improvements are *not* going to happen for a while, because before we can extend our support for DCOM we have to migrate to the same architecture that Microsoft use internally. This has several benefits: 1) It saves us design work, because MS already did it 2) It's the only way to be wire compatible in the long run 3) It means the documentation (like Essential COM etc) is already written Getting to a more native-style architecture has already been started, but won't be finished for a while. Here are the steps we need to take, the ones marked with a * are already done, - means they are still to do. - Replace the wine_marshal_id structure with [STD]OBJREF. This is necessary because the Microsoft internal interfaces like IOXIDResolver and IRemoteActivation operate in terms of OBJREFs. An OBJREF is a marshalled interface pointer, so by using the same structure we're able to be wire-compatible with MS. * Switch apartments to be identified by OXIDs * Refactor and extend the stub manager, identified by OIDs * Refactor and extend the proxy manager - Make all system interface proxies support aggregation - Identify interface stubs by IPID not IID - Do a search and replace of wine_marshal_id with STDOBJREF - Alexandre has stated that he won't allow any more midl generated code in WineHQ. Enhance widl until it can generate raw RPC marshallers for at least IRemUnknown. - Generate unique names for the pipes we currently use in communication and pull the right name from the OBJREF DUALSTRINGARRAY. In real DCOM this contains the RPC string binding for the OXID Resolver endpoint. This should be the first enhanced feature, as at this point you can run two apps at once that happen to marshal the same interface, and they won't interfere. - Implement IRemUnknown, using custom marshalling for now. Use this to nail distributed refcounting, at the moment we have a bunch of bad hacks for that. - Flip DCOM on top of the RPC transport layer, replacing the current named pipe based IRpcChannelBuffer implementation. Not necessarily using NDR marshalling at this point, though we may find it's necessary (?) - Rework RPC dispatch to be more Windows-like, so call re-entrancy works. - Implement RPC thread affinity. This will fix the InstallShield painting problems ... yes it's a long way off :( - Begin rewriting/moving the typelib marshaller to rpcrt4 and to use NDR (in Windows this is done by generating MOPs at runtime from the type data) .... this point is so far off I don't really care about it .... I probably forgot some items as well. But as you can see we only just begun. Also remember that Rob may want to modify it and also we may change direction at any point to make stuff we want internally work (like native MSIv2 ...) thanks -mike

1 0

[Fwd: Re: video4linux - wine]
by MediaHost (TM) 06 Jan '05

06 Jan '05

I'm forwarding this correspondence to wine-devel, in case it interests other developer / users.... -------- Original Message -------- Subject: Re: video4linux - wine Date: Wed, 5 Jan 2005 22:52:33 +0100 From: Jasper van Veghel <vanveghel(a)home.nl> To: MediaHost (TM) <webmaster(a)startcom.org> References: <20050105193015.GA14955(a)Skye.mill1.nb.home.nl> <41DC68AF.2060405(a)startcom.org> Well, sure, a lot of the infrastructure is there already; it seems to me that we'll have to implement several Quartz interfaces / filters and the approriate DLL for VFW to work with DirectX. I'm not quite sure which one to base it on, though; there are quite a lot that deal with VFW, multi-media and stream captur- ing; a lot of abstraction is handled in Quartz (including qcap and amstream), but for the raw video stuff it seems to me that these are the ones where it's really at (and consequently, what we'll have to base the stuff in Quartz on) winmm.dll msvfw32.dll msvideo.dll avicap32.dll As for the devenum stuff, I've had to modify createdevenum.c to include the CLSID for VideoInputDeviceCategory and have it create the corresponding registry entries in CreateSpecialCategories, for which I've extended the stub of avicap32 a bit to actually return a device (a static string, nothing special) - the corresponding filter either references Quartz's VideoRenderer as the DShow or the VfwCapture one .. I've been having more luck with VideoRenderer (MSN 6.2 seemed to respond quite well to that), but native devenum seems to go for the other one. Perhaps they're related in some way (AFAIK there's no implementation of VfwCapture in wine; there is, however, one of VideoRenderer .. perhaps Vfw- Capture captures from the stream and VideoRenderer renders it and provides info about it through IAMStreamConfig (which is a part of VideoRenderer) - anyway, I'm sure this is all well documented and everything on MSDN, but as I said, I've never worked with DirectX before I started looking into this (wouldn't have expected it to be related to it even) Anyway, it would be nice to make some headway with this, and if you have some sample code or even a small application to test this out with (one that indeed uses this DirectX stuff) then I'd be glad to dive back into it :-) Would indeed be nice to return something useful to Wine. Jasper MediaHost (TM) wrote: > Maybe we can start the same procedure with a simpler application. Any > ideas? Of course I would be interested first, what you implemented at > devenum. So I'm not a wine developer (specially not the windows part of > it) I can give it a try and maybe we can return something useful into > wine..... > > Jasper van Veghel wrote: > > >Rob Shearman wrote: > > > > > >>Mike McCormack wrote: > >> > >> > >> > >>>There's currently no support, but you could add it via the Still Image > >>>(STI) API. It's meant for scanners and webcams. There's probably a > >>>way to add VFW (Video For Windows drivers) too. > >>> > >>>I have written an IDL file for IStillImage, which I haven't gotten > >>>round to submitting as yet. I've attached it incase you're > >>>interested... I think it still needs some fixing up. > >>> > >>>Mike > >>> > >>> > >>>MediaHost (TM) wrote: > >>> > >>> > >>> > >>>>Question: Is there support for video4linux devices with wine? Is > >>>>there some support for webcams? What are the settings (config)? I > >>>>couldn't find anything useful on google concerning this issue.... > >>>> > >>>> > >>You're probably much better off implementing a DirectShow -> V4L filter, > >>especially if you want to capture movies or sound. > >> > >>Rob > >> > >> > >> > > > >I've recently been looking into VFW with Wine, and though I certainly am no > >expert at the Windows API concerning this (first time I really looked into > >DX), > >nor Wine for that matter, I was able to get a bit further from where I > >started, > >so allow me to share my experiences with you. > > > >As an application to test this stuff with I went for MSN 6.2, though > >certainly > >not the best application for this, it seemed neat to finally have Webcam > >support > >on MSN - I eventually got some of it working with a load of native DLLs, > >some > >hacking on the SSL stuff (I ended up simply setting useSSL = false, the > >applica- > >tion was sending plain-text over an SSL socket, which wasn't working; this > >fixed > >things, or at least for this application ;-)) and adding some undocumented > >flag > >to InternetSetOption (optionId = 87) - anyway, it seems that MSN is using > >some- > >thing along the lines of the following webcam class I found using Google - > >indeed, using a DirectShow filter: > > > >http://www.jolash.com/projects/other_projects/webcam/WebCam.h > > > >For things to start working under Wine I used the following native DLLs, > >which > >I also registered with regsvr32 (for CLSIDs etc.) > > > >COMCTL32.DLL > >urlmon.dll > >CRYPT32.DLL MSOSS.DLL > >oleaut32.dll ole32.dll rpcrt4.dll > >MSVCRT.DLL > >shlwapi.dll shdocvw.dll > >MLANG.DLL > >qcap.dll amstream.dll > > > >Though I'm not sure if amstream is needed. Don't know what qcap does as I > >only > >managed to get to a point where something in qcap was called which was then > >being forwarded to Quartz (IAMStreamConfig, for which I added a bunch of > >stubs > >and semi-stubs (filled in some bogus information for > >VIDEO_STREAM_CONFIG_CAPS, > >VIDEOINFOHEADER and AM_MEDIA_TYPE) > > > >It turned out that, at least MSN, and this webcam class too, uses devenum > >to > >find the video input devices (CLSID_VideoInputDeviceCategory), for which > >I've > >added the proper code to CreateSpecialCategories and hence > >CreateClassEnumerator > >(it also seems that the windows DLL of devenum always recreates the dynamic > >registery entries whereas Wine only seems to add them once and then never > >again, > >that is, once they're in the registry they stay there (hence if a new > >audio card > >gets added to the system ..)) The Windows DLL seemed to be using avicap32 > >to > >collect information on the available video input devices, so I've simply > >had > >capGetDriverDescription return some string with a fictional video driver > >(this > >also makes it possible to use a native devenum.dll) Next up is Quartz, > >which > >seemed to want IAMStreamConfig (collecting information on the video stream > >(res, > >depth, sps, ..) for starters, but I never got around to implementing > >enough of > >that for the program to accept it and move on, so that's where I got > >stuck. It > >may also have had something to do with MSN wanting an IKsPin which isn't > >imple- > >mented (which is why native quartz may have failed, when trying to > >approach the > >kernel in some way) Here's a small scenario of what I observed working > >with both > >native and hacked up DLLs ;-) > > > >DEVENUM - Read all VideoInputDeviceRenderer's (from CLSID) > >DEVENUM - BindToObject() --> VfwCapture > >QCAP - BindToClass --> Quartz(VideoRenderer) > >QUARTZ - VideoRenderer_create > >QUARTZ - [FAIL] InputPin_QueryInterface (IKsPin) > >QUARTS - VideoRenderer_QueryInterface (IAMStreamConfig) > > > >Anyway, the 'patches' I wrote are probably not worth much as the whole > >under- > >taking was more of a little endeavor trying to see how far I go (MSN > >actually > >managed to sign in, by the way, but kept crashing a few seconds after that > >(the > >webcam stuff can be accessed without signing in though, there's a preview > >option > >in one of the menus), but perhaps this brief explanation of my steps will > >prove > >useful for someone wanting to implement this aspect of VFW :-) Perhaps > >someone > >could build a control from the class I mentioned earlier which can then be > >used > >for testing (through the webpage that refers to it says it's missing some > >code; > >but at least it's a starting point) > > > >Jasper > > > > > > -- > 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 > -- 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

1 0

bi-arch on an amd64
by Gabriel de Perthuis 06 Jan '05

06 Jan '05

Hello, I'm trying to get wine cross compiled for my distrib, a 64-bit ubuntu. I'm using: a gcc-3.4 bi-arch toolchain (gcc built with --enable-multilib); the wine-20041201 tarball; this configure command (CC is ccache gcc-3.4): AS="as --32" CC="$CC -m32" CXX="$CXX -m32" ./configure --x-libraries=/usr/X11R6/lib32 note: with AS the same as CC, it gets stuck with dlls/ntdll/relay32.s -> relay32.o these two patches : sed -i s/SYS_sigaction/SYS_rt_sigaction/g dlls/ntdll/signal_i386.c replacing ld with ld -m elf_i386 in the ld_cmd definition in tools/winebuild/main.c With all this, I can get it to build! The problem is, it doesn't run; wine stops with this unhelpful message: wine: could not exec \uffff\uffffmU\uffff\uffffmUp/bin/wine-pthread (special characters inside) So, I am interested in past experiences (versions used and patches): I think wine, as most applications if need be, can be built in 32-bit mode and used by amd64 distros. It would be nice if these fixes were sent back to CVS to save people headaches; I also would like to know where I can go from here, to debug the binaries I finally got.

2 4

Re: Re: [AppDB] Fix to allow creating of new accounts (urgent)
by Chris Morgan 06 Jan '05

06 Jan '05

You can CC me on the mail as well to keep the load on Jeremy down. Chris > > From: Mike McCormack <mike(a)codeweavers.com> > Date: 2005/01/06 Thu AM 12:19:45 EST > To: tony_lambregts(a)telusplanet.net > CC: wine-devel(a)winehq.com, burnus(a)gmx.de > Subject: Re: [AppDB] Fix to allow creating of new accounts (urgent) > > > Please send mail about security problems with winehq directly to > jnewman(a)codeweavers.com rather than advertising on public mailing lists > first :) > > Mike > > tony_lambregts(a)telusplanet.net wrote: > > > I admit it I am an idiot for not knowing what to do to fix security flaws. > >

1 0

Re: [AppDB] Fix to allow creating of new accounts (urgent)
by Tobias Burnus 06 Jan '05

06 Jan '05

Hello, > $result = mysql_query("INSERT INTO user_list VALUES ( NOW(), 0, ". > "'$username', password('$password'), ". > - "'$realname', '$email', NOW(), 0, 0)"); > + "'$realname', '$email', NOW(), 0, 0, '$CVSrelease')"); Shouldn't one use "'".mysql_escape_string($username)."','" etc.? Or is it ensured elsewhere that no unwanted characters are in the string? ( ' is escaped in PHP, isn't it?) Tobias

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2005