I have a question about cygwin for writing cross-platform applications. I've heard people mention cygwin for years, but I am 100% ignorant of cygwin myself, other than a skim through wikipedia which leaves me confused.

First, my situation so you understand what I'm trying to accomplish and my situation. I've been writing a fairly large cross-platform 3D game/graphics/simulation engine for quite some time now on 64-bit ubuntu linux and 64-bit windoze xp. I just forced myself (kicking and screaming) to switch to WindozeSeven because the winxp64 doesn't save SIMD/AVX registers on context switches, which means my very cool, blazing fast 64-bit assembly routines won't run on winxp64.

Up until now my IDE on linux has been codeblocks, and my IDE on windoze has been VS2005pro. I'm beginning to think that was a massively stupid choice.

I'm sure I'll need to keep a fair quantity of #ifdef LINUX and #ifdef WINDOZE in my code. For example, where I call win32 API functions to create and manage windows and WGL functions to create and manage graphics contexts, I call xlib API functions and GLX functions on linux. This will not change.

However, lately I've been fighting with certain aspects of the application that deal with text. After struggling with various text issues for quite some time, I've decided my only hope is to change all my character/text code to UTF-8. Currently it is a mix of UTF-32 characters on linux and UTF-16 characters on windoze, and not only do I need an absurd number of #ifdefs, but certain problems just can't be solved in any reasonable way --- period.

This and a few other issues makes me wonder whether adopting cygwin is a viable solution for me. Frankly, I'm not even certain I understand cygwin correctly. Sometimes it seems it is just a bunch of [command-line] applications that accept linux syntax and do what a linux user would expected.

But I get the impression that a cygwin installation includes one or more DLLs that contain linux-style "C standard library" functions that my applications could call.

Is this correct? Does this mean my applications could call standard functions like printf(), sprintf(), snprintf(), fopen(), fseek() functions (and so forth) that accept UTF-8 strings? Or UTF-32 strings?

This alone would make it work me pawing through my whole program and ripping out a whole slew of offensive windoze atrocities.

Do I understand this correct? Please explain what functionality I should expect to find, and what functionality I will not find, or is problematic for some reason. I know I won't be calling xlib functions on windoze, even if cygwin makes them available, because that low-level stuff needs to be absolutely as efficient as possible on both systems (besides, it is already written and works fine).

In case it matters, my application adopts the following support libraries:

X11/xlib - linux
OpenGL - both
WGL - windoze
GLX - linux
cairo - both
pango - both
freetype - both
fmodex - both
C standard libraries - both

My code is C (actually, C++ without classes, templates, overloading and other complex goober).

I welcome insights, comments and experiences from anyone who has written large cross-platform applications with [and without] cygwin. What was the best and worst part of adopting cygwin on windoze for cross-platform applications?

Have you thought of using wxWidgets ?

The Cygwin DLL provides most of the functions that you'd find in libc so, yes, you can use printf, fseek, etc.

Support for other stuff, like pango and freetype varies. One show stopper might be that you'll need to start an X server, like on Linux, if you want to perform graphics.

The web site is cygwin.com . You can ask questions in the Cygwin mailing list as discussed at cygwin.com/lists.html .

I would NOT use Cygwin to port programs to MS Windows

cygwin RUNS LINUX programs ON windows ( well about 70% of them)


MinGW

MinGW however BUILDS MS Windows ".exe" and *.dll" files FROM linux code
and is not hampered by RUNNING EVERYTHING and i do MEAN everything thought the ONE cygwin.dll
that is very often VERY slow

Cygwin is slower than native Windows or Linux because it has to emulate a lot of things that Linux does, most notably fork and exec. It doesn't run Linux programs. You have to rebuild them.

Every Windows program uses DLLs. MinGW is no different.

MinGW won't give you much over a native Windows program. Native Windows will allow you to use some basic stuff like fopen, fprintf, fopen. It won't give you fork, execvp, or Linux-like signals. You'd still need #ifdef WINDOWS in the Code. Cygwin, OTOH, strives to be compatible so that if it compiles on Linux, it has a 80-90% chance of compiling using Cygwin's gcc.

I am, btw, one of the Cygwin maintainers.

My application is a 3D game/graphics/simulation engine, and so far the display is driven entirely by OpenGL code (with assist from cairo, pango, freetype, etc).

