I'm in the process of teaching myself C (coming from Java). I appreciate the language a lot, and one of the main reasons I am learning it is so that I can utilize the JNI feature built into Java to write native code when necessary. My question is mainly about the Windows API. Can I use the functions and features of the API using just C?
Will the Windows API be compatible with pure C code or does it contain classes and such that can only be utilized by C++ code?
Also, if I compiled a shared library on a Windows machine as (lib.sl NOT lib.dll), would it work on another machine (Mac/Linux)?
The Windows API (aka Win32 API) is a pure C library.
No you cannot use a Windows shared library on another non-Windows machine unless there is a software that supports Windows ABI - such as Wine or ReactOS.
Win32 API like others have pointed out is pure C. It means, once you get a hold of it, you will know everything about how the Operating system works. It is the same case usually with other operating systems as well. If you are after MFC/COM+ or Java wrappers, it is quite the opposite even if you can build great programs.
Related
I've got a question regarding writing applications for Windows. Can I use WinAPI and DWMApi (aero glass, ribbon, etc.) when programming in ANSI C? I'm looking at MSDN right now and they use c++.
The Windows API is a C API and can be used with any compiler that supports the 'standard' calling convention.
Microsoft has made the strategic decision to put their own C compiler on life support, though, and you're stuck with C90 (with some specific extension) when using Visual Studio. You can use 3rd party compilers (GCC and Clang via MinGW, Pelles C) which support more modern language dialects.
Try it.
Most APIs actually ARE C-APIs; they just call it C++ because "nobody" really uses C anymore. I've also noticed the occasional struct with additional functions attached to them, but definitely not in Win32, and they might just #ifdef that away for C.
The thing I don't know right away is whether the headers are "safe" when used with just C, and whether the libraries have unmangled symbols. I would assume they are, but one never knows. However, making a simple C program that just calls a single Win32 API function should clarify that.
The Win32 API is accessible from many different toolsets. All C compilers for Windows that I have ever come across can call all Win32 APIs. What's more all these C compilers can call COM APIs and even GDI+ which is a very C++ centric library. But MS provided a bridge for C clients to use.
So, in summary, choosing to use C will not deprive you of access to any part of Win32.
I looked at some other questions on SO and its not clear if c is built on top of, under, or alongside the WINAPI. Like for example could someone write something in pure c that was able to open a window, or would they need to use the windows api?
I noticed similarities between the c (library?) version of opening a file (fopen) vs the windows API version (CreateFile) which makes me wonder if one is just a wrapper for the other. Does anyone know?
If windows is running; is a programmer forced to program using the windows api to get something running on it or can the programmer not use the windows api at all and directly access the hardware (ie. does the windows operating system protect access to the hardware)?
Which is more portable between different versions of windows of windows ce. The documentation I found (which has now changed) used to say that CreateFile only goes back to version 2.0 of windows ce (here: http://msdn.microsoft.com/en-us/library/ms959950.aspx -
Notice the note on the link at the very bottom that shows the supported version information has been changed). So what is one supposed to use for windows ce version 1? In other words is programming using c functions or the functions labeled WINAPI more likely to work on all versions of windows CE?
I read the following in a book about programming windows ce and it confused me, so all of the above questions can be understood better in context of making sense of the following:
Windows CE supports the most of the same file I/O functions found on Windows NT and Windows 98. The same Win32 API calls, such as CreateFile, ReadFile, WriteFile and CloseFile, are all supported. A Windows CE programmer must be aware of a few differences, however. First of all, the standard C file I/O functions, such as fopen, fread, and fprintf, aren't supported under Windows CE. Likewise, the old Win16 standards, _lread, _lwrite, and _llseek, aren't supported. This isn't really a huge problem because all of these functions can easily be implemented by wrapping the Windows CE file functions with a small amount of code.
My understanding of wrapping is that you have to have something to wrap, given how it appears that win16 and c library are not available is he stating to wrap the CreateFile function to make your own c-like version of fopen? (The only other thing I am aware of is assembly, and if that is what he was suggesting to wrap it wouldn't be written in such a casual manner.)
Given the above, what is the dependency relationship between c language (syntax, data structures, flow control), the c function library (ex. fopen), and the windows api (ex. CreateFile)?
C existed long before Windows did. The Windows API is a bunch of libraries written in C. It may or may not be possible to duplicate its functionality yourself, depending on what Microsoft has documented or made available through the API. At some level it is likely that fopen() and CreateFile() each call the same or a similar operating system service, but it's unlikely that one is a strict wrapper for the other. It would probably be difficult to bypass the Windows API to access the hardware directly, but anything is possible given enough time and programming effort.
C doesn't know anything about GUIs, and VERY little about operating systems at all. Anything you do graphics-wise in C is through the use of libraries, of which the win32 api is an example.
The windows API is implemented in the C programming language. Functionality provided by the C standard libraries, such as fopen, is portable because it is compiled down to the appropriate assembly code for different architectures by different compilers. Windows API functions such as CreateFile only work on machines running Windows and are therefore not portable.
In theory it's possible to write C that talks directly to the hardware. Back in the days of MS-DOS (for one example) quite a few of us did on a fairly regular basis (since MS-DOS simply didn't provide what we needed). Edit: On some small embedded systems, it's still quite commonplace, but on typical desktop systems and such this has mostly disappeared.
Two things have changed. First, modern systems such as Linux and Windows are much more complete, so there's a lot less need to deal directly with the hardware. Second, most systems now run in protected mode, so normal user code can't talk directly to the hardware -- it has to go through some sort of device driver.
Yes, most of the C library uses the underlying OS so (for example) on Windows, fopen and fwrite will eventually call CreateFile and WriteFile, but on Linux they'll eventually call open and write instead.
I noticed similarities between the c (library?) version of opening a file (fopen) vs the windows API version (CreateFile)
Not surprising. They do similar things.
[is] one is just a wrapper for the other? Does anyone know?
You can't find out because the source code is owned and kept as a trade secret.
It doesn't matter which is more "fundamental". You use the windows API from a windows program. You use C API's from C programs.
Notice that it doesn't matter. You can use C API's or Windows API's intermixed.
If windows is running; is someone forced to use the windows api to get something running on it or can they bypass windows entirely and directly access the hardware?
"Directly access the hardware"? What does that mean? If windows is running, then.... well... Windows is running. Windows mediates your access to the hardware.
Use bootcamp or GRUB or some other bootloader to bypass Windows and have "direct access to the hardware".
If they can, is it possible to damage the hardware if you don't know what your doing?
What does this mean? Are you asking if you can "damage" some rotating media (i.e., disks) by misusing their drivers? You can corrupt your hard disk no matter what OS you're running or not running. A privileged account and dumb software can write bad data on a disk. Does that count as "damage"?
Which is more portable?
What does that mean? To another Windows computer? To a computer not running Windows? What are you asking about? Please clarify your question to define what you mean by "portable".
between different versions of windows
Since different Windows are mutually incompatible, I generally suggest using only the POSIX standard libraries and avoiding all Windows API's.
However, some Windows variants (e.g. Windows mobile for phone vs. Windows "Server") are essentially totally incompatible. There is very little reason for any piece of software to run on both OS's. Portability doesn't much matter. Why try to run a phone app on a server?
Edit
So theres the c language on the bottom (closest to the hardware), then the windows API next, then the C library on top of the Windows API?
This doesn't make sense. You're mixing up two unrelated things. The "language" and the "libraries" have little to do with each other.
Also, the API is not the operating system. So by using Windows "API" all the time, you're making this more confusing than it needs to be.
Here's a way to look at this.
The Windows Operating System has several API's. There are underlying function libraries that are not part of the application interface. They're "internal".
It has a native Windows API. Callable from C.
It has a POSIX API. Callable from C. In some cases, the Posix API generally uses the Windows API.
Most operating systems, including Windows are written in C (and or assembler). The Library is then modified for each operating system to do the basic stuff. (Sockets, Files, Memory, etc ...).
The WINAPI is just a bunch of libraries (written in C and/or Assembler) that allow access to functionality within the OS.
It is not Windows related, after you changed your question, I think what you are trying to understand is the bootstrapping of an OS (Windows or other).
The book Operating Systems Design and implementation discusses the implementation of Minix (Which Linux is based on).
the WINAPI provides an interface that developers in C can use in order to use the WINAPI functionality. C++ programs can also use it.
Operating systems such as Windows contain WINAPI libraries that provide access to some operating system functionality and sometimes contact with Hardware, these libraries are written in C
Carl Norum pointed out that C existed long before Windows, but don't forget that the Windows API kind of started with the MS-DOS API, which kind of started with the CP/M API. C only existed a short time before CP/M.
Lots of answers seem to imply that the Windows API is built on C, but that seems doubtful too. __stdcall is a synonym for PASCAL, which was a keyword in Microsoft's C compilers because the Windows API was built on Pascal. __cdecl is the default for function calls in C and C++ programs compiled by Visual Studio but it doesn't work on calls to APIs.
The relationship between C and the Windows API is that they are capable of working with each other.
As a fun note, you can really get a handle on the 'power' of the Windows API by taking a look at AutoIt http://www.autoitscript.com/autoit3/. AutoIt is a great little scripting language that can create GUIs, run command line apps, manipulate windows and processes, etc. Yes, it does File I/O and networking.
I'd hate to have to relearn C++ just for this! Any libraries/URLs would be great and yes, Google didn't help much here :-(
This is for an upcoming project in which my product (Java based) would provide support for Microsoft's Hyper-V virtualization platform. Unlike VMware, which provides a Web-service, the Hyper-V APIs are mere extensions of WMI. I'd prefer not to use commercial tools such as J-Integra for Java integration into COM/WMI and the few open source tools I found are way outdated.
I would rather use JNI with C than C++. Anybody know where I can find libraries et cetera for using C for WMI operations? In the same vein as Python clients can be used? (And yes, I know C is not an OOP language :D ).
Thanks in advance.
WMI is acessed via COM right?
While it is more verbose and more error-prone (it is easy to accidentally use different pointers for the vtable and the "this" parameter), you can also use COM from the C language.
You also could use C++ but treat it as "C with language extensions to make using COM easier".
The JNI interface itself is a derivative of COM and you will find those methods and the methods of the WMI interfaces much easier to use if you use enough C++ to treat interfaces as implemented by C++ classes.
The other thing that will be helpful is that you will be able to use the COM interface pointers and reference counting as a way to bind the lifecyle of the COM interface to the lifecycle of your JNI-implemented Java classes.
I used an approach like this to implement a Java bridge, via JNI, to some C Language interfaces on Windows. I hand-rolled COM interfaces and a .lib that is used in building the JNI DLL.
The difficult part, with WMI, is that you will want to use the standard COM APIs to Instantiate the COM objects, whereas I created my own custom "factory" code, since it was all a private implementation.
You can download a snapshot of my development tree for the ODMJNI 1.0 0.50beta Function-Complete Release. If you look at info.odma.odmjni100 in the development tree you'll see how the JNI DLL is built (using VC++ 2005 Express Edition) and Java 1.5. The OdmJniBind.java class consists of the static methods that are used in the Java classes to coordinate object lifecycles between Java Classes and COM Object interfaces. (the OdmNative peer section of the tree provides the implementation of the OdmNative100.lib that is used in compiling the odmjni100.dll that is used via JNI.
#z0ltan
You can write your code in C but you ll have to save the file as CPP. As someone had mentioned earlier, for DCOM support your file needs to be a CPP file.
#Umi
For Java Integration - compile your WMI code in C/CPP as a DLL (with proper JNI header files) and then you will have to load the DLL library file. Once this is done, you can access the WMI methods in DLL files just like calling a Java Method.
What is the relationship between the Windows API and the C run time library?
In a nutshell: The Windows API contains all the functions defined specifically for Windows. The C run-time library contains all the functions that are required by standard C.
The physical libraries that implement these functions may be a single file (library), split across two separate libraries or split into many libraries, depending on the operating system and the actual API/service you are using.
For example, when creating files, the C standard includes the function:
fopen
to open and create files, etc., while the Win32 API (for example) defines functions like:
CreateFile
to create and manipulate files. The first one will be available wherever a standard C run-time library is available while the second one will only be available on a Windows machine that supports the Win32 API.
If you mean the standard C library (msvcrt.dll I assume). Then not much at all. The majority of the windows API is implemented in separate dlls (very much of it is in user32.dll or kernel32.dll). In fact, some of these functions in the Windows API are just thin wrappers around system calls where the actual work is done in the kernel itself.
Also, as ocdecio said, it is entirely reasonable to assume that certain parts of the C standard library are implemented using windows APIs. And for certain cases like string manipulations, vice versa.
EDIT: since which dlls are implemented in terms of others has come into question, i've checked with dependancy walker and here is my findings:
kernel32.dll depends on:
ntdll.dll
user32.dll depends on:
gdi32.dll
kernel32
ntdll.dll
advapi.dll
msimg32.dll
powerprof.dll (this dll references msvcrt.dll for some string functions)
winsta.dll
msvcrt.dll depends on:
kernel32.dll (yes it does have imports for CreateFileA)
ntdll.dll
based off of this, I believe that msvcrt is build on top of the win32 API.
Win32 is a completely different beast to the CRT.
CRT is something that needs to be linked into your project when you use C or C++ functions/features (such as printf or cout).
Win32 is a set of libraries that need to be linked into your project when you use Windows features (like GetWindowText).
What they are:
The Windows API is the API exported by the Microsoft Windows[TM] Operating System
The C run time library is the "standard library" which is shipped with the C compiler by the compiler vendor, and which is available on whichever/any operating system (for example, Unix) is targetted by the compiler
What their relationship is:
They are distinct, but both equally available to C++ applications running on Windows
On Windows, the C standard library is implemented by invoking the underlying Windows API (to allocate memory, open files, etc.).
C run time library is based on the Windows API
Unix System calls are analogy with Windows API.
What things should be kept most in mind when writing cross-platform applications in C? Targeted platforms: 32-bit Intel based PC, Mac, and Linux. I'm especially looking for the type of versatility that Jungle Disk has in their USB desktop edition ( http://www.jungledisk.com/desktop/download.aspx )
What are tips and "gotchas" for this type of development?
I maintained for a number of years an ANSI C networking library that was ported to close to 30 different OS's and compilers. The library didn't have any GUI components, which made it easier. We ended up abstracting out into dedicated source files any routine that was not consistent across platforms, and used #defines where appropriate in those source files. This kept the code that was adjusted per platform isolated away from the main business logic of the library. We also made extensive use of typedefs and our own dedicated types so that we could easily change them per platform if needed. This made the port to 64-bit platforms fairly easy.
If you are looking to have GUI components, I would suggest looking at GUI toolkits such as WxWindows or Qt (which are both C++ libraries).
Try to avoid platform-dependent #ifdefs, as they tend to grow exponentially when you add new platforms. Instead, try to organize your source files as a tree with platform-independent code at the root, and platform-dependent code on the "leaves". There is a nice book on the subject, Multi-Platform Code Management. Sample code in it may look obsolete, but ideas described in the book are still brilliantly vital.
Further to Kyle's answer, I would strongly recommend against trying to use the Posix subsystem in Windows. It's implemented to an absolute bare minimum level such that Microsoft can claim "Posix support" on a feature sheet tick box. Perhaps somebody out there actually uses it, but I've never encountered it in real life.
One can certainly write cross-platform C code, you just have to be aware of the differences between platforms, and test, test, test. Unit tests and a CI (continuous integration) solution will go a long way toward making sure your program works across all your target platforms.
A good approach is to isolate the system-dependent stuff in one or a few modules at most. Provide a system-independent interface from that module. Then build everything else on top of that module, so it doesn't depend on the system you're compiling for.
XVT have a cross platform GUI C API which is mature 15+ years and sits on top of the native windowing toollkits. See WWW.XVT.COM.
They support at least LINUX, Windows, and MAC.
Try to write as much as you can with POSIX. Mac and Linux support POSIX natively and Windows has a system that can run it (as far as I know - I've never actually used it). If your app is graphical, both Mac and Linux support X11 libraries (Linux natively, Mac through X11.app) and there are numerous ways of getting X11 apps to run on Windows.
However, if you're looking for true multi-platform deployment, you should probably switch to a language like Java or Python that's capable of running the same program on multiple systems with little or no change.
Edit: I just downloaded the application and looked at the files. It does appear to have binaries for all 3 platforms in one directory. If your concern is in how to write apps that can be moved from machine to machine without losing settings, you should probably write all your configuration to a file in the same directory as the executable and not touch the Windows registry or create any dot directories in the home folder of the user that's running the program on Linux or Mac. And as far as creating a cross-distribution Linux binary, 32-bit POSIX/X11 would probably be the safest bet. I'm not sure what JungleDisk uses as I'm currently on a Mac.
There do exist quite few portable libraries just examples I've worked within the past
1) glib and gtk+
2) libcurl
3) libapr
Those cover nearly every platform and so they are extremly useful tool.
Posix is fine on Unices but well I doubt it's that great on windows, besides we do not have any stuff for portable GUIs there.
I also second the recommendation to separate code for different platforms into different modules/trees instead of ifdefs.
Also I recommend to check beforehand what are the differences in you platforms and how you could abstract them. E.g. this is some OS related stuff (e.g. the annoying CR,CRLF,LF in text files), or hardware stuff. E.g. the previous mentioned posix compability doesnt stop you from
int c;
fread(&c, sizeof(int), 1, file);
But on different hardware platforms the internal memory layout can be complete different (endianess), forcing you to use conversion functions on some of the target platforms.
You can use NAppGUI for both console and desktop apps. The SDK uses ANSI-C and your code will work on Windows/macOS/Linux.
https://www.nappgui.com
It's free and OpenSource.