wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Wine(server) priority inversion on CK kernel mailing list
by Andreas Mohr 09 Jan '05

09 Jan '05

Hi, I'm following CK kernel development, and the mailing list had the following posting: ---------- Message: 19 Date: Fri, 07 Jan 2005 23:16:14 +1100 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] wine is bloody slow with 2.6.10-ck2 To: Michal ?erav?k <michalz(a)olomouc.com> Cc: CK Kernel <ck(a)vds.kolivas.org> Message-ID: <41DE7D8E.8090102(a)kolivas.org> Content-Type: text/plain; charset="iso-8859-2" Michal ?erav?k wrote: > Hi, > > I have been running photoshop under wine > with 2.6.8.1-ck9 and 2.6.9 and it was good. > Is there any workaround for 2.6.10-ckx and wine > to get normal speed? > It's the same with prelink and without. Nice your wineserver +19. If that's not enough, just run wine at +19. Wineserver gets into a silly priority inversion scenario with the main wine threads. Cheers, Con ---------- Note that Con indicated several times that Wine is a very "special" piece of software, it has wildly differing gaming behaviour (threading behaviour) than native Linux games. For those of you who don't know what priority inversion is (I'll try to explain it, but I'm sure my explanation sucks ;): one (high priority) thread is waiting on a lock, and in order to keep this high priority, another thread owning that lock gets more CPU to get that lock released. Problem is that that thread should have a lower priority, but since the high priority thread always has to wait on the lock, the low priority thread effectively has a much higher priority. These could just be the usual known slow wineserver communication effects at work here, but I wanted to make sure you know about these issues on the CK list. Andreas Mohr

3 3

Re: [winegcc] Include .so files when calling winebuild
by Alexandre Julliard 09 Jan '05

09 Jan '05

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > Currently when compiling a program, winegcc calls winebuild > to solve .def references. But winegcc drops .so files, > so any new .def symbols in a .so causes a unresolved symbol at > link time. This patch adds .so files to the files to winebuild. I'm not sure I follow you, if your .so files have been built correctly they shouldn't contain undefined references to Windows APIs. Could you please show an example of the situation that causes a problem? -- Alexandre Julliard julliard(a)winehq.org

2 1

another build problem on current cvs
by Joris Huizer 09 Jan '05

09 Jan '05

Hello, For the past week or so, building from cvs on a debian/stable system w/ alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks on alsa-specific code in wine; I attached the log; note that I did a `cvs update -dPA` and `make distclean` so this can't be any problem with the source I have Any ideas? Maybe you can point me to a place where I can read how to fix this properly (I never worked on alsa-specific code before...) or something like that regards, Joris

4 7

Directx 9
by Ann and Jason Edmeades 08 Jan '05

08 Jan '05

Hiya, FYI I've spent the last couple of months putting together a directx 8 level support into wined3d and calling it from d3d9 such that I can also change d3d8 easily to use the new code. This is mostly complete other than the texture support and the shader support plus moving some functions / stubs into the common code. If you have any directx 8/9 questions feel free to email me directly, put questions on wine-devel or perhaps even the wined3d (very, very quiet - http://www.bbrox.org/mailman/listinfo/wine-d3d) mailing list (Lionel's). You really are welcome, and I'll try to answer any questions I can. I wouldn't spent too much time trying to move existing functionality between d3d8 to wined3d unless you really want to as I am trying to get this move completed asap. I really don't want to discourage any d3d assistance, its just I know where I am and what I have left to do. I have generally been doing a patch and getting it committed both due to lack to time, but also to avoid potential rework of multiple patches. I really hope to get most of the non-shader support done quite quickly once the 20 patch goes in (Christmas and FarCry got in the way, and I had some teething problems with the render target support which delayed it!). Next will be the texture support and that should be quick as it is relatively trivial to move across. >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... Sounds good - one thing wine has suffered from is a lack of people doing the directx support! Note that Raphael (copied on this note) has some outstanding patches he has put off while I do the move to support hardware vertex buffers so the drawstridedslow case is driven less frequently, but that's the only outstanding work I know about. > or moving DirectX8 over to using WineD3d. I have a version locally where I have changed d3d8 up to about patch 13. I can send it to you if it helps - Unfortunately I think the swap to wined3d will have to be one big patch, I don't think there is a way to move d3d8 over slowly, as you have to move the state block code in one go, the resource8 subclasses in one go etc... >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... Sounds fine - The problem I had with the latest patch was purely being able to add the support for getfrontbuffer etc which needed to return d3d8 or d3d9 objects, but the initial crates being done in the wined3d layer. A single callback sounds useful, as I know I'll have to do something similar for stencildepth surfaces (nothing else is created purely from the wined3d layer, so I don't think others need the same). FWIW I do the same, ie find demos on the web with source code, and then try to get them working. That's how most of the d3d8 support came about as it's a lot easier making a demo work than finding why there's a small amount of corruption for a particular game. I wouldn't claim to be a directx nor opengl expert - its all been a learning experience as I go! Maybe we should collect some useful test program links! If there's any d3d8/9 programmers out there, there's definitely a fun project to do to produce test programs for wine. They cant be automated (I think!) but it would be useful to be able to visually see the effect differences of all the render states, the texture states, prove the shader support works in both hw and sw vertex and pixel code etc etc. Jason

1 0

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

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