OK

Go over to Microsoft and download: WMI CIM Studio. With it you can search the entire WMI on your local machine. But, and I'm trying to remember, I think the IP address is written to the Registry when you connect to a Wireless network. I'd have to look it up. Get back tp you.

Yes, the objects are created with the new operator, that way I can just call delete on the object pointer. It's mostly for convenience. ...And, I only have one main thread in these applications,...the sequence of operations are not all that complicated. The end result is to write alot of the data to file. I had thought that for small objects, they would somehow live on the stack. (Shows you how ignorant I am of memory management.) The term "class objects" I just use to describe what is a contiguous block of data. You seemed to get the idea pretty clearly. Thanks for the information. I'll play around with it a little, just to get a better idea of how it works.

I'm basically curious about the heap, and how the operating system manages this type of memory. I have a couple of applications, in which I have created and allocated alot of data which resides in a single C++ class instance, and I have not used any explicit heap memory allocation functions. This seems to work fine, and I'm not likely to have any security-related problems (these objects are NOT COM objects, nor, are they shared resources nor accessed externally from my local machine). The size of these objects are in the range of 100 KB to about 350 KB. I'm wondering if this is a good idea, to just let the memory manager allocate this data, or should I explicitly allocate a private heap? These objects are usually used just as single instances,...occasionally, it will be deleted and re-allocated, but typically they are just single use class objects. Of course, I could break up the objects into alot of smaller components, but, then again, is this necessarily a good idea? I'd appreciate any suggestions. Thanks.

This doesn't really look like a COM problem,...but, copying the same image every time is probably because the HWND is the same every time. Give us some context as to where in an application this code is being executed.

hxhl95, The chapter about hooks from the Rootkits book by Hoglund is lengthy, and goes into great detail describing the most common hooking techniques used by malicious code. Rather than post the entire chapter (which would be HUGE), I just copied brief selections to give you an idea of what the general concept is. I left out a bunch of explanatory material. Alot of interesting information about the techniques used by malicious software are explained on: Rootkit[^] But, if you are trying to detect unauthorized hooks in your process address space (or others on the Local Machine), the concept is examine the address range of the DLL that exports the function called in the IAT of your process (the DLLs are all dynamically loaded by the system into your process address space), and determine if the address actually listed in the IAT corresponds to that range. If the process instead calls LoadLibrary and GetProcAddress to load the DLL on demand, the address entry in the IAT will NOT exist, so any malicious injected DLL code could not possibly overwrite the IAT address. (Actually, I'm unsure if the Operating System creates a temporary IAT entry at this point, but, I assume that it doesn't.) Go to SysInternals and download Process Explorer[^](FREE) to get a graphic representation of which dynamically loaded DLLs exist in your Process addesss space. Also,VMMap[^] is a very useful utility for understanding process address space memory allocations. An excellent overview of the Portable Executable format and its structures when loaded into memory is located at: Peering Inside the Portable Executable, Matt Pietrek[^]

I have copied a brief section here about the general techniques involved in looking for User Mode IAT hooks, again, from "Rootkits: Subverting the Windows Kernel". I have left out the description of Inline Hooks, because they are implemented in assembly language and require some experience in disassembling. Looking For Hooks A memory-based detection method is to look for hooks within the operating system and within processes. There are many places where a hook can hide, including the following: Import Address Table (IAT) System Service Dispatch Table (SSDT), also known as the KeServiceDescriptorTable Interrupt Descriptor Table (IDT) with one per CPU Drivers' I/O Request Packet (IRP) handler Inline function hooks The basic algorithm for identifying a hook is to look for branches that fall outside of an acceptable range. Such branches would be produced by instructions like call or jmp. Defining an acceptable range is not difficult (for the most part). In a process Import Address Table (IAT), the name of the module containing imported functions is listed. This module has a defined start address in memory, and a size. Those numbers are all you need to define an acceptable range. Likewise for device drivers: All legitimate I/O Request Packet (IRP) handlers should exist within a given driver's address range, and all entries in the System Service Dispatch Table (SSDT) should be within the address range of the kernel process, ntoskrnl.exe. Finding Interrupt Discriptor Table (IDT) hooks is a bit more difficult, because you do not know what the acceptable ranges should be for most of the interrupts. The one you know for sure, however, is the INT 2E handler. It should point to the kernel, ntoskrnl.exe. Inline hooks are the hardest to detect, because they can be located anywhere within the function—requiring a complete disassembly of the function in order to find them—and because functions can call addresses outside the module's address range under normal circumstances. In the following sections, we will explain how to detect SSDT, IAT, and some inline hooks. Finding IAT Hooks IAT hooks are extremely popular with current Windows rootkits. IAT hooks are in the userland portion of a process, so they are easier to program than kernel rootkits, and do not require the same level of privilege. Because of this, you should make sure your detection software looks for IAT hooks. Finding IAT hooks is very tedious, and implementing a search for them requires many of the techniques covered in previous chapters. Howev

