I have an application, written in C, which runs on multiple platforms: Windows and various flavors of Unix. The two most important are Linux, then Windows.
One of the core algorithms could benefit from CUDA acceleration. However, everything must run normally if the system isn't CUDA-capable, (or the user doesn't specifically ask for GPGPU acceleration).
So, I need to make sure the application tries to load the CUDA libraries only under the right circumstances.
On Windows, the delay-load mechanism makes this fairly easy.
Is there a similarly easy mechanism to do this on Linux? Or do I have to go through the contortions involved with dlopen()?
You have two choices, both perfectly valid:
As you note in your question, use dlopen to load dynamic libraries at runtime
Statically link the CUDA toolkit libraries into your application. NVIDIA have been shipping static versions of the toolkit libraries for linux for several major release cycles, and static linking is fully supported. The downside of this approach is application size.
I am currently in the process of developing the OS for a consumer electronics product my company is developing. I have settled on freeRTOS as the backbone for our OS, and am working diligently to implement hardware functionality within the OS. However, I have run into an issue concerning running 3rd-party applications from within freeRTOS.
Originally I considered a task to be an application, where basically you had "myapplication.c" and "myapplication.h" containing all your applications necessary functions and the code would reside within the for(;;) loop within the task (acting as a main while loop). Then when the user decides to run that application, a function pointer is passed to a queue, that my app_launcher task then uses to create the new task using the 3rd-party task or application.
The problem with this approach however, is the OS will already be compiled and reside on the microcontroller, and applications with be installed and deleted as the user sees fit... So obviously applications need to be compiled and executable from the OS. On a standard unix machine, I would use something like fork, to select the executable and give it it's own process. However I cannot find a similar functionality within freeRTOS.. My other idea is approaching a scripting language for app development, but again I'm not sure on how to launch those applications...
So the question is, how do I get freeRTOS to run applications from 3rd party developers that aren't already baked into the OS?
FreeRTOS (and most RTOSes for that matter) do not work like general purpose operating systems (GPOS), they are not generally designed to dynamically load and execute arbitrary user supplied applications. In most case you use an RTOS because you require hard real-time response and the execution of third-party code could compromise that.
Most RTOSes (FreeRTOS included) are no more that static-link libraries, where your entire embedded application is statically linked with the RTOS and executes as a single multi-threaded program.
Again many RTOSes (like FreeRTOS) are not operating systems in the same sense as a GPOS such as Linux. Typically the RTOS services available are the real-time scheduler, inter-process communication (IPC), thread-synchronisation, and timers. Middle-ware such as a file system, and network stack for example are either optional extensions or must be integrated from third-party code.
One problem you will have with FreeRTOS trying to achieve your aim is that a "task" is analogous to a "thread" rather than a "process" in the sense of a GPOS process model. A task typically operates in the same memory space as other tasks with no memory protection between tasks. Tasks are not separate programs, but threads within a single application.
If your target has no MMU then memory protection may be limited in any case, but you may still want third-party applications to be conceptually independent from the OS. If your processor does not have an MMU, then running arbitrary third-party dynamically loaded code may be a problem for system integrity, safety and security. Even with an MMU a simple RTOS kernel such as FreeRTOS won't use it.
Operating systems with real-time scheduling that can load and run application code dynamically as separate processes include:
Windows Embedded Compact (formerly Windows CE)
QNX Neutrino
OS-9
Also VxWorks has the ability to load partially linked object code and dynamically link it to the already loaded code. This is not the same at a process model, but is more akin to a dynamic-link library. What makes it worth mentioning in this context is that the VxWorks shell can invoke any function with external linkage by name. So you can load an object file implementing a function and then run that function. You could in principle implement the same functionality on FreeRTOS, but it is non trivial. The shell is one thing, but dynamic loading and linking requires the application symbol table to be target resident.
If you don't need hard real-time (or your real-time requirements are "soft") and your target has sufficient resources, you may be better served deploying Linux or uClinux which are increasingly used in embedded systems.
If the code your end-users need to run are tightly related to the purpose of your device rather than "general purpose" in nature then another possibility for allowing end-users to run code is to integrate a scripting language interpreter such as Lua. In this case you would simply load the script from a file system and pass it to the script interpreter. For more general purpose requirements a Java VM may be a possibility.
Due to request, here is the work around I found to my problem. The issue was launching other applications from freeRTOS. This was accomplished by utilizing the "System()" function in the newlib library. Thus, I can place an application in flash until it's needed, then launch it using the newlib functions provided. This also allows me to launch programs dynamically, without hard coding the code or name of the application, I just need to provide System() with a string, pointing to the app's location in memory.
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.
I have just started reading about threading in C, using pthreads. I know that Pthreads are available for Windows, but do multithreaded WIndows based C/C++ applications mostly use Pthreads?
Also in Unix/Linux are Pthreads the main way developers write multithreaded C/C++ code?
No, most will use the thread abstraction of the application/gui library they are using, e.g. MFC. Or in the plain C case, using the windows API directly.
Pthreads stands for "POSIX" threads, which is basically standarized unix(-like), a standard that has little meaning on Windows outside dedicated POSIX emulations like cygwin.
The new C++ Standard, C++11, has support for portable threads. I'd definitely go with that, except that Visual Studio hasn't implemented them yet.
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.