Created attachment 12848 [details]
patch

the #include <tchar.h> should be removed from the patch - it doesn't belong there

See badvista.fsf.org

What do you want to tell me with this link? Without this patch I can not use gcc on Vista - which means I can not use other free software either because I am not able to compile it.

Should I set up a website like badgcc.windowsdevs.org now? Because noone cares about windows developers here?

No Vista support, broken linking when using virtual stdcall, ...

Just ignore comment #3 and post the patch to gcc-patches@gcc.gnu.org please, indicating which target you configured for and how you tested this patch
(a bootstrap and regtest is required).

This is a host issue only.

I am not in position to test this on Vista until next week. Can you please indicate how you tested.

Danny

This patch was tested by having various people on Vista (32/64) run a full build of ReactOS as a limited user. (also tchar.h is needed for compilation because of the _T macro)

Created attachment 12997 [details]
Patch for Vista/CreateFileMapping

It seems strange to me that CreateFileMapping puts _unnamed_ object into Global namespace.  Can you point me to documentation for this feature?

If CreateFileMapping functionality has changed, maybe we should just avoid it and use VirtualAlloc throughout.  Can you test attached patch with Reactos build?

Danny

Hi

I look at both patcher the frist one the "GCC-v4.1-r120189-CreateFileMapping-Vista.patch" is most correct one in my eyes. 

if you reading how CreateFileMapping works, at http://msdn2.microsoft.com/en-us/library/aa366537.aspx

I interper it the text as u always need to use "local\\name" to support more that one user. 

we need rember that apps can get admin right  in NT 2003 and down when they runs so they where allown to use NULL in the last param and gain admins right
in vista this is not posible any longer, letting program getting admin right 
when user have limit right. so now all program need follow the api to proper
 
Now we looking at the second patch the host-mingw32.c.diff 
I have not tested it in vista or windows yet. But what I can see
it using vritualalloc that mean it alloc memory and getting allot slower against
FileMapping we talking about allot extra comping time, and it is not a good idea for big project like reactos, and another thing the swap file will incress and windows does not always cleanup stuff in the swapfile until a reboot, that is few big disages with host-mingw32.c.diff it exists allot other disgante over it also.

(In reply to comment #11)
> Hi
> 
> 
> Now we looking at the second patch the host-mingw32.c.diff 
> I have not tested it in vista or windows yet. But what I can see
> it using vritualalloc that mean it alloc memory and getting allot slower
> against
> FileMapping we talking about allot extra comping time, and it is not a good
> idea for big project like reactos, and another thing the swap file will incress
> and windows does not always cleanup stuff in the swapfile until a reboot, that
> is few big disages with host-mingw32.c.diff it exists allot other disgante over

Huh?  This is called only once during compilation.  What evidence do you have that CreateFileMapping is faster than VirtualAlloc here?

We are not sharing memory across processes so we don't really need to create a named memory-mapped object. I would prefer to keep the memory object anonymous rather than hardcoding a name that could be accessed by other processes.

Danny

  

I tried the second Patch from danny and got the same results when I tried to build ReactOS in MultiCore, as with this one I used before.

http://www.reactos.org/paste/index.php/1aa48fc/

Fixed.  I have modified Christoph's original patch to avoid problems on NT4
Danny