I need to write some C functions that will be called by a java program running on a CenOS Linux server, as part of a web application. The server is a hosted dedicated server sitting in another physical location, far away from me.
Do I need to develop the C stuff on the server directly, that is, doing development tunneling into the server? Or can I develop the C program on a Mac or Windows PC in my office, then once everything is working fine, store the final results on the server for use? If the latter, does it limit the choices for development environment in any way? That is, which compiler I should use, or any settings in the IDE or compiler I need to worry about since the development environment will be different than the production environment?
If I use Xcode version 3 on a Mac, it uses GCC by default, whereas Xcode version 4 uses LLVM-GCC to compile. Does the choice of compiler matter assuming I'm using C99 standard things? I don't want the code to be dependent on the development environment since I can't guarantee it'll stay the same in the future. Can I switch the compiler manually in Xcode somehow to verify the code works in GCC as well as LLVM?
Ignoring windows, things are pretty portable across mac/linux. If you develop it on mac in whatever development environment you want (I personally use TextWrangler and GCC from the command line.
Once you develop your software, it's a simple matter of copying the file to your remote server and compiling it there.
You may or may not need to change a few things. The only portability issue I've run into was mac's socket() using PF_ instead of AF_ (Mac will still accept AF_ but it doesn't advertise it in it's manpage, and other systems will not necessarily accept PF_) and sranddev() not being available on some systems; both of which were very easily resolvable.
If, however, you wanted to write the software directly on the remote box, its definitely not a hard thing to do, I would just ssh there and take your pick of text editors (usually vi or emacs) and compilers (usually gcc).
In general, for programs that are just traditional unix command line things, I tend to avoid Xcode as much as possible because it likes to hide things, and IMO its a good thing to actually understand what is going on behind the scenes. (Especially if you use other *nix systems.)
Whatever you do, it will need to be recompiled on the server.
You can probably create code that's runnable/testable under both environments, although you may have to #ifdef around compatibility issues. How much of that, if any, depends a lot on what you're actually writing.
Does the choice of compiler matter assuming I'm using C99 standard things?
Yes: Microsoft, AFAIK, still doesn't fully support C99 (but maybe that's changed in the latest MSVC). Also, you have to resist the temptation of using non-standard features just because they are there. OTOH, a local build env might force you to write portable programs.
The choice depends on how your program is going to communicate with the larger system, but developing at least parts locally is probably the most convenient option.
Related
I have a working module on linux and one of the client wants it on windows.
There is very good discussion on similar topic here(https://ask.slashdot.org/story/04/08/12/1932246/cygwin-in-a-production-environment), I guess it leaning towards avoiding cygwin for productions but its about 13 years older discussion,there might have been issues but in about 13 years I hope cygwin might have been improved,matured and good for production use.
The code compiled just fine and seems to work ok under cygwin so its very tempting to take it forward rather than redoing it in windows native code.
But if there are really any unsolvable known issues and people are avoiding it for productions I would like to know.
The code heavily uses pthreads,sockets in no-wait
I've used Cygwin a fair bit, and have found it mostly unproblematic. I am aware of some of the reported problems, but haven't experienced them myself. Some things on Cygwin are much slower than the same code on Linux -- I notice this most with directory scans, but that probably isn't the only thing. People complain about fork() being slow, but that isn't really a surprise, as 'forking' isn't a native concept in Windows. If you're just using fork() to launch subprocesses, then conceivably the whole fork/exec thing could selectively be replaced with calls to native Windows APIs.
A potential limitation of Cygwin is that it requires Cygwin at run-time or, at least, a chunk of Cygwin infrastructure. MinGW might remove this restriction, but at the cost of leaving you to make a larger number of compatibility-related changes in your code (file locations, for example). The last time I looked, MinGW didn't have tooling as extensive as Cygwin, either, but it's probably good enough for many purposes.
I guess another possibility to consider these days is the Windows Subsystem for Linux (WSL) on Windows 10. I've found that code that builds for Cygwin usually builds and runs without changes on WSL, but I haven't really figured out what the relative advantages and disadvantages of Cygwin and WSL are.
I've not noticed problems with pthreads in Cygwin, MinGW, or WSL; although I guess any problems are likely to depend on the exact way you use threads. I can't comment on the no-wait socket issue, because that isn't something I've tried.
Incidentally, both Cygwin and MinGW will allow you to call native Windows API, and other functions in DLLs, if you need to. So the possibility exists to create a sort of "hybrid" application that uses POSIX-type functions and also Win32 APIs. This might be useful if it turns out that some things are much faster with Win32 functionality. I'm not sure this is possible with WSL.
I should say that my comment about time consuming updates refers as much to the need to perform a full Windows update as well as apt-get updates prior to running a wsl
script which will go past midnight. Running a separate memory recovery script every 4 hours or so is a partial solution. I have "only " 6GB RAM.
A CS course I'm taking online suggests students compile their source code and run tools like valgrind on the OS UNIX. I'm completely new to UNIX, Linux, their tools, and coding in c. I've made some attempts at installing FreeBSD 8.1 on VMWare Player 3.1.3, and even managed to get VMWare Tools running. But the FreeBSD documentation has led me down many dead-ends in accomplishing common tasks i.e. mounting an NFS or USB device. It turns out that the packages I need to make this happen aren't installed or configured, and I don't see any straight answer on how to install them.
So, if I'm using UNIX only as a tool to run gcc, g++, valgrind for this CS course, and these can be run on Linux instead, it seems like I can get the job done faster using Ubuntu Linux.
Can Linux be used to compile and run c code identically on UNIX, if compiled on Linux? Or if not, what are the differences to look for?
Thanks
For the novice-level C programmer such as OP, the difference of environment is negligible. Go ahead with Linux.
I think for purposes of the course you could run your programs and tools on Linux,
but I guess the reason your teacher wants you to use FreeBSD is so that you learn other things besides just coding up your problems
The two should be effectively the same. The only major difference you might see would be due to different versions being used. I would check to see what versions of gcc, g++ and valgrind the teacher is having you use, and make sure that you have the same version running on your install of Linux.
You can also use MinGW or Cygwin. You mentioned VMWare, so I'm guessing you're trying to just get an environment up and running in a windows environment. They both allow you to use the compiler and some of the tools without a full install of a Linux based system. In a CS course they would be more than enough.
The main differences too look for:
Compiling C / C++ is not machine independent. You need to have a small environment to compile on UNIX anyway if you need to submit compiled programs to your professor.
C / C++ is rather portable if you don't use anything that's non-portable. It's very hard to verify that you didn't use something that's different between the two machines, so you may wish to compile on UNIX to verify you didn't let an unavailable library (or an specific to the OS procedure, argument, behavior, bugs, etc.) slip into your code.
The vendor of make between the two machines may differ. This means that while the core of make will operate similarly, certain features might not be available in both. In reality, you probably won't use most of makes extended features, but in a worst case scenario you might opt to maintain multiple Makefiles or limit yourself to a common subset of features.
At the end of the day, it all boils down to what your professor will want. Odds are 95+% that you can do 100% of the work in Linux, but the prof's requirements or grading environment might be such that you will have to copy your code into a UNIX account to build the final "submission" executable. Considering that university UNIX accounts aren't nearly as portable as Linux on a laptop, the cost of the "final verification / porting" to the University computer is likely to be small compared to the convenience of working on your homework more hours than you can manage in a fixed lab.
So, I have a large C project that was built entirely on Unix (SPARC Solaris). me and several others have begun to revisit it because their was some interest in a windows build.
none of us have done this with a project of such size, so for starters, has anyone ported something from unix to windows and could maybe give me some pointers or how they did it.
our first step on our plan was to decide on a compiler/dev environment.
it seems that our options are MS Visual Studio, Cygwin, mingw/gcc, and Windows Services for UNIX (SFU).
we are on a fairly short timetable so we want to rewrite as little code as possible.
so, Deciding on a compiler.
Another issue is that the code does use POSIX thread commands (pthread, etc)
we would prefer to compile natively, not using some sort of layer between the executable and the OS. unfortunatly with the pthread calls in our code, this may not be possible.
I believe both Cygwin and SFU do just that. Cygwin has a .dll that must be included in compiled code to work. I am not sure about SFU, any information about that would be greatly appreciated. It seems like it would be a good option but was developed to allow for UNIX compiled software to run on a windows machine with SFU, not any old windows box.
mingw does have the ability to create native exes, but lacks the POSIX support.
So, can anyone give me any more information, suggestions, knowledge on any of these compilers in this context. or any experience they have with this sort of thing, it is greatly appreciated.
Short timetable? CygWin, plain and simple.
Despite your preference to not use a layer, that's going to provide the fastest path and you don't seem to indicate that the timeframe requirement is flexible.
We've ported both command-line and X-based UNIX programs to Windows using CygWin with minimal hassle.
Cygwin is likely the fastest path to a working executable. However it will leave you with some interesting distribution choices. Most obviously, cygwin.dll becomes a dependency. Its licensed GPL, unless you pay money to buy commercial use rights.
Cygwin is not particularly friendly to an ordinary Windows user. Its goal is to provide a full POSIX experience on Windows, supplying a shell, all the familiar *nix utilities, and even a port of X. However, it also remaps the Windows disk drive naming into a POSIX-like file system. I've never attempted to distribute an application built for Cygwin to machines that don't already have a full Cygwin installation. I will note that to my knowledge none of the big well-known open-source applications with Windows ports are based on Cygwin.
If the only hard POSIX dependency you have is pthreads, then that is solvable. There is a pthreads port built on native Windows threads that works well with MinGW. IIRC, it is even distributed along with MinGW, or at least is one of their core supported packages.
If the rest of your handling of file names is largely as opaque strings, you may not even need to care about changing / to \. The Windows API is generally happy to treat either character as a path separator, even mixed in the same name. It is the CMD.EXE and early DOS convention of using / for command line options that prevents the use of / for pathnames at the command prompt, not the underlying Windows API.
For tools that might make porting your build process easier, check out the MSYS component of MinGW. It provides a lightweigh fork from the Cygwin environment in which enough *nix utilities are available to generally run ./configure and similar processes.
In addition, the GnuWin32 project has ports of a large number of utilities and libraries that are all built to run as native Windows applications without unusual dependencies.
If the code is (at least mostly) portable and the only major issue is the use of pthreads, you might want to use the Pthreads Win32 library. While incomplete, it's sufficiently complete and accurate to deal with most pthreads code I've tried it with. While normally built as a DLL, this can also be built as a static library to avoid creating an extra dependencies in your executable.
That, of course, leaves everything else to port -- but you haven't said enough to even guess whether porting the rest within your timeframe is at all reasonable.
I'll write a program for Interactive UNIX (http://en.wikipedia.org/wiki/INTERACTIVE_UNIX). But in a year it will be ported to Windows. I'll write it in ANSI C and/or SH-script. When it runs on Windows it will be run as a Windows service. How do I make it as easy as possible for me?
I want to change as little as possible when I port it, but to make it good code.
Unfortunately, Interactive Unix is a old system and the only shell that exist is /bin/sh
If you are even considering doing this in SH script, then you should give serious consideration to Python which is already portable.
Port early and frequently
Encapsulate non portable code. (Don't spread too many #ifdefs all over your code - rather create functions implemented separately for each OS in separate source files.
Be very strict with data types (use long short in structs/classes and not int)
I.e. switch on the highest warning level and resolve all warnings.
You can use platform-dependent ifdef-include pragmas and as strict types as possible. GLib has some nice ones defined which could be used on nearly every platform or architecture.
A shell script only option is not a viable alternative as on Windows platforms, there's no Bourne shell, Bash or KSH by default, and unfortunately PowerShell seems to be rare on XP machines. But you can create both a traditional batch file and a Bourne shell script.
But as others said, it's easier if you use a higher level language that's platform independent. And why wouldn't you? :)
I would recommand using ANSI-C and Lua (an embeddable small script interpreter). Try to use this with the basic required C functions you need.
You need to port and test often. If you work one year on unix and then try to switch it will be much harder, because often the best porting solution is a different design which is implemented on all platforms.
Windows can't run sh scripts directly, you need to use cygwin for that. So if you really want to run on vanilla Windows, you better use C. Stick to C89 and be careful. If you use any system calls, stick to POSIX ones and you should find them or equivalents on Windows. Windows also has a pretty comprehensive Berkeley sockets-alike library, so you can use that too within reason.
You're still going to have to do some #ifdefing.
You'll end up compiling it with MinGW if you make it a Windows task, if you stray too far into the UNIX den, you'll have to make it a cygwin binary instead, which has some baggage associated with it.
If it is not an option to add something that is inherently portable like python, ruby, perl, java etc. then your best option is probably to use ANSI C. One reason for C's initial popularity was it's (relatively good) portability. That said, anything that is closely tied to the OS, such as graphics, networking, etc are much less portable in C than in something like Python. You should strive to make "wrappers" for OS specific functions and keep those partitioned off from the main code. This way when it comes time to port it over, you're rewriting the wrappers, and everything else should compile without many issues.
All that said, it is a LOT easier to write something in Python and have it work everywhere. Plus it is more "fun" to write. So if you can avoid "interactive unix" in the future, do so.
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.