wine-devel October 2008

wine-devel@winehq.org

114 participants
340 discussions

Kernel32: 3GB UserSpace boot option
by Stefan Reimer 15 Oct '08

15 Oct '08

Hi, I hacked wine to enable 3GB user address space just like the /3GB boot.ini option for windows. ( see patch ) This actually works like a charm playing everquest2 which crashes from time to time without this patch due to running out of memory. To do it right, should this "3GB Option" be enabled by a wine start parameter or a registry key ? Is the registry already setup during the call of libs/wine/mmap.c ? Bye Stefan Reimer diff --git a/dlls/kernel32/cpu.c b/dlls/kernel32/cpu.c index a49df99..61dd2be 100644 --- a/dlls/kernel32/cpu.c +++ b/dlls/kernel32/cpu.c @@ -383,7 +383,7 @@ VOID WINAPI GetSystemInfo( /* FIXME: the two entries below should be computed somehow... */ cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; - cachedsi.lpMaximumApplicationAddress = (void *)0x7FFEFFFF; + cachedsi.lpMaximumApplicationAddress = (void *)0xBFFEFFFF; cachedsi.dwActiveProcessorMask = 0; cachedsi.dwNumberOfProcessors = 1; cachedsi.dwProcessorType = PROCESSOR_INTEL_PENTIUM; diff --git a/dlls/kernel32/heap.c b/dlls/kernel32/heap.c index 9931c09..aec818f 100644 --- a/dlls/kernel32/heap.c +++ b/dlls/kernel32/heap.c @@ -1336,7 +1336,7 @@ BOOL WINAPI GlobalMemoryStatusEx( LPMEMORYSTATUSEX lpmemex ) /* FIXME: should do something for other systems */ GetSystemInfo(&si); - lpmemex->ullTotalVirtual = (char*)si.lpMaximumApplicationAddress-(char*)si.lpMinimumApplicationAddress; + lpmemex->ullTotalVirtual = (unsigned long)si.lpMaximumApplicationAddress-(unsigned long)si.lpMinimumApplicationAddress; /* FIXME: we should track down all the already allocated VM pages and substract them, for now arbitrarily remove 64KB so that it matches NT */ lpmemex->ullAvailVirtual = lpmemex->ullTotalVirtual-64*1024; diff --git a/libs/wine/mmap.c b/libs/wine/mmap.c index ff117cc..6ae6664 100644 --- a/libs/wine/mmap.c +++ b/libs/wine/mmap.c @@ -346,7 +346,7 @@ void mmap_init(void) #if defined(__i386__) && !defined(__FreeBSD__) && !defined(__FreeBSD_kernel__) /* commented out until FreeBSD gets fixed */ char stack; char * const stack_ptr = &stack; - char *user_space_limit = (char *)0x7ffe0000; + char *user_space_limit = (char *)0xbffe0000; reserve_malloc_space( 8 * 1024 * 1024 );

4 5

Re[5] [user32: 2/2] Testcase for font size = 0x7fff
by Koro 15 Oct '08

15 Oct '08

> This is not the intent of an Open Source project like Wine. The object > is to get your name in 'lights' and help fix a problem or implement new > code. Others then my modify it or even correct problems you did not > envision when you produced your code. > This directly violates the spirit and intent of the LGPL. Since Wine > exists under that license model, this would not be very friendly. > Again, the object is to make a project work better or, in this case, > work more like Microsoft Windows through a third party Application > Programming Interface which works with the underlying UNIX/Linux > operating system. I think you missed my point. The thing is, I don't want people to be able to recompile their own version of a project of mine, because I want to be the only place where people get the binaries. There's also the problem of backspaceware but it's another story. Now, when I said "can't-distribute-but-can-be-used-for-WINE license", what I really meant was that, I'd give the necessary raw code for integration into WINE (it'd have to be modified a lot), but once it gets into WINE, it's WINE code and goes by the WINE license. And therefore, if somebody wants to take that BACK from WINE, and make their own TDEmu.dll, or anything else for that matter, I don't care at all.

1 0

setupapi tests question
by Reece Dunn 15 Oct '08

15 Oct '08

When building the setupapi tests with VC9 and the MSVC headers (Vista version) after using msvcmaker, I get the following output: 2>------ Build started: Project: setupapi_test, Configuration: Debug MSVC Headers Win32 ------ 2>Linking... 2>misc.obj : error LNK2019: unresolved external symbol _MyFree referenced in function _test_SetupGetFileCompressionInfo 2>.\Output\Win32_Debug_MSVC_Headers/setupapi_test.exe : fatal error LNK1120: 1 unresolved externals Where does MyFree come from? Why does this work with a Wine/MinGW build and not VC9? Thanks, - Reece

2 2

Re: (try 2) user: edit.c make sure our vlc (vertical line count) isat least 1 even if there is an oversized font in the edit control
by Dmitry Timoshkov 15 Oct '08

15 Oct '08

"Aric Stewart" <aric(a)codeweavers.com> wrote: > +static inline INT calculate_vlc(EDITSTATE *es) > +{ > + INT vlc = (es->format_rect.bottom - es->format_rect.top) / es->line_height; > + return max(1,vlc); > +} The formatting of the above hunk is broken, you will notice that once you set tab size in your editor to native 8. -- Dmitry.

1 0

Re: Try #2 IDirectDraw_CreateSurface Failure on WINE test in dsurface.c code
by chris ahrendt 14 Oct '08

14 Oct '08

Michael Karcher wrote: > I put the list back on CC because someone there might know about the > drmMap problem. > > Am Dienstag, den 14.10.2008, 15:30 -0700 schrieb chris ahrendt: > >>> PS: From the attachments of Chris' mail, one can get the following >>> information: The environment we are currently talking about is Wine on >>> Linux, an ATI FireGL 5200 graphics board driven by the closed source >>> driver, and somehow broken DRM. >>> >> >> Broken DRM? >> > Yes. This shouldn't appear in your log if DRM is working: > | libGL error: drmMap of framebuffer failed (Cannot allocate memory) > | libGL error: reverting to (slow) indirect rendering > > This might be caused by wine blocking the address space used for kernel > addresses in real windows, or it might be a misconfiguration or > installation problem of the ATI driver. Cross-checking with glxgears is > recommended. > > But even if non-functional DRM causes CreateSurface to fail you are > right that the testcase should handle that. > > Regards, > Michael Karcher > > > > > This used to be fixed like I said by doing the ulimit -s unlimited trick but now since drop 15 even that has stopped working. I did a little checking and there seems to be another way to get this error where the focus is lost for the X session. I just added this other fix as well : |Section "DRI" Group "video" Mode 0666 EndSection| | | Ati has a bug reported on this : 737-35215: Creating two successive connections my result in Direct GL context to fail here is a code fix that is supposed to work: The following (psuedocode) sequence, forces fglrx to revert to indirect rendering: dpy = XOpenDisplay() visual = glXChooseVisual(dpy) XCloseDisplay(dpy) ... dpy2 = XOpenDisplay() ctx = glXCreateContext(dpy2, visual) <-- fglrx reverts to indirect rendering ... Changing the code to use the same display connection for glXChooseVisual Chris and glXCreateContext solves this problem.

1 0

Re: Try #2 IDirectDraw_CreateSurface Failure on WINE test in dsurface.c code
by chris ahrendt 14 Oct '08

14 Oct '08

1 0

Re: Try #2 IDirectDraw_CreateSurface Failure on WINE test in dsurface.c code
by Michael Karcher 14 Oct '08

14 Oct '08

I put the list back on CC because someone there might know about the drmMap problem. Am Dienstag, den 14.10.2008, 15:30 -0700 schrieb chris ahrendt: > > PS: From the attachments of Chris' mail, one can get the following > > information: The environment we are currently talking about is Wine on > > Linux, an ATI FireGL 5200 graphics board driven by the closed source > > driver, and somehow broken DRM. > > Broken DRM? Yes. This shouldn't appear in your log if DRM is working: | libGL error: drmMap of framebuffer failed (Cannot allocate memory) | libGL error: reverting to (slow) indirect rendering This might be caused by wine blocking the address space used for kernel addresses in real windows, or it might be a misconfiguration or installation problem of the ATI driver. Cross-checking with glxgears is recommended. But even if non-functional DRM causes CreateSurface to fail you are right that the testcase should handle that. Regards, Michael Karcher

1 0

Re: [PATCH 07/10] jscript: Added NaN handling to relational operators.
by Tijl Coosemans 14 Oct '08

14 Oct '08

On Tuesday 14 October 2008 23:07:45 Jacek Caban wrote: > --- > dlls/jscript/engine.c | 28 ++++++++++++++++------------ > dlls/jscript/tests/lang.js | 12 ++++++++++++ > 2 files changed, 28 insertions(+), 12 deletions(-) > I'm not sure if this applies to javascript but if it does, you might want to add a test case for (( NaN == NaN ) === false ).

1 0

Re: Try #2 IDirectDraw_CreateSurface Failure on WINE test in dsurface.c code
by chris ahrendt 14 Oct '08

14 Oct '08

Yes if we need to move this off list please let me know.... Michael Karcher wrote: > That's why I suggested you to introduce the err2 label. The end of the > function should look like this: > Ya, Ich versteh.... here is the first patch to fix exception 1. I did have the patch with the skip but decided to try this: if (surface4)IDirectDrawSurface_Release(surface4); if (surface3) IDirectDrawSurface_Release(surface3); if (surface2) IDirectDrawSurface_Release(surface2); if (surface1) IDirectDrawSurface_Release(surface1); If I do the above I get the same exception on : if (surface3) IDirectDrawSurface_Release(surface3); So to fix that exception I have to do the following: if (FAILED(hr)) { skip("failed to create surface3\n"); if (surface2) IDirectDrawSurface_Release(surface2); if (surface1) IDirectDrawSurface_Release(surface1); return; } This is for IDirectDraw_CreateSurface failure which was not caught before for 3. The following is for the 4th surface : if (FAILED(hr)) { skip("failed to create surface4\n"); if (surface2) IDirectDrawSurface_Release(surface3); if (surface2) IDirectDrawSurface_Release(surface2); if (surface1) IDirectDrawSurface_Release(surface1); return; } Next Exception # 2 is caused by lines at 1138 : hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface1, NULL); ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); To Fix that exception I have to add the below. if (FAILED(hr)) { skip("failed to create surface1\n"); return; } After that exception I have to close the window and reopen a new one to continue. make test refuses to run or acts strange.. So I figured the env. got hosed by the last exception. Clean up the ok files and .o and shared object and run make test. The run 3 is the final output. The two .ok files contain nothing. Chris

2 1

Re: Try #2
by chris ahrendt 14 Oct '08

14 Oct '08

Michael Karcher wrote: > Am Montag, den 13.10.2008, 21:05 -0400 schrieb Chris Ahrendt: > >> Fixed a trailing space error.. >> > Sorry to chime in so late on this patchset. > > First, some general remarks: The subject of your mail will be the > one-line commit message. "Try #2" is not a good choice for that. Also it > does not have enough context for the casual wine-patches reader, as the > message overview does not show what you patch is about. The usual > convention is to take the subject of the first try, and append (or > prepend) "(try 2)" to that subject. > > >> Subject: [PATCH] Pared Down Test For ddraw test... fixes error with IDirectDraw_CreateSurface >> where the test is not checking the return from the call. CreateSurface is returning a null. >> > Another convention is to *not* use the [PATCH] tag on wine-patches, as > all mails on wine-patches are patches. Use "--keep-subject" with > git-format-patch to prevent it. > Last, but not least, your original subject was way too long. Subjects on > wine-patches usually mention the component to be patched (that is > usually the directory name without dlls or programs in front) followed > by a short synopsis (around 40 to 60 characters, if possible). I suggest > the following subject for your next try: > > Subject: ddraw/tests: Catch failures of CreateSurface to prevent crash > > I don't remember whether you had the crash on Windows or on Wine. You > could put that info also into the subject. As it is more important what > the goal of your patch is than how you achieve that, something like this > might also be OK: > > Subject: ddraw/tests: Don't crash on Windows with GeForce 4399, driver 42.23 > > (this subject using made-up numbers on purpose, please fit in your own, > and only use this line if the crash *is* on native Windows) > > > >> diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c >> index fc7bb88..21e6b15 100644 >> --- a/dlls/ddraw/tests/dsurface.c >> +++ b/dlls/ddraw/tests/dsurface.c >> @@ -1181,7 +1181,10 @@ static void AttachmentTest7(void) >> ddsd.dwHeight = GetSystemMetrics(SM_CYSCREEN); >> hr = IDirectDraw7_CreateSurface(dd7, &ddsd, &surface3, NULL); >> ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); >> - >> + if (FAILED(hr)) { >> + skip("failed to create surface3\n"); >> + return; >> + } >> /* This one has a different size */ >> memset(&ddsd, 0, sizeof(ddsd)); >> ddsd.dwSize = sizeof(ddsd); >> > return inside a test function is bad style. You may use it for try&crash > debugging, but I don't see any chance to get such a patch committed. In > this case, you leak one IDirectDraw7 interface, forget to restore the > cooperative level and you leak two surfaces. The "goto err:" approach is > preferred if a lot of cleanup is needed (like here). You either want to > make a label "err2:" before the IDirectDrawSurface7_Release(surface2) > and use that label (analogous for "err3:" one line before that) or use > the technique of setting released or uninitialized interface pointers to > NULL and NULL-Check before calling release. > > Same remarks for the next 3 hunks (not quoted). > Thing is the two surfaces have not been allocated yet.. they are off the local stack and just set to null. > >> @@ -2208,6 +2220,12 @@ static void SizeTest(void) >> desc.dwWidth = 128; /* Keep them set to check what happens */ >> ret = IDirectDraw_CreateSurface(lpDD, &desc, &dsurface, NULL); >> ok(ret == DD_OK, "Creating a primary surface without width and height info returned %08x\n", ret); >> + /* This should be handled but CreateSurface is failing */ >> + if (FAILED(ret)) >> + { >> + skip("Can't create cubemap surface\n"); >> + return; >> + } >> if(dsurface) >> { >> ret = IDirectDrawSurface_GetSurfaceDesc(dsurface, &desc); >> > The skip message is wrong. It's not about cubemap at all. Also, this > hunk is unneeded. If CreateSurface fails, dsurface is unmodified or set > to NULL (or CreateSurface really badly needs fixing!). As dsurface is > NULL on the call to CreateSurface, it is null if CreateSurface failed. > So the condition of the if statement following the CreateSurface call is > false, and no crash can happen on that NULL pointer. > > > Yes I just caught this message thanks .... I will fix that... The problem here which makes no sense to me is if I don't have the Failed statement before the dsurface if when it gets the surface description it throws an exception because one of the parms is null. That doesnt make sense thought because the contents of desc has been set earlier. So unless the CreateSurface call nulls out the description parm before returning. Any ideas? >> @@ -2492,7 +2510,7 @@ static void PaletteTest(void) >> ok(hr==DD_OK, "CreateSurface returned: %x\n",hr); >> if (FAILED(hr)) { >> skip("failed to create surface\n"); >> - goto err; >> + return; >> } >> >> hr = IDirectDrawSurface_SetPalette(lpSurf, palette); >> > Why do you need this hunk? You talked about usage of uninitialized > variables at the target of the goto, but that's not the case. The code > at err looks like this (formatting adjusted for clearness): > > | err: > | if (lpSurf) IDirectDrawSurface_Release(lpSurf); > | if (palette) IDirectDrawPalette_Release(palette); > > Again when I leave the goto err in and it does the release it throws an exception on the lpsurf line. > So the only two variables used here are lpSurf and palette. These two > variables are initialized at the point of definition. > > | static void PaletteTest(void) > | { > | HRESULT hr; > | LPDIRECTDRAWSURFACE lpSurf = NULL; > | DDSURFACEDESC ddsd; > | IDirectDrawPalette *palette = NULL; > > As they are initialized to NULL, the condition of the if statement is > false if these variables were not yet initialized. So no crash possible > here. Your return statement leaks palette. > > > Yes I saw that.. which is why it did not make much sense... if you want I can recreate and show you the exception which occurs when I don't have the return or the dsurface error I mentioned above. Its not that I don't know C (I have been writing in C for over 20 years so its not that.. (though I do admit at being rusty due to not doing anything but architecture and design)) . Any ideas? BTW Thank you for your comments... I do appreciate them =) Chris

2 1

← Newer
1
...
18
19
20
21
22
23
24
...
34
Older →

Jump to page:

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 October 2008