I was reading through Windows process APIs, and was left with three questions:
What is the difference between base APIs and shell APIs? I read that shell APIs wrap base APIs e.g. ShellExecute() and ShellExecuteEx() wrap CreateProcess() but fail to understand the distinction.
How are base APIs and Shell APIs different from CRT functions (C Runtime). As again, exec() and spawn() CRT functions wrap CreateProcess() of the base API.
I understand that I can use base APIs and CRT functions from code directly by compiling and linking with the correct header files. How do I make use of Shell APIs?
1) What is the difference between base API's and shell API's?
They do different things. ShellExecute family does things in the same way as the shell, i.e. in the same way as windows explorer. It is not simply a wrapper around CreateProcess. For example, if you pass to ShellExecute the path to a word document, ShellExecute will look up in the registry to find out what is the correct way to open a word document, and do that.
ShellExecute can also do the other "verbs" you see on the Windows context menu, such as edit, print, etc.
2) How are base API's and Shell API's different from CRT functions
CRT functions are implemented on Windows so as to be compatible with the C standard. They are wrappers around CreateProcess, but the reason they exist is to be compatible not to offer additional functionality.
3) How do I make use of Shell API's
To use the shell APIs you simply include the header files and link the correct library, just as with any other API.
For example, ShellExecute:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx
As you see at the bottom of the page it tells you which file to include and which library to link against.
Requirements
Minimum supported client: Windows XP [desktop apps only]
Minimum supported server: Windows 2000 Server [desktop apps only]
Header: Shellapi.h
Library: Shell32.lib
DLL: Shell32.dll (version 3.51 or later)
Unicode and ANSI names: ShellExecuteW (Unicode) and ShellExecuteA
(ANSI)
The shell (aka Windows Explorer) adds an extra layer of functionality. It manages file associations, it knows what EXE should be started when you ask it to "run" a document. If you pass the name of, say, a .html file then ShellExecuteEx() can figure out that a browser needs to be started. It also supports verbs, different things you can do with a document. Other than "open", the default verb, the "print" and "edit" verbs are common for example.
That's missing from CreateProcess(), it only knows how to start an executable file. Still with lots of options, review the MSDN docs for the security attributes and creation flag options.
Lots of those whistles are missing from the CRT functions, they work on any operating system so you cannot do much beyond specifying the executable name and the command line arguments.
Related
I am not sure if StringCbPrintf and the include file strsafe.h where it is defined belong the the WinAPI. On one hand, Microsoft documents the function on its WinAPI sites and strsafe.h is under the Windows SDK directory structure which indicates (to me, at least) that it is indeed part of the WinAPI. On the other hand, strsafe.h includes stdio.h etc. which belong to the CRT. I was always under the impression that the WinAPI is completely independent from the CRT (but not vice versa). Possibly, my assumption about the relationship between WinAPI and CRT is wrong. Thus my question: is StringCbPrintf part of the WinAPI?
The StrSafe API is a bit strange because it does not have its own .DLL nor its own exported functions. I assume it was developed this way because it needed to support older versions of Windows that had already been released. It was created during the WinXP service pack security push:
During February and March 2002, all application development in
Microsoft stopped and developers took part in the Security Push
initiative. The goal was to check all code for possible security
vulnerabilities and fix those problems. One of the outcomes of the
Security Push was a library of safe string functions called
"strsafe.lib" with an associated header called "strsafe.h." This
library is available through the Platform SDK that can be downloaded
from the MSDN web site and is automatically installed as part of
Visual C++.NET 2003.
As far as I can tell, a copy of strsafe.h was also included with Writing Secure Code (Second Edition) by Michael Howard and David LeBlanc but I'm not sure if they are the original authors (David LeBlanc is the author of SafeInt):
You can find a copy of Strsafe.h in the companion content in the
folder Secureco2\Strsafe.
msvcrt.dll is basically a system file these days, only Windows 95 shipped without it. You are not supposed to use it as your C run-time but SDK code from Microsoft can probably use it without issues.
msvcrt.dll is now a "known DLL," meaning that it is a system
component owned and built by Windows. It is intended for future
use only by system-level components.
If you want to use msvcrt.dll as your C run-time as well then you must use the WDK for <= Windows 7 but when using the inline version of StrSafe.h, as long as you link to a .lib that contains the required vsnprintf type functions it should not really matter which CRT it comes from. There is also a StrSafe.lib file but Microsoft recommends that you use the inline version.
You are correct that the Windows API is supposed to be independent of the CRT but StrSafe also supports stdin functions like StringCbGetsA and they did not choose to separate those into a separate header for whatever reason. That combined with the need for a existing vsnprintf type function to do the actual work means that StrSafe is somewhat attached to the CRT even though it is meant to be used by all WinAPI developers.
There is probably no true answer to whether it is part of the WinAPI or not since it is a bit subjective. Since it is included with the SDK in the include folder one would assume that Microsoft believes it is a SDK/API component and not a CRT component.
If it's not implemented in Windows and exported from one of its DLLs (as e.g. CreateFile() or CloseHandle() from kernel32.dll), I'd say it's not part of the WinAPI, even if it ends up calling things that are implemented in Windows.
Is it possible to create a new, arbitrary, file namespace scheme in Windows?
As best I understand, Windows currently understands two or three file system or file-system-like namespace schemes:
The namespace scheme we all know and love, eg, C:\path\to\file.
UNC paths, eg, \\server\path\to\file
One, perhaps uncommon scheme - the Windows NT Object Manager, eg, \\.\Device\COM1 - see WinObj on SysInternals, usually accessed by programs by calling CreateFile, though this is not really a file system.
Is it possible to implement a custom namespace scheme that would be universally, automatically used by the rest of the operating system? Perhaps a filter driver or some other specialized kernel-mode driver? I'm out of my league here, but I'm genuinely curious.
I don't have anything concrete, but lets say I wanted to implement a kernel driver that, not only understands how to read and write OpenVMS file systems, but also implements some sort of filter driver so that userland programs could use standard File-11 syntax to access such a filesystem.
For example, an existing program calls OpenFile("[DIR1.DIR2.DIR3]FILE.EXT;10"); and somehow a custom handler deals with it transparently, and lo, notepad can read and write VMS files. More importantly, perhaps, some ported program that expects OpenVMS File-11 path strings just works. Simply mapping the OpenVMS file system into the regular windows file system as D:\dir1\dir2\file.ext would be insufficient.
I should clarify that my OpenVMS reference is just an example; I'd be looking for a more generic solution. This could be for OpenVMS File-11, MVS, standard unix syntax ala /path/to/thing, or something I just cooked up myself.
I'm aware of shell-based namespace extensions, and compatibility layers like cygwin, but that's not what I'm looking for.
So SO, what do you think? Is this possible? Where do you start?
I'd like to write a debugging/diagnostic tool which can call Windbg functions to examine a dump file, instead of writing a windbg extension. Is this possible and any references?
Thanks a lot.
Rather than WinDbg, you can use the Debugging API which is implemented in dbghelp.dll. It's documented on MSDN. That reference documentation is rather dry, but it should give you an idea of the capabilities of the API. For example, MiniDumpReadDumpStream is the gateway to examining dump files.
In addition to the existing answers, WinDBG is a GUI front end for the DbgEng API. You can use this API to write either WinDBG extensions or other standalone applications. The WinDBG SDK ships with samples of both, an example standalone application can be found in the \sdk\samples\dumpstk subdirectory of your WinDBG install.
For more information, I wrote an article about DbgEng to write extensions here:
http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=559
Most of that will also apply for how you write a standalone application as it mostly focuses on the programming pattern of the DbgEng interface.
here are some links that use dbgeng interfaces to make standalone executables.
a short summary of the process is to
call DebugCreate() to create a client
call QueryInterFace()
and call one of its methods
http://www.woodmann.com/forum/entry.php?252-Dbgeng-based-handles-(PART-2-)
http://www.woodmann.com/forum/entry.php?246-A-Simple-Dbgeng-Based-User-Mode-Debugger
http://www.woodmann.com/forum/entry.php?248-DbgEng-Based-Debugger-(PART2)
http://www.woodmann.com/forum/entry.php?249-DbgEng-Based-Debugger-(PART2-Contd-)
http://www.woodmann.com/forum/entry.php?250-DbgEng-based-Kernel-Debugger
http://www.woodmann.com/forum/entry.php?251-Dbgeng-based-Handles
You could make commands using powershell or to the command line version of WinDbg which is cdb and then parse the output from cdb which you interpret.
This would be similar notion to piping the output from cdb to your app.
There is post about using powershell in this manner: http://rkeithhill.wordpress.com/2006/08/14/minidump-crash-analysis-with-powershell/
It should be straightforward to pump commands to cdb and interpret the output for specific commands.
Python integrated with dbgeng:
pykd.codeplex.com
This project may be use as a demo for such integration
I have a code which is running on DOS Box in windows 7...However my question is whether my code is using the Windoows API or not? Below are the headers file which I am using...
#include<iostream.h>
#include<conio.h>
#include<dos.h>
#include<graphics.h>
#include<process.h>
Why don't you take a look at that code? If there are any Windows specific APIs being used, it won't be too hard to find them by looking at included header files.
DOSBox can run Windows 3.1 and associated programs, but if your program runs outside of Windows 3.1, then you can be pretty sure that no Windows APIs are being used.
These headers are not part of the Windows API, and in fact, it's unlikely that your code will compile at all using a compiler other than Borland Turbo C/C++.
It looks like you're using mostly proprietary Borland libraries. For example, graphics.h allows you to draw graphics in a text-based MS-DOS environment. It's not supported under Windows at all.
Even the header files like conio.h that you'll probably find in other compilers may not be compatible with the one you're using in your code. The library functions declared by conio.h vary somewhat from one compiler to another.
As a general rule, every program that uses the Windows API will include windows.h, and perhaps some additional child header files, depending on the specific functionality needed.
Most of the information you have received so far is too general. The headers that are included dont show you everything.
1) the compiler used will include headers behind-the-scenes
2) the librarys linked are only loosly coupled to the headers that you specified
Example:
if you use MinGW and include no headers explicitly it will link to stdlib.h behind the scenes and this will be linked to the Windows API without you ever knowing it.
if you then call malloc() it will be translated to HeapAlloc (Windows API) by the mingw-Headers and obviously linked to the Windows API.
Simple question here (though perhaps not such a simple answer):
Is it possible to specify a path for an (existing) named pipe that can be used by programs as if they were opening on a normal file?
According to this MSDN page, name pipes on the local computer can be referrenced using the following path syntax: \\.\pipe\PipeName, yet I'm having no luck using this from standard Windows programs.
As a side point, if anyone has any suggestions for interfacing with programs that are only capable of using the file-system in a more efficient manner than physical I/O (e.g. named pipes), I would be glad to take them.
It would only work if the programs are using the Win32 API CreateFile() function to open the files.