Thought I'd close on that /unsafe+ problem...

When using /unsafe+, the cs.exe compiler calls EEStartup(DWORD fFlags) in
ceemain.cpp. I don't know why the same sequence doesn't happen
when /unsafe+ is not used, but it doesn't really matter.

>From EEStartup() the sequence is as follows:

EEStartup() -> static HRESULT InitializeIPCManager(void) ->
IPCWriterInterface::CreatePrivateBlockOnPid(DWORD pid, BOOL inService,
HINSTANCE *phInstIPCBlockOwner) -> PAL_CreateFileMappingW( ... )  ->
CreateFileMappingW( ... lpObjectName );

The problem is the value of lpObjectName which
is "Global\RotorefjnlhjmdlgchclbchlnabekeinilkebjhbhfpalRotor_Private_IPCBl
ock_394" (after hashing). The issue is that CreateFileMappingW(...) on NT
does not support backslash in the object name (I think this is new for
w2k.)

So, there you have it... I didn't have time to check whether there are any
other issues with NT, but the build seems to have moved pretty far already.

Cristian

On Wed, 18 Sep 2002 15:29:40 -0700, John Norwood <[EMAIL PROTECTED]>
wrote:

>>The interesting part is that if I just remove /unsafe+ from the command
>line above, the code
>>compiles fine. I just don't see what the relationship is between
>generating unsafe code and
>>the search path for compilation.
>
>The first place I would have thought to look would be yet another
>command interpreter issue but I don't see anything obvious.  I'm
>surprised you haven't hit more command interpeter issues since the batch
>files are pretty dependent on Win2K behavior.
>
>It looks like you've whittled the response file down quite a bit so it
>probably isn't something simple like a truncated command-line and I
>can't see how that would cause this error.
>
>The /unsafe+ option does exercise a lot more code in the C# compiler so
>it's possible that some PAL/API call is being made that has different
>results under NT4.  You might need to run C# under a debugger during the
>build of this directory to see where the error is originating and what
>it really is.
>
>There doesn't appear to be a reason to have /unsafe switched on for
>isymmanagedwrapper.  You could turn it off in the sources file by
>removing the line: CSHARP_ALLOW_UNSAFE=1. It would be a good idea to
>check for the effects of this by running the full test suite.
>
>Your example did help me spot the fact that we seem to be adding
>mscorlib as a reference twice in the response file which is a bug.
>
>John
>
>
>This posting is provided "AS IS" with no warranties, and confers no
>rights.

Reply via email to