I am working in managed C++. I have a Mutex object in which I need to
replace the Handle property with a new handle. The new handle is being
constructed using Win32 CreateMutex call. I need to call the Win32 version
in order to set the security descriptor for the mutex, which is not natively
supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge
Win32 with .NET, so I want to make sure there is not the possibility of
calamity here.
The following code is a snippet of one of the managed class methods that I
am using to return a Mutex object with the replaced handle. Will the new
handle be released by the finalizer of the Mutex object, or do I have to do
this manually?
Also, I am not even sure if the code below will work. Can someone verify
please?
static SECURITY_ATTRIBUTES SecAttr;
static SECURITY_DESCRIPTOR SecDesc;
Mutex *Utility::CreateOpenAccessMutex(BOOL InitialyOwn, String *Name, BOOL
*CreatedNew)
{
Mutex *Ret = __gc new Mutex();
HANDLE OldHandle = (HANDLE) Ret->Handle.ToInt32();
CloseHandle(OldHandle);
// Security settings must be explicitly set to allow full access to the
mutex.
InitializeSecurityDescriptor(&SecDesc,SECURITY_DES CRIPTOR_REVISION);
SetSecurityDescriptorDacl(&SecDesc,TRUE,(PACL) NULL,FALSE);
Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name));
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
*CreatedNew = TRUE;
}
else
{
*CreatedNew = FALSE;
}
return Ret;
}
--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
----------------------------------- 7 1792
Ken Varn wrote: I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here.
The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually?
Also, I am not even sure if the code below will work. Can someone verify please?
I didn't try it, but looking at the .NET 1.1 source code, it looks like it
ought to be fine. The Handle property of System.Threading.WaitHandle gives
full transparent read/write access to the underlying handle, so when you
assign to the Handle property you're really changing the underlying handle.
You do need to close the old handle value, which you're doing, so I'd say
you're A-OK.
-cd
Well, I tried this out, but something doesn't seem right.
When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of
the Win32 handle is always <undefined> when I look at it in the debugger. I
have even tried type casting it to an INT *, and it comes out as 0. Yet,
when I inspect the Mutex->Handle value, it is a positive number. I don't
understand what is going on here with the IntPtr. Also, when I try to
assign a new value the Matrix->Handle, and I inspect it in the debugger, it
still shows the old value.
I may be getting confused by the behavior of IntPtr and how the debugger
shows the output. Could you please clarify this behavior of IntPtr?
--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
-----------------------------------
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:ej*************@TK2MSFTNGP15.phx.gbl... Ken Varn wrote: I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here.
The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually?
Also, I am not even sure if the code below will work. Can someone verify please? I didn't try it, but looking at the .NET 1.1 source code, it looks like it ought to be fine. The Handle property of System.Threading.WaitHandle
gives full transparent read/write access to the underlying handle, so when you assign to the Handle property you're really changing the underlying
handle. You do need to close the old handle value, which you're doing, so I'd say you're A-OK.
-cd
Ken Varn wrote: Well, I tried this out, but something doesn't seem right.
When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of the Win32 handle is always <undefined> when I look at it in the debugger. I have even tried type casting it to an INT *, and it comes out as 0. Yet, when I inspect the Mutex->Handle value, it is a positive number. I don't understand what is going on here with the IntPtr. Also, when I try to assign a new value the Matrix->Handle, and I inspect it in the debugger, it still shows the old value.
I may be getting confused by the behavior of IntPtr and how the debugger shows the output. Could you please clarify this behavior of IntPtr?
There's no light I can shed on the subject really - it sounds like a
debugger bug to me. Perhaps someone else knows.
Other than the oddness in the debugger, does the mutex appear to behave as
you expect?
-cd
"Ken Varn" <nospam> wrote in message
news:ef**************@TK2MSFTNGP12.phx.gbl... I am working in managed C++. I have a Mutex object in which I need to replace the Handle property with a new handle. The new handle is being constructed using Win32 CreateMutex call. I need to call the Win32 version in order to set the security descriptor for the mutex, which is not natively supported in .NET Framework 1.1.
I always get a little nervous about resource leaks when trying to bridge Win32 with .NET, so I want to make sure there is not the possibility of calamity here.
The following code is a snippet of one of the managed class methods that I am using to return a Mutex object with the replaced handle. Will the new handle be released by the finalizer of the Mutex object, or do I have to do this manually?
Also, I am not even sure if the code below will work. Can someone verify please?
static SECURITY_ATTRIBUTES SecAttr; static SECURITY_DESCRIPTOR SecDesc;
Mutex *Utility::CreateOpenAccessMutex(BOOL InitialyOwn, String *Name, BOOL *CreatedNew) { Mutex *Ret = __gc new Mutex();
HANDLE OldHandle = (HANDLE) Ret->Handle.ToInt32();
CloseHandle(OldHandle);
// Security settings must be explicitly set to allow full access to the mutex. InitializeSecurityDescriptor(&SecDesc,SECURITY_DES CRIPTOR_REVISION); SetSecurityDescriptorDacl(&SecDesc,TRUE,(PACL) NULL,FALSE);
Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name));
if (GetLastError() == ERROR_ALREADY_EXISTS) { *CreatedNew = TRUE; } else { *CreatedNew = FALSE; }
return Ret; }
-- ----------------------------------- Ken Varn Senior Software Engineer Diebold Inc.
EmailID = varnk Domain = Diebold.com -----------------------------------
IMO This:
Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name));
is invalid, you assign a void* to an IntPtr, you have to initialize a new
IntPtr using the void* value returned by CreateMutex like this....
Ret->Handle = IntPtr(CreateMutex(&SecAttr,InitialyOwn, ....
Willy.
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message news:% IMO This: Ret->Handle = CreateMutex(&SecAttr,InitialyOwn, CString(Name)); is invalid, you assign a void* to an IntPtr, you have to initialize a new IntPtr using the void* value returned by CreateMutex like this....
Ret->Handle = IntPtr(CreateMutex(&SecAttr,InitialyOwn, ....
Willy.
Forget about this, there is an op_explicit(void*) for the IntPtr, so a
simple assignment should work.
Willy.
Well, I did a ToString() call on the Handle and it appears to have been
changed properly. The problem must be with the debugger output when
inspecting pointers. It seems to only want to show the value that the
pointer points to rather than the actual value of the pointer itself. Maybe
this is because of it running in the managed mode.
--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.
EmailID = varnk
Domain = Diebold.com
-----------------------------------
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:%2****************@TK2MSFTNGP09.phx.gbl... Ken Varn wrote: Well, I tried this out, but something doesn't seem right.
When I assign the Mutex->Handle value to a Win32 HANDLE type, the value of the Win32 handle is always <undefined> when I look at it in the debugger. I have even tried type casting it to an INT *, and it comes out as 0. Yet, when I inspect the Mutex->Handle value, it is a positive number. I don't understand what is going on here with the IntPtr. Also, when I try to assign a new value the Matrix->Handle, and I inspect it in the debugger, it still shows the old value.
I may be getting confused by the behavior of IntPtr and how the debugger shows the output. Could you please clarify this behavior of IntPtr?
There's no light I can shed on the subject really - it sounds like a debugger bug to me. Perhaps someone else knows.
Other than the oddness in the debugger, does the mutex appear to behave as you expect?
-cd
Ken Varn wrote: Well, I did a ToString() call on the Handle and it appears to have been changed properly. The problem must be with the debugger output when inspecting pointers. It seems to only want to show the value that the pointer points to rather than the actual value of the pointer itself. Maybe this is because of it running in the managed mode.
That's probably reasonable. Despite the fact that Handle is defined as
IntPtr, and native HANDLE is defined as void*, it's really just an integer
index into a table - but there's really no way for the debugger to know
that.
-cd This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ken Varn |
last post by:
I have a named mutex object that is accessed by both an asp.net application
and a Windows executable .net application. The Windows executable runs
under the administrator logon, while the asp.net...
|
by: Rocky |
last post by:
I am using the following piece of code to ensure that my application only
runs once, however I have a few questions about it.
static Mutex m_Mutex; << in c# I assume that when the methods are...
|
by: PL |
last post by:
I simply cannot get this to work with my current project, if I create a test
project
with only the code below it works fine but in my real app it still allows
two instances.
using System;...
|
by: Ken Durden |
last post by:
I'm setting up an interface where clients must perform external
locking before calling certain commands. I do this to force them to
specify the duration the action they performed must persist...
|
by: Michael A. Covington |
last post by:
See:
http://www.ai.uga.edu/mc/SingleInstance.html
While attempting to use a mutex to allow only one instance of my app to run
at a time (Recipe 4.12 in C# Programmer's Cookbook), I found that if...
|
by: Kris |
last post by:
I want to set a mutex in one windows account and allow another windows account to access this mutex.
For testing I have two forms that create a mutex using the C# mutex class. I am logging into...
|
by: Ed Sutton |
last post by:
I use a mutex to disallow starting a second application instance. This
did not work in a release build until I made it static member of my
MainForm class.
In a debug build, first instance got...
|
by: Jeroen |
last post by:
Hi all,
I've been trying to get my head around threading. Here's an example
from the book I'm reading:
/***************************/
Mutex m = null;
const string name = "xyz";
try
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |