Printable View
This may seem like a weird question but I am new to linux(ubuntu) and I have noticed that I have no idea how to program it. I write in C and don't even know a header file to start with. I'm mostly looking for the linux equivelent of the windows api if there even is one. Thanks in advance.
You probably want to specify what you want to do. The Windows API is quite extensive, as it covers all the basic OS functionality and most of the GUI parts as well. In Linux, GUI is in X11 libraries and X11 headers, whilst the OS functionality is in other header files.
Also, using generic standard C functions is always a better solution if at all possible - it's obviously not always possible, but certainly would be my recommendation for the best solution when available.
--
Mats
I also have another question while were on the subject. How hard is it to get the windows sdk on linux and do some windows programming on linux?
Depending on what you want to achieve, it ranges from a fairly simple operation to near impossible. There are projects to allow WIndows operation on Linux (such as Wine, the WINdows Emulator), that allow you to use Windows applications on Linux - and I beleive you can use Visual Studio in Wine. Of ocurse, Wine isn't windows, so some things won't work the same - particularly device drivers and how stuff works in low-level functions may be quite different.Quote:
Originally Posted by lruc
But to get gcc natively on Linux compile something using the Windows SDK and then run it natively on Linux is something that would take an enormous amount of effort (and is probably not really wanted anyways).
--
Mats
I never had any intentions of running the application on linux. I just wanted to make the application on linux, and then use it on a windows computer.
Yes, I think Wine will allow you to do that, as long as you are aware that Wine isn't Widnows, it's an emulator "pretending" to be Windows (just like a Windows DOS emulator isn't DOS, so some things will work differently).Quote:
Originally Posted by lruc
--
Mats
To be strict, it's not an emulator :)
It works fairly well. Well enough for small programs, that you could then extensivly test under windows later. You just have to be careful that the "bugs" you have aren't due to the "emulation" rather than your program. Otherwise you can set up a cross-compiler if you have no intention of running it, but usually that's more effort than it's worth.
True, I guess the best word to describe it would be "interface shim" - as it translates various Windows System calls into Linux system calls. It also contains a kernel module that allows system call extensions to Linux to allow more windows-like system calls for some things.Quote:
Originally Posted by zacs7
--
Mats
That being said, I wasn't trying to correct you (no sir!). I call it an emulator all the time, it's far easier to call it that.
I've just got friends in the real world who work on wine and kick my butt everytime I call it an emulator :p
Wine doesn't stand for WINdows Emulator, it stands for Wine Is Not and Emulator, in the grand tradition of recursive acronyms.
Wine is really an implementation of the Win32 API on top of a POSIX OS interface and X11 graphics. The Windows OS provides another implementation on top of the Windows syscall interface.
Wine strives for binary compatibility, and to this end offers utilities that can load Windows executables and dynamic libraries under systems that do not natively support them, which means that you can run Windows applications without recompiling. However, Wine is also a bona fide library you can use in normal applications - if a Windows application doesn't use MS compiler extensions and you have the source (to the program, as well as all the non-system DLLs you're using), getting the code to compile under Linux with Wine should be trivial. Unless, of course, the particular features you're using aren't yet supported.
Also not quite true. The Win32 API is not the kernel syscall interface of Windows. In fact, Windows implements three APIs on top of the syscall layer: its own Win32, the OS/2 API, and (with the Unix compatibility layer installed) a largely POSIX-compatible interface. Unlike Cygwin, which implements POSIX on top of the Win32 API, the UCL bypasses this API.Quote:
as it translates various Windows System calls into Linux system calls.
How about POSIX what is that and where does it come in? Which headers are for the linux os functionality?
POSIX is a standard that defines a programming API and a set of command line tools that an OS could provide. If the OS does provide them, it is POSIX-compatible.
POSIX is derived from the things typical Unices provide, and all Unices and Unix-clones (including FreeBSD, Linux and MacOS X) strive to be fully POSIX-compliant.
POSIX's C API is based on the C runtime library. Where the CRT provides a feature, POSIX probably won't define an equivalent feature. For example, POSIX doesn't define its own memory allocation function; just use malloc(). On occasion, POSIX extends the C API, e.g. in the case of signal() and raise(), where it defines many more signals than just the few that C defines.
Linux OS functionality can be divided roughly into these parts:
1) Memory management: malloc, calloc, realloc, free, mmap, ...
2) File access: open, close, ioctl, fctrl, opendir, readdir, closedir, glob, stat, the C I/O library, ...
3) Network access: BSD sockets and various async I/O facilities
4) Process control: fork, clone, exec*, spawn*, wait*
5) Signals: signal, raise, ...
6) Interprocess communication: pipe, the SysV IPC functionality, futexes
7) Threading: the pthread library
I believe that covers everything important.
Ok one last question i promise. I tried using the cc built in compiler and I got the stupidest error iv'e recieved to this day.
Error: stdio.h, no such file or directory.
huh.
Do you have a /usr/include/stdio.h then?
You may need to install "glibc-devel" or something like that.
--
Mats
matsp is right, but I suggest you install the build-essential package instead (which "contains" the glibc-dev package in particular). So, in your favorite shell, type
Then you should be good IIRC.Code:sudo aptitude install build-essential
Ok it compiled good but the out file, which is new to me used to exe, won't even start.
Try running it asCode:./a.out
Also, you can name the executable anything you want by using the -o option:
Code:gcc -o myprog.exe myprog.c
But it is highly uncustomary for Linux executables to have an extension.
Of course, this can be done easier:Code:gcc -o myprog myprog.c
Code:make myprog
You should also check out the GNU docs:
www.delorie.com/gnu/docs/glibc/libc_toc.html
GNU make glibc and gcc (which all linux systems and distros use). These are quite readable and informative. I think they also address some of your question re: how POSIX relates to "C", etc.
Good luck.
True enough! Just thought it might shield him from the "horrors" of Linux ;)Quote:
Originally Posted by CornedBee
You know, I've been developing various *nix flavors for 13 years, and I did not know that. And a Google shows that if I set the CFLAGS environment variable, I can default to use -g -Wall. Thanks :)Quote:
Originally Posted by CornedBee