When I get to the point of adding a GUI, I will consider wxWidgets as well as wxWindows as well as GTK+, and perhaps others. And I will consider whether I want a conventional GUI at all (in my main graphics window at least), and what complexities arise from trying to have my high-performance 3D graphics application try to share the same window with any other application (like a GUI library).

I also must admit a strong personal preference for C over C++, so efficient GUI libraries with native C interfaces get several bonus points from me right out of the gate. As far as I know, only GTK+ is a native C library. Of course, when the time comes, I'll consider other strengths and weaknesses too.

Also understand that BY FAR the biggest hassle I have now for programming to run on both linux and windoze is dealing with %^$~&*!!!(^^&^$%^ unicode characters and strings! On linux they are UTF-32, which is GREAT, and fine with me, especially since each 32-bit value represents a specific character with no multi-value characters or other BS. However, the morons at macroshaft made unicode characters on windoze 16-bits. This is both a HORRIFICLY bad choice (the worst of ALL possible worlds), but means there is exactly ZERO compatibility between linux and windoze in the realm of characters and strings (unless you stick to the 127-characters of ASCII). You cannot imagine the mess and hassle this causes in expected and unexpected places unless you try it yourself!

Thanks for the information. That sounds great. And from what you've said, I infer that I can choose either UTF8 or UTF32 throughout my program, and it will run on both linux and windoze. That's FANTASTIC, because currently linux supports UTF8 and UTF32 (the only two rational encodings), but macroshaft supports neither of these... leaving me with zero compatible forms that encode all unicode characters --- if it wasn't for cygwin that is!

I have no need to "start an X server" on windoze, unless I misunderstand something. My application already runs on both linux and windoze, and it creates windows on linux with X11/xlib functions and it creates windows on windoze with the normal win32 API. Furthermore, my application already creates OpenGL graphics contexts with GLX on linux, and with WGL on windoze.

From there on, everything is just OpenGL, which is the same code on both.

All my 2D graphics and text are drawn by cairo, pango, freetype. I purposely chose to ONLY have these libraries draw into "memory contexts", which means, "directly into RAM". Therefore, so far at least, I am happily calling cairo/pango/freetype functions on both platforms without troubles. I assume I would have trouble if I tried to make those libraries render into other contexts, but happily for me, rendering into a memory context is the fastest operation AND the only form of 2D graphics/text rendering I need. The memory these libraries render into is precisely compatible with my textures, so those functions are, in fact, rendering 2D graphics and text directly onto textures in my CPU memory. This is so incredibly convenient and efficient for my application, I'm very happy with these packages on both linux and windoze.

Okay, I guess I need to understand this better.

Does mingw ALSO include a DLL (or static library) that contains linux versions of C standard library functions? If so, are you sure mingw doesn't just include cygwin with it?

I know the codeblocks IDE that I develop with on linux pretty much assumes mingw, though it also supports expensive compilers like the intel compiler set. However, I'm not entirely clear what mingw provides (other than gcc [or a port, or an equivalent]).

Let's get back to the cygwin solution, and help me understand this. Am I wrong to say that there are two ways I can take advantage of cygwin:

#1: Write a pure linux application, install cygwin on my windoze machine, then run my pure linux application on [cygwin on] windoze. In this case, whenever I call an XWindows/xlib/GLX function, stubs in cygwin get called instead, and it "emulates" that functionality party by calling win32/WGL functions, and partly by itself.

#2: Write a cross-platform application that contains:

#ifdef LINUX
- and -
#ifdef WINDOZE

sections within it. Inside the LINUX sections call X11/xlib/GLX functions, and inside the WINDOZE sections call win32/WGL functions, and elsewhere call OpenGL functions (same functions on both platforms).

In case #2, where there are character and string functions to call, the application could call cygwin functions that uniformly accept UTF8 characters-and-strings, or UTF32 characters-and-strings.

----------

Now, are you saying #1 is slow, but #2 is fast?

Or you are saying #1 and #2 are slow?

PS: I have no intention whatsoever of trying #1, because my application inherently needs to be as balls-to-the-wall fast as possible on both platforms.

----------

One last question.

One huge annoyance I have is keeping 4 separate versions of an assembly language file for:

32-bit linux
64-bit linux
32-bit windoze
64-bit windoze

The reason is, 32-bit and 64-bit opcodes are DIFFERENT, and also they have different numbers of regular and SIMD registers they can access. Therefore I have no choice but write and keep in-sync separate 32-bit and 64-bit files.

However, right now I also need to keep separate linux/GAS/ATT syntax versions and MASM versions of each file, since up-to-now I build my windoze versions with VS2005pro.

So the question is this. If I switch to cygwin (or mingw), can I throw away my MASM files and compile the linux files on and for both platforms? That would be sooooo sweet!!!

Okay, great! Maybe you understand this issue better than most. Do you understand my situation?

#1: I have no interest in running a pure linux application on windoze, whether I have to recompile or not. This is true because I must achieve maximum efficiency for 3D rendering. For side-issues like opening and closing files, date, time, and so forth, efficiency doesn't much matter, PLUS I already wrote my own efficient platform-independent libraries that contains #ifdefs to call native linux or win32.

#2: However, characters and strings are driving me totally insane, for reasons I explain in my other posts of today (please read them to understand my problem). This relates to printf(), wprintf() sprintf(), snprintf(), snwprintf() and related functions because linux accepts the only rational character/string types (UTF8 and UTF32), and windoze supports NO rational character/string types (either ASCII which lacks most characters, or UTF16 which requires two UTF16 values to represent some characters).

So, for me at least, the main requirement is to let my application call the linux version of all standard character/string functions. I'm inclined to standardize on UTF8, but I'd be happy to standardize on UTF32 too.

What I can't make work conveniently is UTF8 or UTF32 on linux and UTF16 on windoze. That just royally and totally sucks. Not only do I have infinite #ifdefs, but other problems and complexities occur too.

----------

So, given all the above, tell me all I need to know about mingw and cygwin from the context of what I need --- a set of functions that let me write my application with a single type of character/string... especially if that type is UTF8 or UTF32.

Yes, and gcc also lets you access SIMD functions from C code, see Using vector instructions through built-in functions.

MinGW would not help with this. I suggest writing wrapper functions like printUTF8 (or UTF32 if that's an easier encoding to work with) that would convert to UTF16 on Windows, using libiconv.

The Cygwin FAQ says it uses UTF-8 by default, so maybe that would be less work for you.

MinGW provides a distribution of gcc running on Windows in order to compile C code (not "linux code") into native Windows programs (so obviously gives you nothing "over" a native Windows program). It uses the Windows C library, msvcrt.dll.

Sounds like calling functions in the cygwin DLL is what I need. Really, when I look at my situation, I have a working application... BUT... a huge unworkable mess with characters and strings, because I'm dealing with UTF8 and UTF32 on linux, and UTF16 on windoze.

If cygwin lets me work with UTF8 or UTF32 on both linux and windoze, I'm a happy camper.

I think my big mistake was my decision to develop this cross-platform application on linux with codeblocks and windoze with vs2005pro. If I had looked harder, I probably would have adopted codeblocks for both and been led to cygwin.

Oh bummer! I thought cygwin was going to be my solution, to provide consistent character and string functions for the 32-bit and 64-bit version of my application.

But it appears cygwin only works with 32-bit applications. Waaaaaaaa.

Does anyone know of any function libraries that contain consistent character and string functions for both 32-bit and 64-bit linux and windoze. Even simple functions like printf(), sprintf(), snprintf(), etc? It would be nice if it also contained functions like fopen() and such too, for non-english filenames and such.

wxWidgets, IIRC, can do this.

Maybe boost could abstract those string problems away with its string algorithms?
Qt has its own string types too, but I think it'd an overkill to use it just for some consistent text processing...
Maybe you're better using an already platform-independent string library, such as The Better String Library (first result obtained via Google ) to remove ugly platform specific tweaks inside your code.

First thing I noticed about TheBetterStringLibrary is... no support for internationalization at all. In other words, the main reason I need something (a compatible unicode encoding on both platforms) is the one thing it doesn't have.

Maybe what I need are two functions (taken from "somewhere"), one to convert UTF8 to UTF16 for windoze, and one to convert UTF8 to UTF32 for linux (though that's probably not necessary since linux can tolerate UTF8 pretty much everywhere, I suspect).