I thought Windows already provided this functionality via the Event logs. System Policy editor (gpedit.msc) -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy -> Audit process tracking (audit success). :doh: Unfortunately, this option also audits a heap of other events, in addition to process startup/shutdown.

Let's start off with a little modification of your original code. Use this WMI query instead, "Select * From Win32_ProcessStartTrace" to get notified of process creation. Now to receive notification whenever a new Win32_ProcessStartTrace is fired, you need to invoke that WMI query with ExecNotificationQueryAsync. This operates almost exactly like ExecNotificationQuery, except it takes one extra parameter: a pointer to your implementation of IWbemObjectSink. If you don't have an implementation of IWbemObjectSink, just use the stock implementation from MSDN[^] or Codeproject[^]. But why do you need to be notified when a new process is being created? What are you going to do to the process?

First of all, you should note that accuracy is not the same as precision[^]. 10ms is pretty much the most accurate you can get with Win32, without screwing with the operating system metrics or reinstalling the HAL. But anyway, you use timeSetEvent in C++/CLI the same way you use it in Win32.

#include #pragma comment(lib, "winmm")

public ref class TimerWrapper
{
EventHandle ^eventHandle;
public:
TimerWrapper()
: eventHandle(false, EventResetMode::AutoReset)
{
}

int TimerFunc()
{
for( ; ; )
{
eventHandle->WaitOne();
...
}
}

void UseTimeEvent()
{
timeSetEvent(100, 55, reinterpret_cast(
eventHandle->SafeWaitHandle->DangerousWaitHandle().ToPointer()),
0, TIME_ONESHOT | TIME_CALLBACK_EVENT_SET);
...
}
};

-- modified at 17:31 Saturday 13th May, 2006

You haven't yet created the Type library for the .NET DLL. To create a type library, you need to make use of the regasm.exe tool.

regasm.exe net.dll

Also make sure you have set the [ComVisible(true)] attribute

Let me guess... You're project uses a static lib that was compiled in VS2003.

For C++, you have quite a few classes in Codeproject's Threads and IPC section[^]. Examples: CMemMap[^] Which seemed to inspire... XQueue[^] and even Microsoft's own CAtlFileMapping class[^]. Raymond chen notes another method[^], but this one opens a security hole. But for managing variables via shared memory, you'll definitely want to use a helper class.

Once you've got the ProcessID, open up a handle to it and wait on it. I *think* :~ you can get the process handle directly by Win32_Process::Handle, but in case you can't OpenProcess/WaitForSingleObject will work.

That syntax is only valid (AFAICT) in a constructor. The syntax is used to initialise any base classes, and any members. By the time you enter the function, all external parameters need to have been initialized (base classes, members, and global variables). Although we already have syntax to initialise global variables, this is the only syntax available to initialise members and base classes.

<naughty>I see you skipped the chapter on initialisation lists when you were learning C++</naughty>. Well to be honest, it IS an obscure topic and quite easy to miss when you're learning C++. So I'll let you off... THIS time. Anyway, the answer is to use an initialisation list.

class TopClass()
{
TopClass(int xIn)
: x(xIn)
/** The above line tells the compiler to initialise
x to xIn, using the constructor that takes an int.
If you don't provide an initialisation list, the
default constructor is used **/
{
}
InClass x;
};

-- modified at 10:24 Monday 20th March, 2006

Since you posted in the C++/CLI forum, you implicitly admit your DLL was written in .NET. If you were lying and this DLL was not written in .NET then you have just posted in the wrong message board. Repost this question in the message board. Note that in .NET, CLR functions only have one calling convention, and that is __clrcall. The WINAPI or CDECL stuff only applies to native DLLs. If your function has uses WINAPI/CDECL, then your function is not written in .NET (see above). Also note that .NET DLLs do not export their CLR functions as dllexports. Instead, the functions are stored as Metadata, and are discovered using Reflection. The quick way to check the function signature is to add the DLL as a project reference (Project -> References -> Add New Reference -> Browse -> select your DLL -> OK OK). If this doesn't work, then your DLL is not a .NET DLL (see above). Now click on view Object Browser, and go down to the namespace of the DLL. This will show you all the function signatures in that DLL. How do you do this programmatically? The functions to use are given in System::Reflection. Once you have the System::Assembly of the DLL, call the Assembly::GetTypes method to get all the types of the assembly. Then you can call the GetMethods to get the methods in that Type (including private ones). To get the number and type of parameters, check out MethodInfo::GetParameters. That should allow you to discover the signature of the method.

Are you trying to force MFC into Express edition. Every other attempt I've seen to add MFC to Express has either ended in failure or the programmer getting Visual Studio Standard in one way or the other. Trying to shoehorn MFC into Express is not only dangerous, you risk infringing on your EULA for Visual Studio. Let's say you started to integrate MFC into Express now. How long will it take? 50 man-hours? 100 man-hours (there's a lot of code to alter)? Let's go for the lower number, for fairness. Now let's assume you're a low paid Junior developer that earns $15 an hour (you need to be an expert/experienced developer to know how to port MFC, but once again, let's assume for fairness), the time you lose by having to add MFC to express edition is 50 hours: 50 * 15 = $750. You've just cost you and your company $750.00. To compare, Visual Studio Standard costs less than $270 at Amazon. For the time you lost shoehorning MFC into Express edition, you could have bought two copies of Visual Studio Standard! To conclude, forcing MFC to work in Express edition is not only a waste of time, it's a waste of money!

Chintoo723 wrote:

2. Why I want to remove these files? I am writing a cleanup program in which I need to remove these files.

I hope you're not planning to differentiate between each application's IsolatedStorage Dir name. By this, I mean your program does: "Hmm... Publisher.cya1vn0ixvflytpedycizjvrbaqeoksg belongs to Regex designer. Let's tell the user that it belongs to Visual Studio". This feature (ie. identifying "Publisher.cya1vn0ixvflytpedycizjvrbaqeoksg" as belonging to this and that .NET program), I have no idea how to do without .NET to help. The other feature (doing a brute-force delete of the isolatedstorage folder), should be doable. FWIW, I WAS able to delete the IsolatedStorage folder. Therefore, I would check if some external process is still active and is locking the folder. If there is a process, find it and kill close it.

There isn't a magic MakeIsolatedStorage API in Win32, for the sam reasons there isn't an API to make World Peace :) or an API to solve all of Chintoo723's problems (personal and professional-wise) :-D or a SolveMeaningOfLife API :laugh:. But joking aside, your problem should be solvable, If you make it clearer what feature of IsolatedStorage you need. ie. why do you need IsolatedStorage? Is it for the per-user data, or the code access security, or do you need to get at the Publisher.cya1vn0ixvflytpedycizjvrbaqeoksg folder directly without using .NET (some kind of .NET diagnostic tool)?

Unless you can find a way to remove the use of MFC (eg. go to pure native Win32 or C++/CLI), you have no choice But to go for Visual Studio Standard or higher. VC Express does not include MFC. Therefore, your program won't work in the Express edition. MFC... not exactly plain C++ now is it :) ?

Mostly recompile your 32-bit shell extension DLL to Win64 (making sure you eliminate all warnings). Crank up the warning level and enable /Wp64 to ensure you eliminate all 64-bit related problems. Registering the DLL is slightly tougher, so you are recommended to use a setup package to do it for you (I heard that Inno setup was upgraded to support Win64).

In your Microsoft Visual Studio 8\SDK\v2.0\Bootstrapper\Packages\vcredist_x86 folder, there should be a file called vcredist_x86.exe. Run it on the other machine.

Yes (although I admit that the icon on the title bar just looks too weird for my tastes).

Haven't read the prerequisite literature (eg. Programming Windows or Teach yourself Visual C++ in 24 hours) before delving into Win32, eh :| ? Link[^].

The only way I'd expect this to work is if you disabled exceptions, disabled /GS support, used /NODEFAULTLIB, provided your own mainCRTStartup, and removed most use of the new CRTs. But if you've done all of this, you may as well static link, to remove all dependence on any CRT DLLs.

The MidiPlyr sample also has this problem. It doesn't fully scale to the window, hence the jumps in font size you see. So if Microsoft, for all their wealth, power and unrestricted access to the Windows source code, can't get it right, what hope do we poor insignificant developers who get the scrap heap public API, have :)?