In the book, "Rootkits: Subverting the Windows Kernel", by Greg Hoglund, the author devotes an entire chapter to Hooks, and in particular, IAT hooking, which is probably the best way to detect malicious code. I have copied a section here to give you an idea. He discusses hooking in terms of a rootkit injected into a remote computer. Import Address Table Hooking The simpler of the two userland hooking processes is called Import Address Table hooking. When an application uses a function in another binary, the application must import the address of the function. Most applications that use the Win32 API do so through an IAT, as noted earlier. Each DLL the application uses is contained in the application's image in the file system in a structure called the IMAGE_IMPORT_DESCRIPTOR. This structure contains the name of the DLL whose functions are imported by the application, and two pointers to two arrays of IMAGE_IMPORT_BY_NAME structures. The IMAGE_IMPORT_BY_NAME structure contains the names of the imported functions used by the application. When the operating system loads the application in memory, it parses these IMAGE_IMPORT_DESCRIPTOR structures and loads each required DLL into the application's memory. Once the DLL is mapped, the operating system then locates each imported function in memory and overwrites one of the IMAGE_IMPORT_BY_NAME arrays with the actual address of the function. Once your rootkit's hook function is in the application's address space, your rootkit can parse the PE format of the target application in memory and replace the target function's address in the IAT with the address of the hook function. Then, when the function is called, your hook will be executed instead of the original function. You can see that this is a very powerful yet rather simple technique. It does have its drawbacks, though, in that it is relatively easy to discover these types of hooks. On the other hand, hooks like these are used frequently, even by the operating system itself in a process called DLL forwarding. Even if someone is trying to detect a rootkit hook, determining what is a benign hook as opposed to a malicious hook is difficult. Another problem with this technique has to do with the binding time. Some applications do late-demand binding. With late-demand binding, function addresses are not resolved until the function is called. This reduces the amount of memory the application will use. These functions may not have addresses in the IAT when your rootkit attempts to hook them. Also, if the applic

There is also a complete reference on Windows Hooks over at MSDN: HOOKS[^]. I'd guess that you've already read it.

This is an excellent question. If you search over at MSDN you will discover: Win32 Hooks[^] The problem is that, if you want to detect ALL hooks, you're going to have to think about the Hooking techniques. The sneakiest hooks do NOT use the standard available Windows techniques. And, of course, Windows does not want you interferring in its Hooking Chain, so they don't provide you with an easy method of monitoring hook activity.

