Re: setupapi: Implement installing catalog files
The patch you sent doesn't match the subject line.
Vincent Povirk
On Wed, Oct 15, 2008 at 11:05 AM, Maarten Lankhorst
<[EMAIL PROTECTED]> wrote:
> ---
> The functions called here are stubs, but don't cause this code to bomb out.
>
> From 04917f75269b6f4f51924ba734c20dc05617d882 Mon Sep 17 00:00:00 2001
> From: Maarten Lankhorst <[EMAIL PROTECTED]>
> Date: Tue, 14 Oct 2008 20:16:14 +0200
> Subject: [PATCH] advapi32: Make CheckTokenMembership return FALSE for asking
> whether we are connected through the network
>
> ---
> dlls/advapi32/security.c | 21 +
> 1 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/dlls/advapi32/security.c b/dlls/advapi32/security.c
> index ca26217..5a2b3e4 100644
> --- a/dlls/advapi32/security.c
> +++ b/dlls/advapi32/security.c
> @@ -615,10 +615,23 @@ BOOL WINAPI
> CheckTokenMembership( HANDLE TokenHandle, PSID SidToCheck,
> PBOOL IsMember )
> {
> - FIXME("(%p %p %p) stub!\n", TokenHandle, SidToCheck, IsMember);
> -
> - *IsMember = TRUE;
> - return(TRUE);
> +WCHAR *sid = NULL;
> +WCHAR network[] = { 'S','-','1','-','5','-','2',0};
> +BOOL ret = TRUE;
> +FIXME("(%p %p %p) stub!\n", TokenHandle, SidToCheck, IsMember);
> +
> +ConvertSidToStringSidW(SidToCheck, &sid);
> +FIXME("Sid: %s\n", debugstr_w(sid));
> +/* We are not connected through the network in any way, but locally
> + * Internet Explorer 7 installer checks for it and bombs out if
> + * we return TRUE on asking whether we are
> + */
> +if (sid && !lstrcmpW(sid, network))
> +ret = FALSE;
> +LocalFree(sid);
> +
> +*IsMember = ret;
> +return TRUE;
> }
>
>
> /**
> --
> 1.5.6.5
>
>
>
>
>
Try #3 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
Michael / All here is the third go at the ddraw test... and the patch for that... note I went ahead and used the goto. Also I found an error in the test where it was allocating the buffer in one place and it did not free it. Now here is the curious thing... When I did the first run of the ddraw test I got the output found in the no_ulimit_run attachment which did not seem right as nothing ran or didnt seem to. So I did the ulimit -s unlimited and then re-ran the test and got the second output... Now shouldn't the test run the same reguardless of the stack limit? Chris 0001-Fix-for-dsurface-for-IDirectDrawSurface_Release-error.txt Description: Binary data no_ulimit_run Description: Binary data ulimit_unlimited_run Description: Binary data
re: Wineg++ and structured exception handling
See http://wiki.winehq.org/CompilerExceptionSupport
Re: [RFC] jscript: Fix shift/reduce conflict by removing redundant FunctionDeclaration rule.
Hi Rob, Rob Shearman wrote: > The rule is implemented by FunctionExpression which is reduced using > the Statement rule. > --- > dlls/jscript/parser.y | 37 - > 1 files changed, 0 insertions(+), 37 deletions(-) > > The tests pass with this change, but I haven't looked in detail as to > whether it will break anything. Jacek, can you check that your > applications that use jscript still work after this patch is applied? > Thanks for looking at this. There is a big difference between function expressions and declarations in the specification. I don't know, how does it handle this shift/reduce conflict, but it doesn't matter. I've just tested native jscript behavior and (surprise!) it doesn't match specifications. It seems to handle all functions expressions that have an identifier as function declarations. It needs more tests and the fix fill be more complicated (similar to variable handling). I will work on it tomorrow. Thanks, Jacek
Re: shdocvw: [Patch 1/2] Implement URLSubRegQueryA [Resend]
On Mi, 2008-10-15 at 16:53 +0200, Alexandre Julliard wrote:
> Detlef Riekenberg <[EMAIL PROTECTED]> writes:
>
> > +len = sizeof(buffer);
> > +res = SHRegGetUSValueA(regpath, name, NULL, buffer, &len, FALSE,
> > NULL, 0);
> > +if (!res) {
> > +lstrcpynA(out, buffer, outlen);
> > +if (outlen > 0) {
> > +out[min(outlen-1,len)] = '\0';
> > +}
>
> This doesn't look right. Why do you even need a separate buffer?
The test in Patch 2 show, that URLSubRegQueryA still succeed,
when the caller buffer is to small (the result is truncated).
I used the buffer from the caller first, but SHRegGetUSValueA fail, when
the
buffer is to small.
With the seperate buffer, SHRegGetUSValueA (and URLSubRegQueryA) only
fails,
when the value does not exist in the registry.
Dropping the seperate buffer is possible, but then the implemenation
works only, when the the caller buffer is always large enough and we
need to add a buch of todo_wine.
I used a new file for the test, because URLSubRegQueryA is not related
to an object, and ParseURLFromOutsideSource is in the pipeline.
--
By by ... Detlef
Re: [PATCH 03/10] jscript: Added NaN value implementation.
Jacek Caban <[EMAIL PROTECTED]> writes: > Alexandre Julliard wrote: >> I'd suggest to take advantage of the variant union instead of copying >> all these glibc definitions. Something like >> >> #ifdef NAN >> V_R8(&vt) = NAN; >> #else >> V_I8(&vt) = nan_magic_pattern; >> #endif >> > > The problem is that nan_magic_pattern would have to be 8 bytes and > AFAIK there is no portable way to do it without ugly casts like in > attached patch. Something like (ULONGLONG)0x7ff8 << 32 should do the trick. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH 03/10] jscript: Added NaN value implementation.
Alexandre Julliard wrote:
I'd suggest to take advantage of the variant union instead of copying
all these glibc definitions. Something like
#ifdef NAN
V_R8(&vt) = NAN;
#else
V_I8(&vt) = nan_magic_pattern;
#endif
The problem is that nan_magic_pattern would have to be 8 bytes and AFAIK
there is no portable way to do it without ugly casts like in attached patch.
Thanks,
Jacek
>From bae01a44932b20aa31cf3d9ca09f31a970ea1791 Mon Sep 17 00:00:00 2001
From: Jacek Caban <[EMAIL PROTECTED]>
Date: Wed, 15 Oct 2008 16:45:09 -0500
Subject: [PATCH] jscript: Added NaN value implementation.
To: wine-patches <[EMAIL PROTECTED]>
---
dlls/jscript/global.c | 15 +--
dlls/jscript/jscript.h | 16
dlls/jscript/jsutils.c |3 +++
dlls/jscript/tests/lang.js |3 +++
4 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/dlls/jscript/global.c b/dlls/jscript/global.c
index a1c76de..e397c3d 100644
--- a/dlls/jscript/global.c
+++ b/dlls/jscript/global.c
@@ -108,8 +108,19 @@ static HRESULT constructor_call(DispatchEx *constr, LCID
lcid, WORD flags, DISPP
static HRESULT JSGlobal_NaN(DispatchEx *dispex, LCID lcid, WORD flags,
DISPPARAMS *dp,
VARIANT *retv, jsexcept_t *ei, IServiceProvider *sp)
{
-FIXME("\n");
-return E_NOTIMPL;
+TRACE("\n");
+
+switch(flags) {
+case DISPATCH_PROPERTYGET:
+num_set_nan(retv);
+break;
+
+default:
+FIXME("unimplemented flags %x\n", flags);
+return E_NOTIMPL;
+}
+
+return S_OK;
}
static HRESULT JSGlobal_Infinity(DispatchEx *dispex, LCID lcid, WORD flags,
DISPPARAMS *dp,
diff --git a/dlls/jscript/jscript.h b/dlls/jscript/jscript.h
index 691ac9e..4d4ad0f 100644
--- a/dlls/jscript/jscript.h
+++ b/dlls/jscript/jscript.h
@@ -242,6 +242,22 @@ static inline void num_set_val(VARIANT *v, DOUBLE d)
}
}
+static inline void num_set_nan(VARIANT *v)
+{
+V_VT(v) = VT_R8;
+#ifdef NAN
+V_R8(v) = NAN;
+#else
+#ifdef WORDS_BIGENDIAN
+((DWORD*)&V_R8(v))[1] = 0x7ff8;
+((DWORD*)&V_R8(v))[0] = 0;
+#else
+((DWORD*)&V_R8(v))[0] = 0;
+((DWORD*)&V_R8(v))[1] = 0x7ff8;
+#endif
+#endif
+}
+
const char *debugstr_variant(const VARIANT*);
HRESULT WINAPI
JScriptFactory_CreateInstance(IClassFactory*,IUnknown*,REFIID,void**);
diff --git a/dlls/jscript/jsutils.c b/dlls/jscript/jsutils.c
index c6f4b9c..6507ce6 100644
--- a/dlls/jscript/jsutils.c
+++ b/dlls/jscript/jsutils.c
@@ -16,6 +16,9 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
*/
+#include "config.h"
+#include "wine/port.h"
+
#include
#include "jscript.h"
diff --git a/dlls/jscript/tests/lang.js b/dlls/jscript/tests/lang.js
index b989645..5f14eb1 100644
--- a/dlls/jscript/tests/lang.js
+++ b/dlls/jscript/tests/lang.js
@@ -785,7 +785,10 @@ if (true)
else
ok(true, "else should be associated with nearest if statement");
+ok(isNaN(NaN) === true, "isNaN(NaN) !== true");
ok(isNaN(0.5) === false, "isNaN(0.5) !== false");
ok(isNaN() === true, "isNaN() !== true");
+ok(isNaN(NaN, 0) === true, "isNaN(NaN, 0) !== true");
+ok(isNaN(0.5, NaN) === false, "isNaN(0.5, NaN) !== false");
reportSuccess();
--
1.5.5.4
Re: Michael Stefaniuc : shlwapi: Remove break after return (Smatch).
On Wed, Oct 15, 2008 at 2:11 PM, Michael Stefaniuc <[EMAIL PROTECTED]> wrote: > Hello Alexandre, > > I'm pretty sure that my patch contained only the second chunk of the > patch commited. The first part seems to have been credited to me by mistake. > The first chunk should have been in commit dc9eeb75bad6542a8068a024a604f68ad77e.
Re: Michael Stefaniuc : shlwapi: Remove break after return (Smatch).
Hello Alexandre,
I'm pretty sure that my patch contained only the second chunk of the
patch commited. The first part seems to have been credited to me by mistake.
Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: d6359edd3cbe366c71f22e09e27d3e427520f609
> URL:
> http://source.winehq.org/git/wine.git/?a=commit;h=d6359edd3cbe366c71f22e09e27d3e427520f609
>
> Author: Michael Stefaniuc <[EMAIL PROTECTED]>
> Date: Tue Oct 14 16:32:33 2008 +0200
>
> shlwapi: Remove break after return (Smatch).
>
> ---
>
> dlls/shlwapi/assoc.c | 27 +--
> 1 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/shlwapi/assoc.c b/dlls/shlwapi/assoc.c
> index 7f71708..9e4b036 100644
> --- a/dlls/shlwapi/assoc.c
> +++ b/dlls/shlwapi/assoc.c
> @@ -627,7 +627,31 @@ static HRESULT
> ASSOC_GetExecutable(IQueryAssociationsImpl *This,
>if (!pszExtra)
>{
> hr = ASSOC_GetValue(hkeyShell, &pszExtraFromReg);
> -if (FAILED(hr))
> +/* if no default action */
> +if (hr == E_FAIL || hr == HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND))
> +{
> + DWORD rlen;
> + ret = RegQueryInfoKeyW(hkeyShell, 0, 0, 0, 0, &rlen, 0, 0, 0, 0, 0, 0);
> + if (ret != ERROR_SUCCESS)
> + {
> +RegCloseKey(hkeyShell);
> +return HRESULT_FROM_WIN32(ret);
> + }
> + rlen++;
> + pszExtraFromReg = HeapAlloc(GetProcessHeap(), 0, rlen * sizeof(WCHAR));
> + if (!pszExtraFromReg)
> + {
> +RegCloseKey(hkeyShell);
> +return E_OUTOFMEMORY;
> + }
> + ret = RegEnumKeyExW(hkeyShell, 0, pszExtraFromReg, &rlen, 0, NULL,
> NULL, NULL);
> + if (ret != ERROR_SUCCESS)
> + {
> +RegCloseKey(hkeyShell);
> +return HRESULT_FROM_WIN32(ret);
> + }
> +}
> +else if (FAILED(hr))
> {
>RegCloseKey(hkeyShell);
>return hr;
> @@ -743,7 +767,6 @@ static HRESULT WINAPI IQueryAssociations_fnGetString(
> return hr;
>len++;
>return ASSOC_ReturnData(pszOut, pcchOut, path, len);
> - break;
> }
>
> case ASSOCSTR_FRIENDLYAPPNAME:
>
>
>
bye
michael
Re: Wineg++ and structured exception handling
Michael Ost wrote: > Hi, > > Is there a way for wineg++ to catch windows exceptions and handle them > as g++ does --- cleaning up stack variables, etc? > > My C++ winelib app, built with wineg++, is loading Windows DLLs. I want > to catch windows exceptions from functions that I call from those DLLs. > I need to do some cleanup if there are exceptions, and tried creating > some stack variables to manage that. > > I found __TRY and __CATCH in wine/exception.h. Wrapping the DLL function > calls with __TRY and __CATCH does indeed catch exceptions, but there is > no stack cleanup. > > There is some deep code in exception.h that implements __TRY/__CATCH > (which I sure could be misreading) but they look more C like than C++ > like... just taking care to jump to the right location without trying to > do any cleanup. > > Window's c++ compiler evidently does that now, per this page: > http://msdn.microsoft.com/en-us/library/7w0chfbk(VS.80).aspx > > I'm guessing I am out of luck here, but am hoping I'm just missing > something. > > Thanks... mo > > Wow, I remember discovering this area of winelib about 4 years ago and wondering if anyone else was working on it or using it. Great to hear about you :) Thanks, Scott Ritchie
Wineg++ and structured exception handling
Hi, Is there a way for wineg++ to catch windows exceptions and handle them as g++ does --- cleaning up stack variables, etc? My C++ winelib app, built with wineg++, is loading Windows DLLs. I want to catch windows exceptions from functions that I call from those DLLs. I need to do some cleanup if there are exceptions, and tried creating some stack variables to manage that. I found __TRY and __CATCH in wine/exception.h. Wrapping the DLL function calls with __TRY and __CATCH does indeed catch exceptions, but there is no stack cleanup. There is some deep code in exception.h that implements __TRY/__CATCH (which I sure could be misreading) but they look more C like than C++ like... just taking care to jump to the right location without trying to do any cleanup. Window's c++ compiler evidently does that now, per this page: http://msdn.microsoft.com/en-us/library/7w0chfbk(VS.80).aspx I'm guessing I am out of luck here, but am hoping I'm just missing something. Thanks... mo
Re: advapi32: Fall back to /dev/random if /dev/urandom can't be opened, and add warnings if opening either fails
Hi Austin, > FWIW: http://en.wikipedia.org/wiki/Urandom (snip) > "A software program called EGD (entropy gathering daemon) is a common > alternative for Unix systems which do not support the /dev/random > device. Yep, I know. The problem with using EGD is that there isn't a standard path to it. Because /dev/urandom is so commonly available, adding a configuration option and code for such a rarely used feature didn't seem worth it. Thanks, --juan
Re: advapi32: Fall back to /dev/random if /dev/urandom can't be opened, and add warnings if opening either fails
On Wed, Oct 15, 2008 at 1:13 PM, Juan Lang <[EMAIL PROTECTED]> wrote: > Let me know if you think the fallback is a bad idea, or if a FIXME is > more appropriate than a WARN here. > --Juan > > > > FWIW: http://en.wikipedia.org/wiki/Urandom "/dev/random and /dev/urandom are also available on Solaris, Mac OS X, NetBSD, OpenBSD, Tru64 UNIX 5.1B, AIX 5.2, and HP-UX 11i v2, however as with FreeBSD, AIX implements its own Yarrow-based design which uses considerably less entropy sources than the standard /dev/random implementation and stops refilling the pool when it thinks it contains enough entropy.[2]" "A software program called EGD (entropy gathering daemon) is a common alternative for Unix systems which do not support the /dev/random device. It is a user space daemon which provides high quality cryptographic random data. Some cryptographic software such as OpenSSL, GNU Privacy Guard, and the Apache HTTP Server support using EGD when a /dev/random device is not available." -- -Austin
Re: wininet: quiet a noisy fixme
I think this one can be better removed entirely, wine will never get support for dialup programs or other fancy ways to connect to the internet, so this fixme is useless.
Re: winex11.drv: Prevent XCreateIC from returning NULL when input style isn't "root". (try 3)
"Muneyuki Noguchi" <[EMAIL PROTECTED]> writes: > diff --git a/dlls/winex11.drv/x11drv.h b/dlls/winex11.drv/x11drv.h > index e5a40aa..f58342b 100644 > --- a/dlls/winex11.drv/x11drv.h > +++ b/dlls/winex11.drv/x11drv.h > @@ -701,6 +701,7 @@ struct x11drv_win_data > RECTwhole_rect; /* X window rectangle for the whole window > relative to parent */ > RECTclient_rect;/* client area relative to parent */ > XIC xic;/* X input context */ > +XFontSetfont_set; /* international text drawing font set */ > XWMHints *wm_hints; /* window manager hints */ > BOOLmanaged : 1;/* is window managed? */ > BOOLmapped : 1; /* is window mapped? (in either normal or > iconic state) */ You shouldn't need to create a font set for each window, once per display should be enough. -- Alexandre Julliard [EMAIL PROTECTED]
Re: shdocvw: [Patch 1/2] Implement URLSubRegQueryA [Resend]
Detlef Riekenberg <[EMAIL PROTECTED]> writes:
> +len = sizeof(buffer);
> +res = SHRegGetUSValueA(regpath, name, NULL, buffer, &len, FALSE, NULL,
> 0);
> +if (!res) {
> +lstrcpynA(out, buffer, outlen);
> +if (outlen > 0) {
> +out[min(outlen-1,len)] = '\0';
> +}
This doesn't look right. Why do you even need a separate buffer?
--
Alexandre Julliard
[EMAIL PROTECTED]
re: [user32: 2/2] Testcase for font size = 0x7fff
Koro wrote: > That is an *excellent* explanation. Everything becomes > clear now, and indeed this should be documented somewhere > (except I can't find how to edit the wiki without making an account). That's because you need an account. (Otherwise there's too much spam. Accounts are free.) > Maybe somebody could wikify it for me? Done: http://wiki.winehq.org/Developers-Hints#head-8494fa344a35867c68b6bdd5e6256e4d8d378308 > if somebody wants to take up the project, I guess I > could release parts of the source (namely, the API > emulation and the layout / reflow code) under a very > specific can't-distribute-but-can-be-used-for-WINE > license. ... [That is,} > 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. I think we could live with that. It would be more convenient if you could right away place the code you send us under the LGPL, but either way is ok. Just send me the code along with either "I hereby release this code under the LGPL" or "I hereby release this code, as it is when it is finally merged into Wine, under the LGPL." - Dan
Re: SourceForge community awards ... we won ... ;)
On Wednesday 15 October 2008 15:46:25 Marcus Meissner wrote: > Hi, > > We won in the > SourceForge.net2008 Community Choice Awards > https://sourceforge.net/community/cca08/ > > in the Category: "Most Likely to Be Ambiguously and Baselessly Accused of > Patent Violation" So, given that this was over in July, who got the trophy? :) Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher is watching lostwages patches
On Tue, Oct 14, 2008 at 11:11 PM, Scott Ritchie <[EMAIL PROTECTED]> wrote: > Just a small bug, but patchwatcher is complaining about my lostwages > patch not applying. Yeah, that's one of the many known bugs. When I have time to work on patchwatcher, which isn't often, my top priority is getting the multislave rewrite finished; Rob's helping with that. Once that's up, we'll bring over all the bugfixes I did after I branched, and replace the old patchwatcher. And THEN we'll fix these bugs. The only thing I'm doing now to the old patchwatcher is expanding the blacklist as needed, which isn't often.
Re: SourceForge community awards ... we won ... ;)
2008/10/15 Marcus Meissner <[EMAIL PROTECTED]>: > Hi, > > We won in the > SourceForge.net2008 Community Choice Awards > https://sourceforge.net/community/cca08/ > > in the Category: "Most Likely to Be Ambiguously and Baselessly Accused of > Patent Violation" > > :) > > Ciao, Marcus > Cool :-)
SourceForge community awards ... we won ... ;)
Hi, We won in the SourceForge.net2008 Community Choice Awards https://sourceforge.net/community/cca08/ in the Category: "Most Likely to Be Ambiguously and Baselessly Accused of Patent Violation" :) Ciao, Marcus
[RFC] jscript: Fix shift/reduce conflict by removing redundant FunctionDeclaration rule.
The rule is implemented by FunctionExpression which is reduced using
the Statement rule.
---
dlls/jscript/parser.y | 37 -
1 files changed, 0 insertions(+), 37 deletions(-)
The tests pass with this change, but I haven't looked in detail as to
whether it will break anything. Jacek, can you check that your
applications that use jscript still work after this patch is applied?
diff --git a/dlls/jscript/parser.y b/dlls/jscript/parser.y
index af3d35d..e982954 100644
--- a/dlls/jscript/parser.y
+++ b/dlls/jscript/parser.y
@@ -142,11 +142,8 @@ static expression_t *new_literal_expression(parser_ctx_t*,literal_t*);
static expression_t *new_array_literal_expression(parser_ctx_t*,element_list_t*,int);
static expression_t *new_prop_and_value_expression(parser_ctx_t*,property_list_t*);
-static function_declaration_t *new_function_declaration(parser_ctx_t*,const WCHAR*,parameter_list_t*,
-source_elements_t*,const WCHAR*,DWORD);
static source_elements_t *new_source_elements(parser_ctx_t*);
static source_elements_t *source_elements_add_statement(source_elements_t*,statement_t*);
-static source_elements_t *source_elements_add_function(source_elements_t*,function_declaration_t*);
%}
@@ -207,7 +204,6 @@ static source_elements_t *source_elements_add_function(source_elements_t*,functi
%type TryStatement
%type Finally
%type StatementList StatementList_opt
-%type FunctionDeclaration
%type FormalParameterList FormalParameterList_opt
%type Expression Expression_opt
%type ExpressionNoIn ExpressionNoIn_opt
@@ -267,13 +263,6 @@ SourceElements
: /* empty */ { $$ = new_source_elements(ctx); }
| SourceElements Statement
{ $$ = source_elements_add_statement($1, $2); }
-| SourceElements FunctionDeclaration
-{ $$ = source_elements_add_function($1, $2); }
-
-/* ECMA-262 3rd Edition13 */
-FunctionDeclaration
-: KFunction tIdentifier '(' FormalParameterList_opt ')' '{' FunctionBody '}'
-{ $$ = new_function_declaration(ctx, $2, $4, $7, $1, $8-$1+1); }
/* ECMA-262 3rd Edition13 */
FunctionExpression
@@ -1474,21 +1463,6 @@ static expression_t *new_literal_expression(parser_ctx_t *ctx, literal_t *litera
return &ret->expr;
}
-static function_declaration_t *new_function_declaration(parser_ctx_t *ctx, const WCHAR *identifier,
- parameter_list_t *parameter_list, source_elements_t *source_elements, const WCHAR *src_str, DWORD src_len)
-{
-function_declaration_t *ret = parser_alloc(ctx, sizeof(function_declaration_t));
-
-ret->identifier = identifier;
-ret->parameter_list = parameter_list ? parameter_list->head : NULL;
-ret->source_elements = source_elements;
-ret->src_str = src_str;
-ret->src_len = src_len;
-ret->next = NULL;
-
-return ret;
-}
-
static source_elements_t *new_source_elements(parser_ctx_t *ctx)
{
source_elements_t *ret = parser_alloc(ctx, sizeof(source_elements_t));
@@ -1508,17 +1482,6 @@ static source_elements_t *source_elements_add_statement(source_elements_t *sourc
return source_elements;
}
-static source_elements_t *source_elements_add_function(source_elements_t *source_elements,
- function_declaration_t *function_declaration)
-{
-if(source_elements->functions_tail)
-source_elements->functions_tail = source_elements->functions_tail->next = function_declaration;
-else
-source_elements->functions = source_elements->functions_tail = function_declaration;
-
-return source_elements;
-}
-
statement_list_t *new_statement_list(parser_ctx_t *ctx, statement_t *statement)
{
statement_list_t *ret = parser_alloc_tmp(ctx, sizeof(statement_list_t));
Re: [PATCH 03/10] jscript: Added NaN value implementation.
Jacek Caban <[EMAIL PROTECTED]> writes:
> +#include
> +#include "basetsd.h"
> +
> +#ifndef NAN
> +
> +#ifdef __GNUC__
> +
> +# define NAN \
> + (__extension__
> \
> + ((union { unsigned __l __attribute__ ((__mode__ (__SI__))); float __d; })
> \
> +{ __l: 0x7fc0UL }).__d)
> +
> +#else /* __GNUC__ */
> +
> +#ifdef WORDS_BIGENDIAN
> +# define __nan_bytes { 0x7f, 0xc0, 0, 0 }
> +#else
> +# define __nan_bytes { 0, 0, 0xc0, 0x7f }
> +#endif
> +
> +static union { unsigned char __c[4]; float __d; } __nan_union
> +__attribute_used__ = { __nan_bytes };
> +# define NAN(__nan_union.__d)
> +
> +#endif /* __GNUC__ */
> +
> +#endif /* NAN */
I'd suggest to take advantage of the variant union instead of copying
all these glibc definitions. Something like
#ifdef NAN
V_R8(&vt) = NAN;
#else
V_I8(&vt) = nan_magic_pattern;
#endif
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: rpcrt4(2/2): Use pseudo-random numbers to generate UUIDs rather than using the (old, deprecated) MAC-address-and-time generation algorithm
"Juan Lang" <[EMAIL PROTECTED]> writes: >> The change is OK but you'll want to flesh out RtlGenRandom first, >> currently it will fail pretty badly if /dev/urandom isn't available. > > Ah, good point. Thanks. Where isn't it available, out of curiosity? I thought it was missing on Solaris, but apparently it's there too. So probably a FIXME on failure would be enough for now. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Kernel32: 3GB UserSpace boot option
You still need to prove the second part of your claims. Please don't omit wine-devel from the cc: list. [I'm intentionally top posting so that you caould see why it's bad] "Stefan Reimer" <[EMAIL PROTECTED]> wrote: > Yeap I did, see: > > [EMAIL PROTECTED] ~ $ winedump .wine/drive_c/Program\ Files/Sony/EverQuest\ > II/EverQuest2.exe > Contents of .wine/drive_c/Program Files/Sony/EverQuest II/EverQuest2.exe: > 12918784 bytes > > File Header > Machine: 014C (i386) > Number of Sections: 6 > TimeDateStamp:48EF93D1 (Fri Oct 10 19:41:37 2008) offset > 336 > PointerToSymbolTable: > NumberOfSymbols: > SizeOfOptionalHeader: 00E0 > Characteristics: 012E > EXECUTABLE_IMAGE > LINE_NUMS_STRIPPED > LOCAL_SYMS_STRIPPED > LARGE_ADDRESS_AWARE > 32BIT_MACHINE > > > > Done dumping .wine/drive_c/Program Files/Sony/EverQuest II/EverQuest2.exe > > > "Stefan Reimer" <[EMAIL PROTECTED]> wrote: > > > >> The EQ2 binary is large address aware. > >> > >> Windows changes it upper most user space address from 0x7FFE to > >> 0xBFFE booting with /3GB and this is not possible in wine right now > >> as > >> I think. > > > > Did you really check that? -- Dmitry.
Re[9] [user32: 2/2] Testcase for font size = 0x7fff
> This will also affect the Wine RC compiler as well. Even the Windows RC compiler emits an invalid template in that case. I just tested with this .rc file: #include MSGBOXFONT DIALOGEX 0,0,128,128 STYLE WS_SYSMENU|WS_CAPTION|WS_POPUP|DS_SETFONT|DS_MODALFRAME CAPTION "Test" FONT 0x7fff,"",0,0,0 BEGIN LTEXT "WINE dialog test.",-1,0,0,128,128 END RC version is 6.1.6723.1 It would complain that the font name was missing if I'd give it only "FONT 0x7fff". And it emits the 6 bytes for the '"",0,0,0' part (which it shouldn't)
Re: Kernel32: 3GB UserSpace boot option
On Wednesday 15 October 2008 01:37:46 am Dmitry Timoshkov wrote: > There is no need for hacks like that, 3 Gb address space limit is already > implemented in Wine, but is being activated only for applications marked > as IMAGE_FILE_LARGE_ADDRESS_AWARE for obvious reasons. Doesn't that only work if Windows is already booted in 3GB mode? I thought I read somewhere that the flag doesn't do anything if the system wasn't booted with /3GB.. Here: "The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB. The virtual address space of processes and applications is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file." http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Re[5] [user32: 2/2] Testcase for font size = 0x7fff
> 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.
Re: Kernel32: 3GB UserSpace boot option
"Stefan Reimer" <[EMAIL PROTECTED]> wrote: > The EQ2 binary is large address aware. > > Windows changes it upper most user space address from 0x7FFE to > 0xBFFE booting with /3GB and this is not possible in wine right now as > I think. Did you really check that? -- Dmitry.
Re: Kernel32: 3GB UserSpace boot option
The EQ2 binary is large address aware. Windows changes it upper most user space address from 0x7FFE to 0xBFFE booting with /3GB and this is not possible in wine right now as I think. Stefan > "Stefan Reimer" <[EMAIL PROTECTED]> wrote: > >> 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 ? > > There is no need for hacks like that, 3 Gb address space limit is already > implemented in Wine, but is being activated only for applications marked > as IMAGE_FILE_LARGE_ADDRESS_AWARE for obvious reasons. > > -- > Dmitry. >
Re: setupapi tests question
2008/10/15 Dmitry Timoshkov <[EMAIL PROTECTED]>: > "Reece Dunn" <[EMAIL PROTECTED]> wrote: > >> 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? > > Looks like setupapi.lib from PSDK misses at least MyFree, MyMalloc and > MyRealloc setupapi.dll exports. According to MSDN: "Note that if the version of SetupAPI.dll is less than 5.0.2195, then the caller needs to use the exported function MyFree from SetupAPI to free the memory allocated by this function, rather then using LocalFree. If the call to LocalFree causes an Access Violation, you should solve the problem by using MyFree." Therefore a GetProcAddress call is needed to get the MyFree function. >> Why does this work with a Wine/MinGW build and not VC9? > > The answer is obvious I'd assume. It is obvious when you understand the answer to the previous question. - Reece
Re: Kernel32: 3GB UserSpace boot option
"Stefan Reimer" <[EMAIL PROTECTED]> wrote: > 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 ? There is no need for hacks like that, 3 Gb address space limit is already implemented in Wine, but is being activated only for applications marked as IMAGE_FILE_LARGE_ADDRESS_AWARE for obvious reasons. -- Dmitry.
Re: setupapi tests question
"Reece Dunn" <[EMAIL PROTECTED]> wrote: > 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? Looks like setupapi.lib from PSDK misses at least MyFree, MyMalloc and MyRealloc setupapi.dll exports. > Why does this work with a Wine/MinGW build and not VC9? The answer is obvious I'd assume. -- Dmitry.
Re: Kernel32: 3GB UserSpace boot option
Stefan Reimer wrote: > 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. Coincidentally, I saw this post on the Ubuntu forums about another application (Blockland) that appears similarly affected: http://ubuntuforums.org/showthread.php?t=948170 Thanks, Scott Ritchie
setupapi tests question
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
Kernel32: 3GB UserSpace boot option
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 *)0x0001; - cachedsi.lpMaximumApplicationAddress= (void *)0x7FFE; + cachedsi.lpMaximumApplicationAddress= (void *)0xBFFE; 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 *)0x7ffe; +char *user_space_limit = (char *)0xbffe; reserve_malloc_space( 8 * 1024 * 1024 );
