POSIX 2008 offers a family of functions with *at() prefix, like openat(), which operates on files relatively the given directory descriptor. These functions seem practical in multi-threading environment, since they avoid potential races if some thread called chdir() or fchdir(). As I see the same goal can be achieved using Nt API like NtCreateFile(), if OBJECT_ATTRIBUTES structure has RootDirectory member set. What I'd like to do is to NtCreateFile() Nt handle and convert it to Win32 handle since a lot of my API depends on Win32 handles (e.g. as I understand ReadFile() can work only on Win32 handles). Is it possible? Or shall I rewrite the entire API to use Nt functions (e.g. NtReadFile(), NtWriteFile() and so on)?
Related
In its simplest form, COM allows you to instantiate C++-like classes from DLL in your application. Basically it's a glorified wrapper around LoadLibrary and some conventions regarding the interface. This is called using an in-process component.
But COM also supports out-of-process components. If you instantiate a class from such a component, COM starts a new process. Your objects live in said process, and are marshalled transparently over to you, so you don't care too much about where they live. They might even be on a different computer (DCOM). You can also fetch objects from already running applications. A well-known example is controlling MS Office via a script. This is called Automation (formerly OLE Automation, and there is a bit of confusion around what exactly this term encompasses).
There are a couple of nice articles explaining how (in-process) COM works low-level (e.g. COM from scratch. I'd like to know how it works when your component is out-of-process. Especially, what IPC does COM use beneath the hood to communicate between the processes? Window messages, shared memory, sockets, or something else? MSDN lists COM as an IPC method by itself, but I'm guessing it has to use something else underneath. Are different IPC methods used in different cases (instantiating an OOP component from C++, accessing an Excel document from VBScript, embedding a document in another via OLE)? It seems like it is all the same underlying technology. And lastly, how does marshalling fit in the picture? I believe it is neccessary to serialize method parameters for transmitting between processes, correct?
According to this MSDN article, it's RPC.
When you instantiate an OOP component, the COM subsystem generates an in-process proxy. This proxy is responsible for packing parameters and unpacking return values. It also generates a stub in the server process, which, expectably, unpacks parameters and packs return values.
Interestingly enough, the whole marshaling process can be customized, by implementing IMarshal.
DCOM was originally added as an extension to COM, precisely for cross apartment calls. Note cross apartment calls are not always from process to process. A process can have many apartments (0 or 1 MTA and/or 0 to n STAs, etc.) . There is at least one apartment per process, etc.
DCOM, some kind of a "middleware", needed a technology for all this low-level work: data representation, caller/callee convention, memory management, wire marshaling, session handling, security, error handling, etc. so Microsoft naturally used the in-house implementation of DCE/RPC: MSRPC. Note that as Microsoft says on its site,
"With the exception of some of its advanced features, Microsoft RPC is
interoperable with other vendors’ implementations of OSF RPC."
There was some tentative work to have all this implemented by other vendors, but they were basically killed by the rise of the internet and HTTP.
Also, note this RPC uses Windows Messages for STA apartement messages. I suggest you read carefully this document (not available any more on Microsoft site, shame on them :-) for more details:
DCOM Architecture by Markus Horstmann and Mary Kirtland - July 23, 1997 .
See also this interesting case study about a DCOM/RCP issue that should tell you a lot of how RPC over Windows message works under the scene: Troubleshooting a DCOM issue: Case Study
Windows Resource Monitor displays (among other things) which files on disk are currently accessed by which processes. And it does that in realtime. How?
I know that it probably uses ETW and that I can generate traces with tools like xperf. But how to get realtime information without having to start, stop and parse a trace file?
I need to programmatically access the data, i.e. from C# or C++.
wOpenTrace/ProcessTrace/StopTrace can get the data in real-time as long as you know the provider GUID. They can run on Win2000 but you need to parse the raw data in your callback functions. To convert raw data into human-readable text, we need the TMF/MOF. Not sure if they are public though.
For Vista/Win7, there is a new set of TDH (Trace Data Helper) APIs (eg: TdhFormatProperty).
Scroll down a little of above links and you can see them. The good thing about TDH is they can parse the data for you (still need to provide TDH the TMF/MOF though).
I tried to write my own .etl to readable .txt program using Open/Process/StopTrace API (because I need to support XP). I found out it's quite difficult. The TMF file is not hard to interpret since it pure text. The hard thing is to decipher more than 50 different undocumented prinf-alike format-specifications' internal structures. So I gave up in the end and stick to the powerful tracefmt.exe provided in Microsoft WDK.
What is the difference between a Win32 or DirectX wrapper and a Win32 or DirectX framework?
A wrapper is typically a family of functions that contain the function calls for a library or API like win32, DirectX, etc., in some sort of abstracted way to the end-user. Many times they are customized so that the functions you call in the wrapper is not exactly the same as the original API, or some default parameters have been setup for you to make working with the API a bit easier. Also in the specific instance of a language wrapper, the functionality has been embedded in the language's run-time API, and then exposed to the end-user. For example, one could expose the win32 calls to a Python user by creating a C-library plug-in for python with the win32 API calls, and then creating a python library that may have customized python functions that call the win32 functions exposed by the C-library plugin. In this case the Python library "wraps" the native C-based win32 library.
A framework is like a wrapper, but in its most-typically used definition, it's a little different in that it works by creating some type of run-time environment that you create callbacks to plug into, so that when the frame-work wants to-do some task, you've written a function that is called for that task. This is called the "Hollywood Principal" of programming, which basically says, "don't call us, we'll call you". So in working with this model, you create functions, register them with the frame-work, and your function is called when the frame-work needs to call it, and the framework passes its own internal parameters as your function arguments. A good example is a GUI-framework, where you create callbacks for buttons and other events, and the GUI-framework calls those functions as it processes its runtime event-loop.
So I guess one way to think of the primary differentiation between the two is that wrappers tend to be static (i.e. exposing libraries and functions with customized function calls either that fill-in default values for you or translate them to a different language), whereas a framework tends to be dynamic (i.e. its a runtime system that you create callbacks for, and register it with the framework that are then called during some time of runtime event loop or kernel, etc., like a GUI toolkit).
Wrappers tend to make it possible (oftentimes easier) to access complex systems, complex code or combinations of calls from multiple classes and so forth. For example, you may create a Facebook wrapper in C# or Java to interact with getting user data from the Facebook API, which has many REST-based functions which return JSON. A framework is a set of related objects, functions, and so forth to provide a particular functionality, or enhance a particular functionality, so you wouldn't use either a wrapper or framework. Oftentimes you'll use a both, using a wrapper to access a framework. This is especially true with legacy systems :)
What is the difference between NtCreateProcess and ZwCreateProcess? In ntdll.dll, both NtCreateProcess and ZwCreateProcess point to exactly the same address
In user-mode the groups of Nt and Zw APIs are identical. In kernel mode they are different. The Nt API contains the actual implementation. The Zw API uses a system-call mechanism and ensures that it is calling in kernel-mode and that there is no need to check the parameters if they contain user-mode addresses. Otherwise you could use the API from user-mode with kernel parameters which would not be good. So it is just a safety mechanism.
Aside from the already given answer (which I don't want to parrot), in my opinion the best answer can be found on OSR Online: here.
Alternatively you can read books on the Native API, such as the one from Gary Nebbett called "Windows NT/2000 Native API Reference", he devotes some space to this very question, or you can use WinDbg (pronounced as "wind-bag") yourself.
Are there any places where one is preferable to another? Is there a performance impact to using one over the other?
#Alex K.: Small remark: NtFsControlFile is documented in http://msdn.microsoft.com/en-us/library/ff566462(v=VS.85).aspx. Kernel mode application should use ZwFsControlFile function and user mode application can use NtFsControlFile.
#vedang: From you question I would assume that you don't a developer of kernel mode driver. So I will strictly recommend you to use only DeviceIoControl to send FSCTL_XXX codes http://msdn.microsoft.com/en-us/library/aa364230(v=VS.85).aspx.
Only if you plan to write an application which don't use Win32 subsystem and use NT native subsystem only like a small checkdisk application or disk defragmentation application which run at the beginning of the windows start (see session manager registry key) than you will have advantage in using of NtFsControlFile. In all cases of usual work you should use only DeviceIoControl.
I have no idea about implementation, but NtFsControlFile is an undocumented kernel internal and it's use comes with the risk that it will disappear/change implementation at some point in the future, whereas DeviceIoControl is part of the public Win32 API.