User account creation filtered due to spam.

Bug 30335 - CreateFileMapping fails in Vista due to lack of admin privileges
Summary: CreateFileMapping fails in Vista due to lack of admin privileges
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: 4.3.0
Assignee: Danny Smith
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-30 23:46 UTC by Christoph von Wittich
Modified: 2007-07-18 11:44 UTC (History)
3 users (show)

See Also:
Host: mingw32-*-*
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-01-01 01:53:22


Attachments
patch (427 bytes, patch)
2006-12-30 23:46 UTC, Christoph von Wittich
Details | Diff
Patch for Vista/CreateFileMapping (1.30 KB, patch)
2007-02-02 19:31 UTC, Danny Smith
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph von Wittich 2006-12-30 23:46:19 UTC
CreateFileMapping fails in Vista due to lack of admin privileges
Comment 1 Christoph von Wittich 2006-12-30 23:46:47 UTC
Created attachment 12848 [details]
patch
Comment 2 Christoph von Wittich 2006-12-30 23:49:38 UTC
the #include <tchar.h> should be removed from the patch - it doesn't belong there
Comment 3 Andrew Pinski 2006-12-31 12:08:21 UTC
See badvista.fsf.org
Comment 4 Christoph von Wittich 2006-12-31 13:48:05 UTC
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, ...
Comment 5 Richard Biener 2006-12-31 14:16:18 UTC
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).
Comment 6 Andrew Pinski 2006-12-31 16:55:22 UTC
This is a host issue only.
Comment 7 Danny Smith 2007-01-01 01:53:22 UTC
I am not in position to test this on Vista until next week. Can you please indicate how you tested.

Danny
Comment 8 Peter Ward 2007-01-02 20:25:10 UTC
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)
Comment 9 Danny Smith 2007-02-02 19:31:24 UTC
Created attachment 12997 [details]
Patch for Vista/CreateFileMapping
Comment 10 Danny Smith 2007-02-02 19:32:45 UTC
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
Comment 11 Magnus Olsen 2007-06-03 17:48:12 UTC
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.
Comment 12 Danny Smith 2007-06-03 21:37:45 UTC
(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

  


Comment 13 Daniel Reimer 2007-06-12 22:07:11 UTC
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.
Comment 14 Daniel Reimer 2007-06-12 22:13:06 UTC
http://www.reactos.org/paste/index.php/1aa48fc/
Comment 15 Danny Smith 2007-07-18 11:44:07 UTC
Fixed.  I have modified Christoph's original patch to avoid problems on NT4
Danny