Managed DirectX is the variety that compiles with a NET Framework language, (C#),...you must have the NET Framework installed on the executing machine for it to work (and, yes, the SDK libraries that your program links to are different). From my experience, the Managed DirectX API functions have the same functions available as the COM DirectX (C++) version, but the syntax when writing code is slightly different. If you GOOGLE the two terms, you will find an enormous amount of information available (API Reference and tutorials). MSDN DirectX Developer Center[^] Also, if you had bothered to look around here at CodeProject, you would have found An Enormous Number of Excellent DirectX Articles[^]

...Ha Ha,...well, looks like I was wrong. Sorry. Did you give any thought to the problem? This would be a good place to start: DirectD3D Tutorials, MSDN[^], or, maybe, D3D Reference, MSDN[^] There is also a standard Direct D3D API: D3DXCreateCylinder[^]

I'm guessing, based on your post that you have not done much Direct3D programming (otherwise, you'd know the answer). Can you display a just a cylinder (without any modification)? That would be the obvious starting point. Wireframe? Solid? Lighting? What version DirectX? You leave out alot of important details. You should initially query the capabilities of your graphics device. But, essentially, I think you will want to coordinate the output of a number of standard DirectX APIs: Direct Input (to respond to the mouse action), and, the display of the cylinder data. The way I'd do it would be to implement a cylinder Mesh (which is a standard DirectX object), and which gives you access to the Vertex Buffer and Index Buffer (and all the other data you'll need). The easiet method would be to implement a series of drawing calls using a progressive algorithm that deforms the Mesh by some simple metric. You would be writing data to the Vertex Buffer and then displaying the Mesh. Also, there is a Graphics Forum here at CodeProject, where you'd probably get a better answer.

Both of the above books are good. The first is easier reading,...but Don Box, "Essential COM" explains that thinking that motivated the designers. There is an on-line book that covers a lot of the same material as both of the previously mentioned books, Inside COM+[^], to give you a idea of what COM architecture is like. Also, there are quite a few excellent articles about all aspects of COM, reight here at The Code Project.

Probably the most comprehensive approach is to look for the Utility that comes with the DirectX SDK (both version 9 and 10). It lives in the Utilities directory of wherever you installed the SDK on disc. As I recall, it's name is something obvious like, "DX9Capabilities". Launch it, and it will automatically query your Graphics Card and show you graphically what it's capabilities are. Then all you have to do is do a little research into what each designation actually means. The documentation that comes with the SDK should explain it all. You will discover that some DirectX APIs don't work because your Graphics Card doesn't perform a certain operation. It's a tedious process, but necessary in many circumstances where you are actually instructing the GPU to perform some computation (just by calling a standard DirectX API in your code). The API will often just fail silently, or return an almost useless error code like, D3DERR_INVALIDCALL. Determining your Graphics card capabilities beforehand prevents this kind of thing.

Initially, you want to determine the capabilities of your graphics card. That really is the main determinant for which APIs you can use in your application. Many applications call GetDeviceCaps when first initializing the Direct3D Device (this is the recommended technique both at MSDN, and in all the books written about DirectX 9 and 10 that I've read). Have a look at: D3DCAPS Structure[^] over at MSDN.

I would do it programmatically. MSDN Registering a Type Library[^]

This is probably the best place to start: Microsoft Developer Network Library[^]

I read your other post in the C++/MFC forum. Pallini is correct (always is, in fact), you must start with MIDL. You might also find this online book useful: Inside COM++[^]. It's quite similar to Don Box's, "Essential COM".

This is really interesting, and it sounds like an enormous amount of work. About a year ago, I was getting familiar with MIDI (a computer music format), and there was a company that was promoting a DirectX COM interface standard for creating what is known as a software synthesizer (which could process MIDI messages into sound). This component would be loaded into an application that would stream MIDI messages (which comprised a musical composition) to the synthesizer component, the COM interface would process the MIDI format and return a stream of what was essentially a continuous stream of WAVE format digital signals, which the application would then send to its own audio driver. Pretty complicated stuff. Anyway, the company (Cakewalk) that develops the music software, offers developers an SDK package (including source code for both minmal server and compatible client, and lots of html documentation) demonstrating the utility of the server component and the interface that the COM In-Process server must present to the Executable, and all the associated data structures, interfaces, callbacks, and related mechanisms required to make the whole thing work. Admittedly, it is probably more complicated that what you are suggesting. But, the point is that the COM structure must be provided and thoroughly tested, and the documentation must be clear to the client developer, before they can even begin to design a component that will interface with your server correctly. In the above mentioned example, I had to study the source code for several weeks before I completely understood how it worked, and especially, how the server-client connections were implemented. What you realize is that, the more complex the code model is, the more difficult it is to get it to work.