GCC Bugzilla Bug 30335

CreateFileMapping fails in Vista due to lack of admin privileges

Created an attachment (id=12848) [edit]
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 an attachment (id=12997) [edit]
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