I am porting my application to windows from Linux. I am fairly new to the fine-art of porting application across platforms. As far as I know, Windows does not natively support POSIX threads implementation. Is this true? I have heard about some implementation of pthreads for windows (a wrapper or something), would it be better to use them or use CreateMutex and other APIs provided by windows???? Someone pls. enlighten me with the PROs and CONs of both worlds. Some miscellaneous tips for porting would go nicely along with the answer.
Thanks in advance.
It's all going to be the same stuff (pthreads is just going to call EnterCriticalSection etc), so if you've got a pthreads wrapper, you should probably use it so that you don't have to change as much code
this works well: http://sourceware.org/pthreads-win32/
It is a port of the pthreads library for Windows.
One thing you need to keep in mind is what is the future of this code. Do you plan on developing (and releasing) on both platforms in the future? Or is this a one way port?
The best thing to do when porting a project is to keep the actual changes to the code as minimal as possible. In your case, this would mean going with a pthread solution. That being said, if you are planning this to be a one way port, going native never hurts. :)
I would take some time to fully examine both stratigies and then implement the one you feel most comfortable with.
The first thing I'd do is to port to Boost Thread under Linux than to Windows.
Why not have the best of both worlds and use a library that wraps both pthreads and Window's API and uses the appropriate one under the covers? Your code stays the same on both platforms.
There are no shortage of such libs in C++ so I can't imagine there aren't C versions about.
On Windows C/C++ applications that use the CRT need to call beginthread/beginthreadex to properly initialize the CRT in the new thread.
Related
I'm in my third year studying computer science, so I should probably actually know the answer to this question already, but nonetheless, I don't. Anyway, I'm taking the OS course for my degree currently and we've been been covering a lot of new programming concepts like signals, semaphores, and threads in C. Unfortunately, my prof is covering all of these in a Linux/OS X perspective. What this means for me, being on a 64-bit windows machine, is that things like installing an alarm signal, or using semaphores and pthreads won't compile or run on my machine (as far as I can tell).
Anyway, currently I have just been doing my assignments in a VM running Linux, which has worked well so far, but I much prefer the Windows environment for coding.
So, after that heavy winded introduction, my question is, as you might have already guessed, is there a way to code with all these features (alarm signals, semaphores, pthreads, etc.) and be able to compile and test them in Windows? I'm fully aware that the Windows OS does not support the alarm signal and has limited POSIX capability, but I've heard rumors tossed around about cygwin (which I did try to get to work, but not very hard :P) and micro Linux kernels that you can run in the background to use these features.
Anyway, if anyone can give me maybe a list of options they would recommend (preferably not stick with your VM, even though I'm thinking that might be my best option) and maybe some tips, pros, cons, maybe a setup guide, or really any non-empty subset of these options I would really appreciate it. Also, before you ask, we have to use C and the above mentioned programming features in our assignments, so there's no switch to Java or code in win32 option unfortunately :(
Thanks in advance to anyone who can lend some words of wisdom :)
The basic principles are all there in Windows but done differently. And I recommend that, if you're going to program for Windows, you do this in the Windows API rather than through an emulation layer like Cygwin. If anything at all you'll quickly learn that different operating systems take a different approach to signalling and process handling.
First thing to be aware of is that threads are much more lightweight in Windows while processes are significantly more heavyweight. With that in mind Windows programs operate most efficiently when using threads. There is the concept of the CriticalSection that you should become very familiar with. And the Semaphore Object. Keep reading the API and you'll find a wealth of information about these topics - the Microsoft documentation is actually rather good. A key thing to understand about the Windows API is that you almost always have to "create/get" a new object (and obtain a handle) before you can use it. And Windows doesn't like programs having too many handles.
Personally I like the POSIX API and have a love for Linux. But I do appreciate that if you want to do things properly in Windows you should be using the Windows OS API - they have thought about this carefully even though the results and methods may be somewhat different.
PS Windows doesn't have the "alarm". It is perhaps the single most prohibitive barrier to simply porting Unix/Linux utilities to Windows. (That and the fact that Windows processes have to "bootstrap" Internet/socket support before using it whereas Linux processes are good to go).
There's MinGW-w64 - a Windows port of the GNU toolchain - and Pthreads-win32, a POSIX wrapper of the Windows threading API.
I'm using these via the mingw64-x86_64 Cygwin cross-compiler packages (which currently provide the somewhat dated gcc 4.5.3) instead of directly for two reasons: First, I need other stuff from the GNU toolbox, and second because of the package manager.
I'm not sure to what degree Pthreads-win32 complies to POSIX, but I can confirm that LLVM and Clang both compile with this setup.
I am looking for a NIO type of library for C. I want to implement a multi threaded UDP network server that will have a lot of clients connecting to it.
Instead of attempting to code my own program to handle packets and 'connections'. I thought I would have a look if there is not already an existing library that has been tested and build for scalability and high performance.
I have found a few for Java but none for C. such as Apache Mina.
I am hoping that some one out there knows of a good one that may assist me.
Thaks
It sounds like you want something to abstract select(), poll(), or whatever the most efficient mechanism is for your platform.
Have you looked at libevent and libev? There is a nice writeup here.
First of all, C has no classes. Secondly, C provides you with everything you need to implement a scalable and high performance solution. It's more low level than java's NIO, but there are good tutorials out there in google.
And if you want a library - try boosts' asio. It is C++, but perhaps you can use it.
If you are using Linux I strongly recommend you to use the POSIX API. It gives you resources for multithreading and networking acrosss any Linux box.
GNU C library
Is there a task library for C? I'm talking about the parallel task library as it exists in C#, or Java. In other words, I need a layer of abstraction over pthread for Linux. Thanks.
Give a look at OpenMP.
In particular, you might be interested in the Task feature of OpenMP 3.0.
I suggest you, however, to try to see if your problem can be solved using other, "basic" constructs, such as parallel for, since they are simpler to use.
Probably the most widely-used parallel programming primitives aside from the Win32 ones are those provided by pthreads.
They are quite low-level but include everything you need to write an efficient blocking queue and so create a thread pool of workers that carry out a queue of asynchronous tasks.
There is also a Win32 implementation so you can use the same codebase on Windows as well as POSIX systems.
Many concepts in TPL (Task, Work-Stealing Scheduler,...) are inspired by a very successful project named Cilk at MIT. Their advanced framework (Cilk Plus) was acquired by Intel and integrated to Intel Parallel Building Block. You still can use Cilk as an open source project without some advanced features. The good news is Intel is releasing Cilk Plus as open source in GCC.
You should try out Cilk as it adds another layer of abstraction to C, which makes it easy to express parallel algorithms but it is close enough to C to ensure good performance.
I've been meaning to checking out libdispatch. Yeah it's built for OS X and blocks, but they have function interfaces as well. Haven't really had time to look at it yet though so not sure if it fills all your needs.
There is an academia project called Wool that implements work stealing scheduler in C (with significant help of C preprocessor AFAIK). Might be worth looking at, though it does not seem actively developed.
I've run into an issue with writing some code in c. My basic problem is that I am pressed for time and the code I am dealing with has lots of bugs which I have to "erradicate" before tomorrow evening.
The bigger part of the problem is that there is no adequate IDE that can do real time debugging, especially when using threads or spawning processes with fork(). I tried Mono, Eclipse, and finally NetBeans, and have concluded that those are very good but not for coding in C. More over the learning curve to utilize the command line debugger properly is quite steep. (Like I mentioned earlier... I am pressed on time.)
So, since I am a C# developer by profession I was wondering whether I can pull this off in VS2003/VS2005/VS2008/VS2010. If I abstain from using system calls, can I do this?
Of particular interest are FILE* descriptor and fread(), fclose(), fseek() methods. I know they are part of the standard C library, however are they tied to the platform itself? Are the headers the same in Linux vs Windows? What about fork() or shared memory?
Maybe if I use VS2010 to build parts of the component at a time (by mocking inputs and stuff), debug those, and then migrate the working code in the overall Linux project would prove most useful?
Any input would be greatly appreciated.
The bigger part of the problem is that there is no adequate IDE that can do real time debugging, especially when using threads or spawning processes with fork().
The Eclipse CDT would probably have the best overall support for C/C++ development and integrated debugging.
Note that multithreaded and multiprocess debugging can be difficult at the best of times. Investing in a good logging framework would be advisable at this point, and probably more useful than relying on a debugger. There are many to choose from - have a look at Log4C++ and so on. Even printf in a pinch can be invaluable.
So, since I am a C# developer by profession I was wondering whether I can pull this off in VS2003/VS2005/VS2008/VS2010. If I abstain from using system calls, can I do this?
If you take care to only use portable calls and not Win32-specific APIs, you should be ok. Also, there are many libraries (for C++ libraries such as Boost++ that provide a rich set of functionality which work the same on Windows, Linux and others.
Of particular interest are FILE* descriptor and fread(), fclose(), fseek() methods. I know they are part of the standard C library, however are they tied to the platform itself? Are the headers the same in Linux vs Windows? What about fork() or shared memory?
Yes, the file I/O functions you mention are in <stdio.h> and part of the portable standard C library. They work essentially the same on both Windows and Linux, and are not tied to a particular platform.
However, fork() and the shared memory functions shmget() are POSIX functions, available on *nix platforms but not natively on Windows. The Cygwin project provides implementations of these functions in a library for ease of porting.
If you are using C++, Boost++ will give you portable versions of all these system-level calls.
Maybe if I use VS2010 to build parts of the component at a time (by mocking inputs and stuff), debug those, and then migrate the working code in the overall Linux project would prove most useful?
You could certainly do that. Just be mindful that Visual Studio has a tendency to lead you down the Win32 path, and you must be vigilant to not start using non-portable functions. Fortunately the library reference on MSDN gives you the compatibility information. In general, using standard C or POSIX calls will be portable. In my experience, it is actually easier to write on *nix and port to Windows, but YMMV.
Looks like I am the first to recommend Emacs here. Here is how Emacs works. When you install it, it is simply a text editor with a lot of extensions(debugger and C font-locking are included by default). As you start using it and install the extensions you miss, it becomes more than just an editor. It grows to become an IDE very soon and easily, then on to something that can eschew the OS under one frame.
Emacs might take long to learn, in the mean time, you could use Visual Slick Edit if you are not pressed on the cost part. I have used it on both platforms and seen it work good with version control, tags, etc.
Perhaps Code::Blocks? I love it and while it says it's for C++ it is, of course, very good for plain C as well.
I'm working on a project that's supposed to work on both Windows and Linux (with an unofficial Mac port as well) that emulates a true colour system console.
My problem is that recently there appeared a request for textfield support (yes, console-based) and it would be cool to add the possibility of copying text to clipboard and pasting from it. Is there a way of achieving this that will:
be done in C (not C++),
work in both Windows and in Linux (preprocessor macros are an option if there's no platform-independent code),
require no extra libraries to link to?
Thanks in advance for your help.
If you're not using a cross platform UI library (like wx or something), then it sounds like you're just going to have to write native clipboard code for each platform you want to support.
Remember, on Macintoshes, you copy with Command-C, not Ctrl+C :)
The clipboard is inherently an operating system defined concept. The C language itself has no knowledge of what a clipboard is or how to operate on it. You must either interface directly with the OS, or use a portability library that does this on your behalf. There is no way around this.
Personally I would define my your own function
getClipboardText();
That is defined in two different header files (linux_clipboard.h, windows_clipboard.h, etc) and then do pre-proccessor stuff to load the appropriate one accordingly. I don't really code in C/C++ so I'm sorry if that didn't make any sense or is bad practice but that's how I'd go about doing this.
#if WIN32
#include windows_clipboard.h
#endif
That sort of thing
Remember:
For linux you have to deal with different window managers (Gnome, KDE) all with different ways of managing the clipboard. Keep this in mind when designing your app.
You may be able to communicate to the clipboard by using xclip. You can use this python script here to do this job via communicating with 'dcop' and 'klipper' here. That is for KDE, I do not know how it would be done under GNOME... You may also be able to do this independantly of either GNOME/KDE by using DBUS, although I cannot say 100% confidently on that either...
Just be aware, that for a truly cross-platform job, you have to take into account of the different GUI's such as under Linux, X is the main window manager interface and either GNOME/KDE sits on top of it..I am not singling out other GUI's such as FluxBox, WindowMaker to name but a few, and that there will be a lot of platform dependant code, and also in conjunction, you will be dealing with Windows clipboard as well..all in all, a big integrated code...
Have you not considered looking at the raw X programming API for clipboard support? Maybe that might be better as I would imagine, GNOME/KDE etc are using the X's API to do the clipboard work...if that is confirmed, then the work would be cut out and be independant of the major GUI interfaces...(I hope that would be the case as it would make life easier for your project!)
Perhaps using compile-time switches, for each platform...WIN, KDE, GNOME, MAC or use the one that is already pre-defined..
Hope this helps,
Best regards,
Tom.