Migrate Win32 C/C++ Applications to Linux

An anonymous reader writes "This series of articles helps you migrate your Win32 C/C++ applications to Linux on POWER. Win32 C/C++ Apps to Linux Part-1 of this series covers the Win32 APIs mapping to Linux on POWER regarding the initialization and termination, process, thread, and shared memory services. Win32 C/C++ Apps to Linux Part-2 illustrates how to map Win32 to Linux with respect to mutex application program interfaces (APIs)."

Comments

The problem with migration is...

[Jaidon]

...that sometimes during the process the stragglers fall prey to hunters.

Re:The problem with migration is...

[Anonymous Coward]

By stragglers, do you mean people attempt to use every support library in order to reduce the number of origional lines of code to the point that #includes are about all they really have to type?

Re:Stupid question

[laughingcoyote]

Nope. It relates to porting Mac applications to run under Solaris. They just called it "Win32C/C++ Applications to Linux" to see if you'd ask a stupid question.

Worked brilliantly, too!

Portable code

[OneArmedMan]

I was thinking about this today. everyone complains that there isnt *Insert Random Program HERE* available for Linux, isnt part of the problem that most code being written isnt portable? eg its too dependant on specific libraries.

I cant write code myself, so obviously there is a lot that i dont know. But is it really that hard to write code that is portable?

Thoughts , Ideas?

Comments and/or Flames should be posted below this line .

---------------------

Re:Portable code

[PhrostyMcByte]

It's not really that hard if that's what you have in mind. Things like Boost can really help, if you can convince whoever your coding for that portability is a good thing.

The problem usually comes when dealing with the GUI or other slightly lower level system functions which sometimes can't be wrapped elegantly.

Re:Portable code

[adlaiff6]

Programs written in Java are relatively portable, given that they run in a runtime that has been written for multiple OSes.

Re:Portable code

[Anonymous Coward]

Portable code can be more time consuming to write, and the resulting application is sometimes less efficient than if it utilized APIs more heavily integrated into the operating system.

Re:Portable code

[mingot]

_what everyone else said_

AND in addition to generally being a bit more difficult to code (or less efficient when using a cross platform libraries/language) is that it can be a real bitch to support code running on multiple platforms.

Re:Portable code

[Lisandro]

Generally, the *code* itself it's quite easy to port (specially C/C++). The problems are the OS architecture and underlying libraries. Functions available in one can't be available in the other, or be so wildly different that rewriting them becomes quite a chore.

DirectX - OpenGL is a good example (for graphics). Both accomplish pretty much the same, have similar features and perform the same. Yet, telling OpenGL "hey, draw me a few polygons here" can be completely different than telling DX the same. Now, OpenGL is supported in Linux, so if your Windows program uses it, converting it to Linux becomes more or less inmerdiate (you'll still have to retouch here and there, but not much). Not the other way arround - converting DX to OGL might be doable, but doing it consistently all over big programs it's an awful chore.

This also happens in quite a few other areas, not all related to the so called "multimedia". For example, widgets (the windows and buttons drawn on screen) might be handled completely the same. Libraries allowing you to do similar things on both OSs can be completely different to implement. Audio, file management, program intercomunication, etc.

The way to deal with this is thinking ahead. It's actually not hard to write portable code - the problem is porting code which wasn't designed for it.

Re:Portable code

[ottothecow]

In my little experiance, I can tell you that the portability of code has much to do with its complexity and what it works with (and the level of the language).

If to systems have very similar network protocols (as most do), it becomes trivial to write a cross platform app that mostly deals with the net in a higher level language. But when you try to optimize it more and more or start linking it to more unique parts of a system (cocoa for instance), the process becomes exponentially more difficult.

Repeating libraries across systems helps this as show by wine, but then the software is nolonger running native to the system, it thinks that it is still running on a windows box.

Re:Portable code

[mboverload]

That's what alot of FreeBSD people complain about. Programs for Linux are supposed to be so portable, but many times they are just as dependent as their Windows brethren.

Re:Portable code

[Lisandro]

...for example, widgets (the windows and buttons drawn on screen) might be handled completely the same.

Sorry, make that "completely different". I need my caffeine dose.

Re:Portable code

[AmberBlackCat]

I don't think portability is such a big problem for somebody who has time and resources. I think the biggest problem is people who make software for money are concerned that Linux users want everything to be available for free. And on top of that, a lot of them want it to be open source. So anybody who makes software for a living is going to feel like Linux is a hostile or unprofitable market to enter, unless they're making corporate software.

Re:Portable code

[Anonymous Coward]

Sometimes you just dont realize that the code is not portable until you try to port it...

I code with unix in mind. So my programs work on mac, linux and aix with just a recompile. Never got it to work on windows... that os is just so strange.

Re:Portable code

[chesapeake]

But is it really that hard to write code that is portable?

Well, that's an interesting question. My current work is probably pure evil in the eyes of most slashdotters - I'm currently porting a compiler/interpreter/virtual machine of a special variant of prolog from unix->win32 native code.

While writing c/c++ that's portable seems relatively straight-forward, there's lot of gotchas. Different compilers support standards differently, and GCC is one of the worse in some ways - it supports many, many extensions to the standards - what we'd normally bash Microsoft for 'embracing-and-extending'. As a consequence, code that heavily relies on these features can be somewhat involved to port to another compiler/OS. For example, GCC supports zero length arrays, which are currently causing headaches for me as I attempt to fix a garbage collector. :-/

Also, should you wish to interact with the operating system (ie: write any program more complex than hello_world.c), there is no choice - you must use the relevant api. If you look at the article, you'll see tables, with things like GetCurrentProcess() mapping to getpid() under unix. You don't have a choice which one to use under what OS unless you write a compatibility layer of your own.

And that's the whole thing really - code has to be dependant upon specific libraries if you value your time and/or don't want to reinvent the wheel. Thankfully, it appears that cross-platform libraries are starting to become a bit trendier (eg: QT, GTK, etc). Hopefully this will help here a little.

Should you choose a language like Java, however, these issues are supposed to just go away - a nice ideal... ("Write once, test everywhere", I believe ;-P )

(I would just like to add that I'd rather code C/C++ under unix with GCC any day - I'd just rather eat.)

Re:Portable code

[CodeBuster]

The problem is with code that depends upon services and libraries provided by the platform in question and which vary from platform to platform such as graphical user interface and threading code. Since many applications provide either graphical user interface or threading or both and make use of other features which may not be common across platforms it is not generally possible to separate certain important parts of the code from the target system. This means that while some parts of the code, which are not dependant upon system specific resources, may be reused there are still major portions that will have to be rewritten (i.e. ported) to new platforms. Graphical user interface code especially tends to be verbose and tedious to rewrite multiple times on different platforms. Perhaps this helps you to have a better understanding of why porting is an issue.

Re:Portable code

[Anonymous Coward]

Isn't that mainly because FreeBSD has incomplete/incompatible threading APIs?

Re:Portable code

[Anonymous Coward]

I have a similar question.

Say I would use Qt for Windows - could I write something as trivial as a little advanced text editor and port it to Linux _just_ by recompiling it? That's what their website says.

Re:Portable code

[Anonymous Coward]

No, it's not that easy. See, I've tried to get used to running Windows in User mode instead of the normal Admin, full access mode. There are a few applications that just won't run that way, you can argue they're poorly written, but that's how it is: such scenarios weren't expected by their programmers. There's no such things as natural consistency in programming, you have to be expecting the contexts you wan't to support.

Now, there are ways of doing code that is more easily portable, which is basically similar to coding your own sandbox. You can build your program on top of a layer of your own that serves as an interface with whatever API is needed. Make the internals of your actual program rely only on its own set of functions, not direct API calls.

Re:Portable code

[Anonymous Coward]

Nope, it's because people hard code paths (and other distribution dependancies), use the innards of various structs, use /proc, assume the entire world is Intel, assume various GNU options are available for build - configure - install, etc.

Re:Portable code

[bigberk]

I don't think portability is such a big problem for somebody who has time and resources. I think the biggest problem is people who make software for money are concerned that Linux users want everything to be available for free

Put me in this category. I use both Windows and Linux and would love to partially rewrite some of my best selling apps so that they run under Linux. But I'm not sure whether it's worth the effort. I will want to release the binaries (versions for a few different libc's for example) and am definitely not going to be releasing my source code. btw I'm also an open source developer but I don't intend to make money off that UNIX software.

I'll bet there are tons of other programmers in my situation. For instance, Mac OS X looks like a more attractive destination platform for diversifying my market, rather than Linux.

Re:Portable code

[bigberk]

man you have got to look at wxWidgets. It provides a uniform API under many platforms, so you can use wx's threads, wx's file I/O, wx's sockets (instead of say winsock vs BSD sockets), wx's GUI and widgets. This will seriously cut down, if not eliminate, OS-dependent stuff.

Re:Portable code

[Anonymous Coward]

Yes, but aren't those details Situation Normal in the *nix world?

Neither Linux nor FreeBSD have the right to complain about portability because neither strictly follow the Single Unix Specification.

Re:Portable code

[Anonymous Coward]

Depends on your software. If it's server or enterprise software, there's certainly a Linux market outside of the cheapskate hippies. However, if it's desktop software, make a mac port with a good UI and you might be golden (Mac users love paying for shareware).

Re:Portable code

[starfishsystems]

You can build your program on top of a layer of your own that serves as an interface with whatever API is needed.

The idea being that all of the portability issues will be confined to the interface layer. Moving to a different platform, or even tracking changes to an existing platform, should then have no effect on the majority of program code, since it lies outside of this layer.

That's the theory. In practice the effort required can vary a lot from one application to another. The easiest cases are operations which are to be expressed have fairly conventional meaning, for example getting a list of network interfaces from the system. Conversely, the most challenging cases involve fundamentally dissimilar models or capabilities, or else semantic complexity and context that has to be carried around.

The strategy for the first alternative, if you're committed to portability, is to restrict your design to a modest set of platform capabilities. That's always a good design discipline anyway, so I think you actually come out ahead if you think in terms of portability for any design project, excepting perhaps proofs of concept and other transient projects.

The second alternative is the really expensive one, since what you're really doing in the interface layer is building some kind of elaborate context management system on top of some other elaborate context management system. And I think this illustrates the point being made by the parent in saying you have to be expecting the contexts you want to support.

Re:Portable code

[Spacejock]

Me too, although my apps are written in VB6 so the likelihood of me porting them is slim.
Instead, I've made a load of internal changes to make them wine-friendly. For example, ditching all my database code which used to run on the MDAC and JET runtimes - now I use flat ascii for small stuff and records/random access databases for the larger ones.

When I started programming I had 640kb of RAM to play with, which means I automatically select disk-based access when storage needs exceed about 10kb. Nowadays who cares if you load a 100kb data file into memory when the program starts, and write it out from time to time?

Re:Portable code

[Nasarius]

Libraries allowing you to do similar things on both OSs can be completely different to implement. Audio, file management, program intercomunication, etc.

Well, that's why we need cross-platform toolkits. Qt (which is much more than just a GUI library) will be available in GPL form on Windows soon, making it a good choice for open-source programs.

Re:Portable code

[Afrosheen]

For more on this, see the crappy performance of any Adobe app in MacOSX. They refuse to conform to the new standards (coconut or whatever the hell they're calling it) and end up with slow slow apps.

Funny how Adobe made all their money from Apple to begin with and NT was once a hobbled stepchild to them. Now Apple's the stepchild. Oh how things have changed.

Re:Portable code

[Nasarius]

wx's sockets (instead of say winsock vs BSD sockets)

Kind of a bad example. If you don't use the Winsock functions (WSA*, except for WSAStartup), your sockets code should be easily portable between Windows and Unix.

Re:Portable code

[secretsquirel]

Wasn't portability the whole point of java in the first place?

Re:Portable code

[secretsquirel]

Someone PLEASE mod parent up.

Re:Portable code

[unknown_host]

Just to clarify, DX isn't supported in Linux and OGL isn't really supported completely on Windows. Porting normal OGL/DX functions is not much of a problem, but as soon as you get in the domain of extensions and functions using vertex/fragment shaders, it is really painful. In fact, DX support for stuff like fragment shaders, rendering to textures, etc is much better than OGL. Being a Linux/OGL user, it is almost a pain to use OGL if you're say writing some messy shader. Darn you game developers for using Windows..

Re:Portable code

[Anonymous Coward]

GCC supports zero length arrays, which are currently causing headaches for me

Good thing, though. It's common in some places to write code like

int a[0];

a = malloc(sizeof(int)*2);
a[0] = 100;
a[1] = 200;

rather than saying

int *a; /* will use as a[n] later */

I used to work at Microsoft, and all dynamically-allocated arrays were declared as zero-length arrays rather than simple pointers. Always. (Well, that was C code; not sure what the C++ guys did.)

Re:Portable code

[mboverload]

The problem is, the whole reason the OS is there is to support programs. Sure, you COULD have the work processor have its own kernel and other funtions, but the developer leaves that ot the OS. It is the purpose of the OS to make it easier on the developer by including shortcut and other goodies. However, in this day and age of "multi-platform" support developers are being pushed away from that crutch (not that it's a bad thing).

Making a program mutli-platform is like using peanut butter instead of sticky notes. Sure you CAN do it, but taking the shortcut (using OS APIs and other thing) is how an OS is supposed to work.

Re:Portable code

[mboverload]

??? I thought that Photoshop was way more efficient/faster on OSX than on a Windows. I guess thats just Apple marketing crap then?

Re:Portable code

[Anonymous Coward]

Somewhat normal, but especially common in Linux and older Solaris programs. Linux is a "first unix" for a lot of amateurs and there are lots of programs where it shows.

Re:Portable code

[KiloByte]

I'm working on something that's supposed to be über-portable -- as the very minimum, I want Win32 and everything that can be called Unix.

Yet, I rely on autoconf, which, even though extremely portable among unices, depends on some type of a shell... uh oh. Show me a shell on Windows :p

So, I'm ending up with something "portable" that requires GNU tools to even build for win32 -- either CygWin or cross-compiling. I even use gcc-specific flags for the win32 binary ("-Xlinker --subsystem -Xlinker windows" to avoid spawning the console window).

What way would you suggest to have both Un*x and win32 native support from the same source tree in a clean way?

Re:Portable code

[BarryNorton]

Portability between washing machine controllers...

Re:Portable code

[Anonymous Coward]

autoconf isn't bad as long as it is clearly stated as a dependancy. I was thinking more of the sometimes minor obnoxious differences in output and the command line args of the varying versions of sed, awk, grep, tar, etc.

and additionaly OT, but why the hell does slashcode allow the "named" entities (ü and the like), but not the "number" entities (amp pound 252 ;)?

Re:Portable code

[Anonymous Coward]

MSYS is what you are looking for.

Re:Portable code

[Yokaze]

Well, since

int a[N];

is an array of fixed length N, I'd acutally expect the compiler to issue a warning on the following lines.

a[0] = 100;
a[1] = 200;

If you want dynamic sizes in C, you go through pointers. So

int *a; /* will use as a[n] later */

would be correct.

If you find the latter lacking the expressiveness, go Hungarian,

int *prgA;

but don't abuse a unportable laxity in certain compiler. The reason should be obvious from the existance of the grandparents post.

Re:Portable code

[RKBA]

"What way would you suggest to have both Un*x and win32 native support from the same source tree in a clean way?"

Use macros that expand to the API call appropriate to the OS being compiled under.

Re:Portable code

[DrXym]

To be frank, those things are trivial to fix and can be expected when moving any Unix program to some other platform. Once a program goes through a few iterations, gains an autoconf script and some maintainers, it will build and run happily on lots of platforms.

Contrast that with Win32 vs Linux where the API is different, the compiler is different, the build system is different, the underlying OS is totally different etc.

Re:Portable code

[IamTheRealMike]

You clearly don't have much idea of what porting your average Windows app involves, and if they are saying such things neither do the "FreeBSD people". Changing the build system a bit or adding a few #ifdefs is nothing compared to your average Windows port (aka rewrite).

Re:Portable code

[Decaff]

Should you choose a language like Java, however, these issues are supposed to just go away - a nice ideal... ("Write once, test everywhere", I believe ;-P )

It really isn't an ideal - it works, and works well. The 'test everywhere' was true years ago when there were portability problems with some aspects of Java (such as threading). But these days, portability is virtually complete.

There are many issues that developers may have with Java - licensing and redistribution etc., but portability is rarely a problem these days.

Re:Portable code

[DrXym]

Take a look at what Mozilla does. Basically it uses the same build system (& autoconf script) for Unix and Win32 but it invokes gcc (or cc / icc etc.) on Unix and cl on Win32. It manages this trick by using lots and lots of macros - project makefiles use macros to specify paths, libs, targets etc. and pull in global rule files to turn these into compiler switches.

Building on multiple compilers also requires writing code to the subset of functionality common to all of them and avoiding dangerous stuff like STL / exceptions etc. Instead of STL, Mozilla uses its own string classes and portable functionality for threads, collections, memory allocation etc. exposed by the NSPR.

Re:Portable code

[Dolda2000]

The way to deal with this is thinking ahead. It's actually not hard to write portable code - the problem is porting code which wasn't designed for it.

I partly agree. It's just that sometimes (quite often for my part), thinking ahead often means writing less portable programs.

I often want to write programs that work as well as they can on my platform (GNU/Linux, of course), and that means taking full advantage of and really adapting to the system in question. For example, using "POSIX-like" directory layouts and file formats, forking and piping, using regexes (which, AFAIK, aren't even available in the basic Win32 API), and sometimes (though I prefer to stay strictly POSIX) using GNU extensions.

That certainly makes the program less portable, and I'm aware of it, but it makes it more integrated with the platform for which it was intended. Sure, you could seperate the core logic algorithms from the O/S-specific code, but that always forces you to rely less on O/S-specific behavior, and often forces you to spend a lot of time on constructing generic abstract interfaces to functionality that exists in different forms on both platforms.

Thus, if one doesn't intend to port ones programs, one does benefit a lot from writing non-portable code (provided that it's done correctly, of course).

Re:Portable code

[Anonymous Coward]

STL? Come on, the C++ standard was ratified SEVEN years ago. Templates were added to the language several years earlier. Why care about people who still haven't got a compiler that supports STL properly?

Re:Portable code

[pdbaby]

If memory serves it used to be. Then adobe decided that supporting windows was a much better idea if they wanted to make an oodleplex of money. They may be employing cunning trickery and not comparing performance of the latest versions. Perhaps.

Re:Portable code

[DrXym]

That's not the point. The point is that the version of STL that ships with Visual C++ is different and behaves differently from the version that ships with GNU libc++ which is different and behaves differently from [insert commercial Unix compiler here]. Even versions of the same STL library differ (e.g. comparing VC98 to VC2002). Reconciling those differences (and incompatibilities) in Mozilla is a waste of time. Mozilla has to build a broad range of platforms, not just the small fraction that possess sane STL implementations.

For example, the STL that ships with VC98 is atrociously inefficient and non-compatible. It doesn't even support fundamental methods such as basic_string::clear. The string buffer allocation reallocs the buffer in fixed 16 byte increments - just imagine what that does for performance. I'm sure libstdc++ has had similar problems in various iterations too.

It's no good either to suggest moving to .NET 2002 or later (which does have better STL), since these decisions were made before such a product even existed. Nor can you insist that everyone in Unix-land upgrade either since they often don't have the choice. Besides, Mozilla now has extremely mature and robust string and collection classes of its own which negates any reason to use anything else. Not only are they mature but they're tailored for multiple purposes. For example, the string classes come in several flavours for handling stack and heap based memory allocations - no such concept exists in STL. There are other flavours for dealing with nsIMemory allocated buffers and so on.

Using STL would be to replace these classes with bloaty and general purpose classes from varying and incompatible implementations. It would be a lot of effort and would make the executable considerably more inefficient and larger than it already is. And to even use STL would require enabling rtti & exception handling on Mozilla which would bloat the code by another 25%.

Re:Portable code

[JWhitlock]

I can't write code myself, so obviously there is a lot that i dont know. But is it really that hard to write code that is portable?

I'm not a polygamist, so obviously there is a lot that I don't know, but I imagine it's about as hard as dating two people at once. Once it goes into production, it's more like being married to two people. Not impossible, but surely you can imagine some of the difficulties. Unless you haven't dated, in which case you should have plenty of time to pick up programming.

Re:Portable code

[dustmite]

Reduced efficiency I'll give you, but because (and only because) Win32 and MFC are such mind-numbingly bad APIs, writing portable code can often be a massive time-saver if you use more well-designed libraries, like wxWidgets ... for our company's main project, I estimate that choosing wxWidgets over Win32 or MFC easily cut down development time by 30% (and that's in spite of our developers all having Win32/MFC experience). And as a bonus, our code is now only a stone's throw away from Linux and Mac ports, which we fully intend on developing.

Re:Portable code

[Anonymous Coward]

Qt (which is much more than just a GUI library) will be available in GPL form on Windows soon, making it a good choice for open-source programs.

Sadly, not as good as you might think. All non-standard toolkits - and Java, GTK, and .NET have the same problem - suffer from the fact that you either have to distribute the toolkit with your program (which feels kind of silly when the program is 300 KB and the toolkit is 20 MB), or you have to tell your users to get the toolkit if they don't have it already (which confuses the fuck out of most people, who don't know whether they have it or not, and still irritates them when they have to download a 20 MB toolkit just to run a 300 KB program).

For traditional CD-based apps, or large apps where the toolkit is not disproportionately large compared to the program, it can make sense. But for most people it just doesn't work.

Even wxWidgets, which proudly proclaims that it uses native widgets, adds a couple of megabytes to the download. That MORE THAN DOUBLES the size of most programs. Doubling the size is not exactly convenient in a world where many people still use dialup connections...

Re:Portable code

[djbckr]

I don't know exactly how they do it, but Oracle's RDBMS runs on all kinds of OSes. OSX, Windows, Solaris, HP-UX, and Linux (among some others). Oracle is fast and it has the same feature set on all the platforms. Oracle on Linux works just like Oracle on Windows.

Now, they have an army of programmers, and I'm certain they write their own compatibility layer. Most bugs I have found in their RDBMS are platform independent - that is, a smallish percentage of bugs are specific to certain platforms.

It didn't really answer the question, but it obviously can be done on a large scale. Oracle has done it quite well.

Re:Portable code

[smittyoneeach]

For some values of "behaves differently"
Go boostify the code in question, and you'll probably get good results for VC7.1 vs. GCC, WRT STL.
The GUI is a different beast--the extended kerfluffles on the boost mailing lists about a boost GUI are an instructive read about the spectrum of design philosophies, irrespective of the gritty implementation details.
But, hey: real men run emacs in a terminal, so what's this fuss about, anyway? :)

Re:Portable code

[Anonymous Coward]

Yes. As long as you don't call functions that are OS specific (i.e. things beyond the Qt library)

Re:Portable code

[LurkerXXX]

There are lots of different reasons for different apps. One in particular I'd love to use, VMWare (v 4), hooks deeply into the Linux kernal, so it isn't something you can just migrate over to a *BSD.

Re:Portable code

[arkanes]

Portable GUIs aren't too hard these days, with several high quality toolkits. Writing these toolkits is much harder, but GTK and Win32 are similiar enough that it's not too hard. Sockets are pretty easy at this point, although there's some behavior differences that can bite you. Threads are a big problem, Linux (and Unix) threading has traditionally sucked, and while Linux has a high quality system now I don't know that any of the cross platform libraries take advantage of it.

Reliance on COM/ActiveX controls and libraries can make porting quite a chore - even when similiar functionality exists on Linux (and it usually does), the API is totally different and that affects the basic application architecture..

Re:Portable code

[ggambett]

You're correct, it's quite possible to write very portable code. For example, I compile our games (follow link at sig) for Linux, Mac and Windows from a single codebase.

The trick is to use portable libraries (in our case, SDL, ZLIB, and a few others), as few OS-specific APIs as possible, and in the occasions when you must use OS-specific code, encapsulate it in a library for which you have multiple implementations.

You end up coding against a (usually) thin layer which is completely OS-agnostic.

About Direct3D and OpenGL, one solution is to have an abstract renderer class which then calls OpenGL or Direct3D. Good examples are the excellent Ogre3D and part of the code in the Doomsday Engine.

Re:Portable code

[naden]

I guess thats just Apple marketing crap then?

What as opposed to any other companies marketing crap .. hmm.

All G4/G5 processors have something called Altivec aka Velocity Engine which is a 128-bit vector processing unit. Photoshop filters being composed of matrix calculations are ideally suited to being computed using the Altivec unit on Macs and the equivalent SSE/SSE2 on x86.

Its just that Altivec spanks SSE/SSE2 quite a bit that Macs have a supposed performance advantage.

Re:Portable code

[mikael]

Put me in this category. I use both Windows and Linux and would love to partially rewrite some of my best selling apps so that they run under Linux. But I'm not sure whether it's worth the effort.

I've been through this phase. As an experiment, I ported one of our in-house tools from MFC to Qt. The stages are quite straightforward:

(1) Split your MFC application into shared libraries and the MFC event handlers. Your shared libraries should be independent of all MFC constructs (CString etc...). The MFC event handlers shouldn't do anything more than make API calls to your the objects defined by the core libraries, and change the state of other MFC widgets.

(2) Port your shared libraries over to Linux. You'll probably end up shuttling the libraries back and forth to ensure any changes made haven't broken anything on the other platform. Both GCC and the MFC compilers pick up different errors, so if your code can compile without warnings or errors on both platforms, it should be fairly reliable.

You can use 'automake' to automatically create the Makefiles for you.

And you can also create command line versions for script file testing.

(3) Port the MFC interface over to Qt using 'designer'. For an application with six dialog windows and one main window, this took me a week working part-time. This will also include icons
and any custom widgets you might need (eg. Combo boxes, List boxes). You'll probably want to look at using the 'configure/make install' framework to allow you to clean and automatically rebuild your application.

Once this stage is complete, you will have an empty application shell ready to be linked
with your shared libraries.

(4) The final stage is to stitch together the Qt GUI interface with your shared libraries. This is probably the most time-consuming part.

All of this took around me around three months working part-time while learning Qt for the first time.

The benefits are:

1. Your source code is more modular.
2. Your source code has been tested with more than one compiler.
3. Your source code is now platform independent.
4. Trolltech can only place distribution rights on the GUI of your application.

Re:Portable code

[fitten]

We saw this way back in the day when Linux was just starting to gain interest. Back before Linux, most code was intentionally made portable across various Un*x variants. You could download the source, configure and make, and off you went. We started seeing lots of patches/fixes and new code written for Linux that didn't port at all. The most annoying thing was the patches/fixes that were put into source bases that were already portable that broke the portability. Linux coding was polluting the F/OSS (before it was called that) world. These simple issues caused us many headaches back in the day.

These issues are less today, but they still exist.... mostly because Linux is killing off the other Un*x and Un*x-clones. Enough people are using Linux and have only used Linux that they think they are doing good things but break things out of ignorance or simply write non-portable code when they think they are writing portable code.

"Back in the day", I worked on two different projects where portability was a concern. One was Un*x/Windows (two flavors of Un*x and Win32) and the other was Un*x only (but about 10 flavors). Not only did the code have to be portable, but the data had to be as well. This included file formats and having all the different systems on the 'net and working together simultaneously. It can (and has) been done but it takes a bit of work.

Also, testing isn't linear in difficulty... Two systems are harder than one system (three combinations... hetero- each type and then both together), but three is not "just a little harder" than two... it's a bit harder... (seven combinations).

Re:Portable code

[Anonymous Coward]

Considering that FreeBSD runs Linux binaries just fine, that simply isn't true (or is a huge exaggeration).

Except for the rare programs that hook into the kernel (VMware, some drivers), porting from Linux to FreeBSD is trivial.

Even dependencies on things like the Linux procfs are easy to handle compared to transitioning from the Win32 GUI API to something like Gtk+ or Qt.

Re:Portable code

[Anonymous Coward]

FreeBSD's POSIX Thread support is pretty good.

Re:Portable code

[Anonymous Coward]

Give Borland Delphi/Kilix a try.

Re:Portable code

[Duhavid]

The decision to be portable should be made up front, before any coding or designing is done, IMNSHO. Then you can see what things are common, at what level they are common, and design, code and purchase/license/use appropriately.

Re:Portable code

[Anonymous Brave Guy]

For example, the STL that ships with VC98 is atrociously inefficient and non-compatible.

In their defence, it was also written before the standard was finished, so some of it was a "best guess". If the next version of VC++ hadn't taken so long to appear, everyone would just have upgraded after a few months and thought nothing of it. The VC++ .Net 2002 release had the twin advantages of actually having a standard to work to, and an extra 4 years of development work behind it, so it's not really surprising that it's better...

Re:Portable code

[rob_squared]

"its too dependant on specific libraries."

Why do you think Microsoft loves providing all those DLLs?

Re:Portable code

[DrXym]

Yes, but Mozilla already had string and collection classes by the time .NET 2002 turned up with a decent STL so there was no point.

Even if someone were to try to port to STL as an exercise, they would quickly realise that each implementation would be grossly inefficient compared to the existing classes and that fixes for one implementation wouldn't work in another.

For example, the Dinkum / VS2002 basic_string implementation allocates memory for strings over 16 bytes (i.e. 16 chars or 8 wchar_ts). Mozilla has an explicit class for stack based strings, and it would be next to impossible to engineer the Dinkum class to support larger stack strings, short of hacking that header with the appropriate changes or cutting and pasting an substantially similar class with a different memory management routine.

And that's just one class. You'd have to repeat for VS2003, plus all popular implementations of libstdc++. And by the end of which you're left with code which is no more efficient than the existing code, but is considerably more bloated due to excessive inlining, rtti & exceptions.

Re:Portable code

[jmccay]

Actually, wxWidgets would be a better choice. It is stable, and it is open source and free on all platforms.
Combine this with SDL (Simple DirectMedia Layer) and Boost.org, and you get a great cross-platform development toolset. SDL is "a Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer."
Boost provides cross platforms threading and other nice things. If you keep your GUI seperate from from the main guts of your processing, you can do cross platform programming rather well.

Re:Portable code

[Anonymous Coward]

It is like compiling with several compilers, they complain about different errors. If you fix so that no compiler gives errors, your code is most likely pretty good.

Same with Java - if you test in several systems, your threading and timing problems are more likely to be exposed now, instead at customers site.

Re:Portable code

[Decaff]

Same with Java - if you test in several systems, your threading and timing problems are more likely to be exposed now, instead at customers site.

What threading and timing problems? I was talking about the situation years ago.

Re:Portable code

[tim256]

Yes, MFC is gross. For the past few years, I've been using Java/swing and C#, but for some apps they are too slow. I really like swing, but it has so much overhead and setting up the placement of GUI objects is a pain.

I went to the wxWidgets site, and it looks pretty sweet. I'll have to try it out sometime. Thanks for the link.

Re:Portable code

[oistrakh]

Hmmm... how should FreeBSD maintainers ifdef out ALSA from a Linux application? While I agree that porting the average Windows app is exponentially more difficult than porting the average Linux app, the point is still valid. As Linux continues to dominate in mind-share, if not real-world usage-share, it's inevitable that if developers aren't careful they are going to start writing apps that aren't easily portable to other un*xes. If portability is a goal, it has to be planned up front, and Windows developers are far from the only developers out there who don't plan for portability.

Re:Stupid question

[Mercedes308]

What I was getting at is if it was a porting or the application ran in a virtual OS.

"windows"

[tonekids]

The hardest part of porting to LINUX will be refactoring all of the GUI stuff.

Re:"windows"

[lachlan76]

Well there's wxWindows which eases porting the MFC programs.

Re:"windows"

[Anonymous Coward]

Use wrappers.

Or better yet, dont use a SYSTEMS language for APPLICATIONS, use C# on Mono and GTK bindings or something or Java etc.

C and C++ and so on are SYSTEMS languages and applications in usermode should sit on a VM really, welcome to the year 2005. Performance, please, thats an stupid argument, you can compile and not run in JIT mode easily with virtual machine languages, you just lose out on dynamic optimisations that any JIT compiler may have and son on.

Re:"windows"

[Greyfox]

The hardest part of porting to Linux will be figuring out what all those hungarian notation variables were supposed to be. pszStringVar3? WTF?! Hungarian notation is always a warning sign that deeper evil lurks within the code disguised by programmers pretending that they know what they're doing because they can adhere to a naming convetion for warts while choosing actual variable names that make absolutely no sense. If you notice that hungarian notation is in use, it's going to mean that the project is going to end badly. Insure that programmers who insist in using it are removed or assigned to little projects that will probably never be used so they don't end up dragging everyone else down with them.

You'd think I was overgeneralizing, but I'm not. Absolutely every single time I see HN in use, I quickly end up learning that the programmer who wrote the code was an idiot. On at least two separate occasions, I've had to correct C code with HN that did not allocate space for the null terminator on any strings anywhere in the code. That's pretty much the level of programming talent you can expect when you see HN in use.

Conversely, I have never seen any code using HN which I looked at and thought to myself "Well that's a sweet way to solve that problem!" Not even once have I ever seen an elegant algorithm expressed in code written with HN. Not one single time.

Now I could propose several different reasons why I think this might be the case. It could be that HN actually causes brain damage in otherwise able individuals. It could be that it is a harbinger of doom, like some programmatic horseman of the apocalypse. More likely the programmers in question went through some community college somewhere and HN was the only thing they can remember from their beer-and-drug soaked college days. They've advertised that they know how to program and probably claim to have invented C, and they point to their strict adherence to programming convention, missing the fact that conventions without understanding is still stupidity. And it's not like managers typically know any better.

Which is why every trace of HN must be eradicated from any code which is ported, before it is allowed near our pristine and pure operating system. Well that, and the code will be more maintainable in the long run.

Re:"windows"

[Threni]

> That's pretty much the level of programming talent you can expect when you see
> HN in use.

No, that's the level of programming YOU can expect. There's nothing wrong with hungarian notation. How showing the type of a variable makes cost less maintainable is beyond me. There are many programming styles, with arguments for and against them. Your post doesn't further any of them - it simply states that you are a better programmer than anyone who uses HN whose code you've seen, which suggests that either you've not seen vary much code or you're in no position to judge the quality of other people's code.

Re:"windows"

[Anonymous Coward]

not with winelib:
http://www.winehq.com/site/winelib

Re:"windows"

[JohnFluxx]

Your logic is faulty, both reading and writing.

"it simply states that you are a better programmer than anyone who uses HN whose code you've seen, which suggests that either you've not seen vary much code or you're in no position to judge the quality of other people's code."

It could also be that people that use HN are worse programmers, like he says. He never said HN was bad, he said programmers that use HN are bad.

Re:"windows"

[johannesg]

Here's an argument or two against HN:

- HN seems, for many people, to serve as a replacement for the actual name. It is easy to write psz1 and psz2 when you want two pointers to zero-terminated strings, but really - I'd rather have their meaning than their type. You may argue that this is simply bad usage (and I'd agree) but I've seen too much code by now that does this to believe it is coincidental. Coming up with good names for variables is hard. Once you have a few characters, even if they don't mean much, people tend to stop thinking and just use it.

- HN adds long strings of unpronouncable garbage throughout the source. That decreases general readability.

- When a variable changes type, you should also rename it everywhere it is used. People tend to not do this, resulting in a system that actually gives the wrong information.

- HN places a great deal of stress on variable type. In my not so humble opinion type is important, but not quite _that_ important. In reality I find myself caring about meaning, then about scope, and finally about type - in that order. And you should be thinking "objects" anyway, not actually caring about type since that's all encapsulated.

More here...

Re:"windows"

[Anonymous Coward]

When I read your comment all I just kept thinking

bDumbass = True

Re:"windows"

[Tim Browse]

If you notice that hungarian notation is in use, it's going to mean that the project is going to end badly.

Overgeneralise much?

Re:"windows"

[dustmite]

Rather. I must say I've seen many examples of very successful and well-designed systems implemented by programmers that used HN. And likewise I've seen a lot of incredibly retarded code (far worse than not allocating space for the NULL terminator character) by people who didn't use HN. The key as with any tool is to use it properly. Bad programmers are going to produce bad code no matter what notation they use, and good programmers are going to be successful no matter what notation they use. Slam bad programmers for being bad programmers, and end it there. I'm not sure why GP has such rabid feelings about this issue.

Re:"windows"

[ggambett]

I find the usual hungarian a bit cumbersome, but I do use a "simplified" version that I find useful. bBoolean, sString, nInteger, fFloat, lList, pPointer, hHash and not much more.

Re:"windows"

[Anonymous Coward]

read much?

Re:"windows"

[robocrop]

Refuting your arguments:

HN seems, for many people, to serve as a replacement for the actual name.

Translation: because some people use it poorly, it shouldn't be used.
Analogy: Then nobody should be allowed to drive.
Point: Invalid.

HN adds long strings of unpronouncable garbage throughout the source

This argument is simply ridiculous. HN descriptors are not mean to be "pronouncable", they are a compact way of expressing meaning.
Point: Invalid.

When a variable changes type, you should also rename it everywhere it is used. People tend to not do this, resulting in a system that actually gives the wrong information.

In addition to being similar to point one, this argument also applies to pretty much every other naming convention as well. So if you call your variable "PointerToThing" but change it to a reference, you still have to change the name of the variable. The only way you don't have to change your variable name when you change the type/use of the variable is if you use meaningless variable names.
Point: Invalid.

HN places a great deal of stress on variable type. In my not so humble opinion type is important, but not quite _that_ important

Problem here is that this relies upon your opinion which is certainly subjective, certainly limited, and probably doesn't apply to what other people are working on.

If variable type always didn't matter, nobody would have invented Hungarian notation.

The other arguments are exactly the same nonsense. I really wonder if you people would be so anti-HN if Linus had invented it. Just admit it - you're anti-HN because it's an idea fostered by Microsoft.

HN definitely has its uses. At the very least, the m_ notation to denote member variables is useful enough to justify its existence.

If you don't like it, don't use it. Simple as that.

Re:"windows"

[Greyfox]

Yeah you'd think that wouldn't you? Well I do only have have a bit over a decade of actual professional programming experience to back me up, miniscule compared to the number of man years of actual implemented code out there. If I ever do run across some glorious, readible, maintainable system implemented using HN, I'll change my opinion of it. In the mean time, I will treat any HN systems I run across with fear and horror.

One might also point out that if you actually adhere to good structured programming techniques (You know, what they used to teach back before OO) your functions should never be long or complex enough that you can't easily keep track of all the variables. If your function is that long and complex, you need to refactor it into smaller steps.

I find that OO languages can make keeping track of variables more difficult since the member variables are often not right there where you can see them when you're implementing a method. I also find that documenting which member variables a particular method changes helps with that particular problem. The biggest problem I tend to have with OO is remembering if a method already exists in the system somewhere that does a job I need done.

Re:"windows"

[swillden]

The only way you don't have to change your variable name when you change the type/use of the variable is if you use meaningless variable names.

Ah, thank you, you just demonstrated the fallacy of your own argument by conflating type and use. They are not at all the same, and the distinction is very important, but HN encourages combining and therefore confusing them.

A really good variable name expresses what the referenced object is in context. What is it used for? What concept does it represent? The type of the referenced object shouldn't be relevant to understanding the intent of the code. The only time you need to know the type is when you're looking to see if some type-related error has caused the intent (which is correct) not to match the actual execution.

IOW, HN is a boon to programmers who write lousy, hard to read code and spend a lot of time debugging it.

Looked at that way, it's not hard to understand why Microsoft is so closely associated with HN, is it?

I, personally, have seen both good code and bad code that uses HN. More bad than good, but I have seen good. And I've even seen cases where it's actually useful and informative. The fact that it encourages less-than-excellent programmers to use lousy names, rather than thinking up something descriptive, is enough reason for me to discourage its use.

The biggest single reason I hate it, however, is tool-related: I like to be able to type the first character or two of a variable name, hit Meta-/ and let EMACS type the rest of it for me. For that reason, on the rare occasions I attach informational 'tags' to variable names, I put the tags at the end. I generally use tags to indicate scope, rather than type, though, since, like johannesg, I think scope information is more valuable than type information.

Re:"windows"

[swillden]

I do use a "simplified" version that I find useful. bBoolean, sString, nInteger, fFloat, lList, pPointer, hHash and not much more.

A simple way to improve on that is to move the type tags to the end. That way the information is still present, but doesn't take precedence over the descriptive variable name. Also, it facilitates the use of automatic expansion by good editors, since you have to type fewer characters before uniquely identifying a variable.

Consider using something like ReachedListEnd_b instead of bReachedListEnd. After a little use, the '_' becomes an "ignore the rest, except when you care" signal to the brain.

I use that occasionally, except that I tend to tag variable names with scope information, rather than type information.

Re:"windows"

[robocrop]

Ah, thank you, you just demonstrated the fallacy of your own argument by conflating type and use

Actually, no, I've illustrated that you are completely incorrect for stating that they are always not the same, or always not related.

A really good variable name expresses what the referenced object is in context

Indeed. And what is useful about HN is that it allows you to also include the type of the variable, in relative shorthand for - pay attention here - those situations where the type of the variable might be relevant information. For many programming situations, the type of the variable is frequently relevant information. Thus, for many programming situations, HN is quite useful.

IOW, HN is a boon to programmers who write lousy, hard to read code and spend a lot of time debugging it

Wow, that certainly is a well-thought-out, even-handed, and professional comment, isn't it? Thanks for helping reinforce my statement about how your position regarding HN is an anti-Microsoft, kneejerk reaction.

I, personally, have seen both good code and bad code that uses HN. And I've even seen cases where it's actually useful and informative.

Then you've just subverted your own position that HN is useless!

I attach informational 'tags' to variable names, I put the tags at the end

... and now you're just arguing semantics. Put them in the middle, the end, the line above - whatever. Call it Ukrainian notation. The basic idea is still quite sound.

The biggest single reason I hate it, however, is tool-related

... because you use Emacs. So - here's a shocking position - don't use HN. But don't have the unmitigated gall of trying to tell me you're a better programmer because you don't.

Using HN does not mean you are a "lousy" programmer, or that you write "buggy" code or "spend a lot of time debugging it". This is just another religious argument, much like the "gcc can beat up VC", "Linux r0x0rs Windows", and "OpenGL roolz b/c it's open!" beliefs.

Re:"windows"

[ggambett]

I'll try that sometime. About scoping, I do that too - the examples I gave were for locals. bDone becomes m_bDone when it's a member variable or s_bDone if it's static.

Re:"windows"

[Anonymous Coward]

What are you going to complain about next?

while (1)
if (x == 0)
break;
else
{
goto whatever;
continue;
}

Re:"windows"

[johannesg]

Refuting your refutations:

Translation: because some people use it poorly, it shouldn't be used.

I'd agree if it was only _some_ people that use it poorly. There is overwhelming evidence, however, that it is the majority that does this. This points to a flaw in the design of the methodology: it invites people to do the wrong thing. As a result I consider it more of a hindrance than a help.

A better translation would therefore be: because _most_ people use it poorly, it shouldn't be used.

HN descriptors are not mean to be "pronouncable", they are a compact way of expressing meaning.

Actually they express _type_, not meaning. Confusing the two is not a good sign. Also, I find that software written to be pronouncable (as opposed to, say, source that leaves out all the vowels in a misguided attempt to be "shorter") is much more maintainable. Tacking on these strings simply does not help that goal.

I also place question marks on any methodology that apparently strives to reduce the readability of software.

In addition to being similar to point one

Only in the sense that, once again, HN invites people to do the wrong thing. The actual problem is quite different.

this argument also applies to pretty much every other naming convention as well. So if you call your variable "PointerToThing" but change it to a reference, you still have to change the name of the variable

My argument is that it is bad to assign names based on type. A different encoding of the type doesn't change that, it is still a bad idea. PointerToThing means absolutely nothing to me, since there is no meaning implied in it. This is _exactly_ what I meant: you provided a type but a completely meaningless name, and I (taking on the role of maintenance program for the moment) have no clue what you could be pointing to.

The only way you don't have to change your variable name when you change the type/use of the variable is if you use meaningless variable names.

As another poster already correctly pointed out, confusing type and use is not a good sign of your understanding of the problem. But leaving that aside for a moment, let's try an example. Suppose I have an industrial control application, containing code in either your or my notation. Which is clearer:

if (PointerToThing->Status () == OPEN) { PointerToThing->Close (); };

...or... if (NitrogenValve->Status () == OPEN) { NitrogenValve->Close (); };

? Personally I prefer the second, since I can tell what it is doing. In the first case I'm left to guess, even though I can tell I'm doing something with a pointer.

Problem here is that this relies upon your opinion which is certainly subjective, certainly limited, and probably doesn't apply to what other people are working on.

Since you are disagreeign with my argument, evidentally you believe that type is more important than both scope and meaning. I suppose we could have an argument about scope, but the very idea that type is more important than meaning is utterly ridiculous.

If variable type always didn't matter, nobody would have invented Hungarian notation.

Actually I said it was of lesser importance than meaning and scope. As to how the invention of HN implies a need for it, I'm uncertain. People invent meaningless crap all the time.

The other arguments are exactly the same nonsense.

I presented just the four you refuted. What other arguments you may have seen exist only in your imagination.

I really wonder if you people would be so anti-HN if Linus had invented it. Just admit it - you're anti-HN because it's an idea fostered by Microsoft.

For that silly ad-hominem you really deserve a -1, troll. I don't give a flying fuck who invented it. I just don't like it. I actually care about the maintenance of the software I'm responsible for, and I find HN creates much more of a mess than it solves. But hey, if you find it hard to attack the message you can always try your luck attacking the messenger.

Re:"windows"

[dcam]

I think with a move to OO languages HN becomes moot.

HN assumes that there are common variable types, and that they are common enough the someone else reading your code will recognise what the variable is in an instant. If most of your variables are classes you have written, you would need to come up with your own prefixes, which means that people will not understand them.

I personally find some prefixes useful. For example when writing C++ I use "m" for member variable and "p" for pointer (m has precendence, so a member pointer would be mp).

Re:"windows"

[Anonymous Coward]

[A priest stands guard at the pristine gates of the halls of purity]

Man: Preach the good word priest!! Hallallooyaa!! I aim to join ya so we can git out and round us up some o' these HN using heathens and ship 'em off to MicroHell. Maybe they'll have a use er two for 'em there.

[the priest points at the man and yells]

Priest: "False one! You use HN! I can smell it on you."

Man: Um, well, I guess you could say that but it's a simplified HN, that's not the same is it? I mean, it doesn't really count if it's simplified, does it?

[the priest snarls and advances]

[the man slowly retreats]

Man: But it really is very readable!

[a hiss twists its way from the priest]

Man: I always know the scope and type of each symbol at a glance.

[the priests eyes begin to glow a feral green]

Man: Hey, I even know the...

[the priest's eyes flash green like a hundred Apple II monitors at full power]

Man: RUN AWAY...RUN AWAY

[the priest spits the foam from his mouth and wipes it dry]

Priest: As if we needed anything more than the name. Bah!

Programming in C++ on Linux

[__aaclcg7560]

Does anyone know of a good book on C++ programming in Linux?

I'm taking a C++ class at the local college that's being taught by the Unix guru. The class is using Visual Studio .NET as the IDE (which the instructor is not familar with and is threatening to go to Linux instead). At home, I'm using Visual C++ 6.0 Learning Edition that was provided by the Deitel and Deitel book. Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

Anyway, I tried compling the sample programs under gcc and g++ on my Linux file server, and I get a lot of errors. I thought C++ (or at least, C) was supposed to portable. ;) I would like to learn how to program basic C++ fluently on both platforms.

Re:Programming in C++ on Linux

[mingot]

I'm taking a C++ class at the local college that's being taught by the Unix guru. The class is using Visual Studio .NET as the IDE (which the instructor is not familar with and is threatening to go to Linux instead).

No offense, but anyone who can't figure out how to use and become familar enough with the visual studio IDE to use it in a teaching environment shouldn't be called a guru of anything. It's extremely simple to use until you want to start doing very complex things. And that's when you start pining for makefiles. I can't imagine you're writing anything that complex for (what your post would indicate is) an introductory c++ class.

Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

Actually, there is. Where it is buried in the settings? Couldn't tell you off the top of my head, but here is something for you to try: Navigate to the directory where the exe is being dumped and run the thing from the command line yourself.

Anyway, I tried compling the sample programs under gcc and g++ on my Linux file server, and I get a lot of errors. I thought C++ (or at least, C) was supposed to portable. ;) I would like to learn how to program basic C++ fluently on both platforms.

Not familiar with the book, but unless it is doing something windows specific (and it may be) you should not have any trouble compiling simple programs under gcc and the MS c++ compiler.

Re:Programming in C++ on Linux

[BlurredWeasel]

I am taking a class right now focusing on Linux C++. As far as I can tell, C++ is rather standardized (nowhere near Java though...).

The things that are standard are the basic syntax and structure (declaring variables/classes/everything). The other thing that is standard is the STL and a few standard functions left over from the C days.

The things that aren't standard are the system libraries. So in windows when you use MFC and similar (I don't program windows, don't jump on me about windows junk), or in linux when you program against GTK, or QT, you need those libraries in Windows. Similarly, if you wanted to compile windows apps in linux, you'd need those windows libraries. The problem being that you can't get windows libraries in linux.

Wine tries to provide those libraries to already compiled programs so that they can run, but honestly it isn't very good for anything non-standard (but definatly getting better by the day!).

Hope this clears up the universe and shown you how programming windows via windows apis is a bad idea in terms of portabilty.

Re:Programming in C++ on Linux

[Mystic0]

C++ is not supposed to be portable. Don't expect the Deitel examples to always work if they are designed for a Windows enviornment.

I don't know of any Unix / Linux specific C / C++ book, but considering that C was originally meant to be used in a Unix environment, you should have no trouble using it in a Linux enviornment if the book is a traditional C / C++ Unix book and isn't clobbered with Windows junk. "The C Programming Language", by Kernighan and Ritchie comes to mind.

Your instructor sounds like he is unfamiliar with your school's software. This is unfortunate, because that software costs money and it is a shame to have it go to waste.

A good, free, Windows IDE is Bloodshed Dev-C++, which is basically the GNU C Compiler bundled with a GUI. It's quite nice, and it's free. On Linux, well, I just use a text editor and a terminal. But there are IDEs out there if that's your inclination.

Here is a link to the Dev-C++ page: http://www.bloodshed.net/devcpp.html

Re:Programming in C++ on Linux

[spectecjr]

I'm taking a C++ class at the local college that's being taught by the Unix guru. The class is using Visual Studio .NET as the IDE (which the instructor is not familar with and is threatening to go to Linux instead). At home, I'm using Visual C++ 6.0 Learning Edition that was provided by the Deitel and Deitel book. Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

That's because you're running it under the debugger, and the assumption is that if you want it to stick around, you most likely have a breakpoint set somewhere.

Run it outside of the debugger - namely, by hitting CTRL+F5, or the "!" icon - and it'll run and when it terminates it'll ask you to press a key before finishing.

There you go. Learn your tools, and you'll find it much easier to use them.

Re:Programming in C++ on Linux

[Mystic0]

I take it back when I said "C++ is not supposed to be portable." It really depends. Straight C++ with no OS specific calls should work just fine on any platform. (You'll have to recompile it of course)

If you are having problems, make sure that there aren't any OS specific calls being used.

Re:Programming in C++ on Linux

[dejavudeux]

>Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing). This is a real annoyance for me, too. I've searched through the dialogs a little and didn't find it. (Although if I program with the IDE a little more I would just Google for the option.) Incidentally, another quick hack you can use in this situation is to add a std::cin.getline() at the end of the program. However, I feel bad saying that because you'll be far more productive in the long run if you just look it up.

Re:Programming in C++ on Linux

[miyako]

Most C++ books will cover C++ in a way that should be applicable to Window or Linux, so long as you don't go for one that specifically mentions VC++ in the tittle. I've been partial to "C++ The Complete Reference", since in my experience, if you already know how to program, a reference style book is more useful in the long term for a particular language. Another book I've been particularly partial to is C++ GUI Programming with Qt.

Re:Programming in C++ on Linux

[AmberBlackCat]

I was using CodeWarrior, Visual C++, and GCC and my main professor was a Linux guru who despises Windows. From what I can remember, Visual C++ was the most troublesome. I think it would be a good idea to set your compiler to only accept ansi C++ code because that's what GCC handles. If that doesn't work then try downloading DJGPP. It's like a DOS version of GCC. If you can get your code to compile on that, it will probably compile on GCC. And it's been a while since I used GCC but I'm pretty sure you have to type G++ instead of GCC to compile C++ code instead of C code, just in case you didn't know.

For book recommendations, I think your Deitel book is fine because ansi C++ is crossplatform as long as you're not including unistd.h or windows.h or whatever that other unix include file is.

I hope that helps.

Re:Programming in C++ on Linux

[Anonymous Coward]

Or you can put a simple system("pause"); at the end.

And that's not a DOS box, it's a command prompt (on Linux, you would call it bash, shell, terminal)

Re:Programming in C++ on Linux

[vistic]

If you're programming a simple program in Visual Studio and it won't compile when you try doing it with gcc/g++, it's probably a very simple problem.

Your main in Visual Studio is probably "void main(void)" and returns nothing. To compile it in gcc, declare "int main()" and make the last line of main "return 0;" and it will probably compile.

Re:Programming in C++ on Linux

[CodeBuster]

I remember my early days in CS when my simple first year lab assignments, written in C++, wouldn't port between the CodeWarrior compiler on the Macs in the labs and my Visual C++ compiler at home. The problem is not in the language per se, but more often with differences in the ways that compilers handle certain situations such as the classic:

What happens when you call an overridden virtual method from a virtual base class's constructor?

C++ is a powerful language, but it is too easy to shoot yourself in the foot if you do not fully understand the language and the ins and outs of your compiler. That is why I now tend to avoid it, if possible, in favor of more modern languages such as Java or C#. You give up some fine grained control and speed but frequently the gain in productivity is worth the small price that you pay (you can often do in a few lines of Java what might have taken 50 or 100 lines of C++).

Re:Programming in C++ on Linux

[EvanED]

Which will run really well when you try compiling it with another compiler...

Re:Programming in C++ on Linux

[Anonymous Coward]

He said they are using VS.NET

Re:Programming in C++ on Linux

[Anonymous Coward]

Don't forget that even the console is OS specific (MacOS 9 or embedded for example). So, congrats, you've just written a useless program.

Re:Programming in C++ on Linux

[EvanED]

And he was also asking about books for C++ programming on *Linux*, saying that the class might change to *Linux*, and complaining that *GCC* was giving error messages. Clearly he has some interest in portability.

Re:Programming in C++ on Linux

[__aaclcg7560]

That is why I now tend to avoid it, if possible, in favor of more modern languages such as Java or C#.

I prefer Java a whole lot better and I'm also taking Java Servlets this semester. But resume-wise I'm trying to broaden my prospects by taking other programming language classes and then specializing on whatever language is being used at the next job.

I recently had an interview for a testing/programming position at one of the local software companies. If I get the job, Javascript will be my bread-and-butter programming language for a while.

Re:Programming in C++ on Linux

[Anonymous Coward]

No, was he said was:

Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

Something like this couldn not occur on Linux (and system("pause")) wouldn't matter because you have to run that app from the shell.

Re:Programming in C++ on Linux

[Anonymous Coward]

So you're saying code that compiles in VC++ won't compile in gcc? It might be this:

In VS.NET 2003 (I have not used prior versions), a default c++ win32 console application has all kinds of extra crap in it. Your empty program looks like this to begin with:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}

Make sure when you first start the project to click Application Settings and then select empty project...this will give you a 100% empty c++ project.

Re:Programming in C++ on Linux

[__aaclcg7560]

Your instructor sounds like he is unfamiliar with your school's software. This is unfortunate, because that software costs money and it is a shame to have it go to waste.

After waiting three years for funding, the school finally upgraded from Visual Studio 6. Seems like all the instructors are having a hard time adjusting to the new IDE since the upgrade took place over the winter break. If the upgrade happened over the summer break, I think the instructors would've been better prepared.

Classes that uses programming languages that can be downloaded free (i.e., Java, Javascript, Perl, etc.) are usually more current since you're not tied to an platform- and/or language-specific IDE.

Re:Programming in C++ on Linux

[ccoakley]

As far as I can tell, C++ is rather standardized (nowhere near Java though...).

Funny you should say that as C++ is an ISO standard and Java is not a standard at all. In fact, the Java Language specification can't really be called a standard definition because it defines Java's lexical grammar in terms of Java classes:

Section 3.8 of the java language specification:
A "Java letter" is a character for which the method Character.isJavaIdentifierStart returns true. A "Java letter-or-digit" is a character for which the method Character.isJavaIdentifierPart returns true.

You could iterate through all characters (not that you can really do that for all Unicode character sets... but anyway...), and Sun could change their mind and say, "Naw, that's no longer a valid letter." Changing Character's static methods would keep the spec correct but change the lexical rules of the language.

OK, your meaning was actually obvious, just ranting...

Incidentally, the Win32 APIs *are* a standard. ECMA standardized them many years ago (yes, they have changed since). None of the GUI libraries for linux are standard (I may be full of shit, X may be recognized by a standards body). Of course, this just means that ECMA really is a "Standards for sale" organization.

Re:Programming in C++ on Linux

[izakage]

Thank you for pointing me towards "The C Programming Language" book. My dad had purchased it tens of years ago, but never got around to messing with it, and I had noticed it in his bookshelf many times when I was younger. You've inspired me to pick up the book and start learning. Thanks.

Re:Programming in C++ on Linux

[MidnightBrewer]

No offense, but anyone who can't figure out how to use and become familar enough with the visual studio IDE to use it in a teaching environment shouldn't be called a guru of anything. It's extremely simple to use until you want to start doing very complex things.

Being able to jump from one software package to another isn't always easy, even if the new one is supposedly better. I just recently change video compositing packages to a better one and expect to take a few months of constant use (or more) before I'm as fluent in it as I was in the previous software, which I've been using for seven years. The workflow is different, the terminology is different; it's a lot like learning a new programming language.

You get comfortable with your tools, it's going to take you a while to get used to new ones. It has nothing to do with your ability as a programmer.

Re:Programming in C++ on Linux

[John Pliskin]

system("PAUSE");

before the end of your main(), that'll stop the program. Now if it's a C++ program, just place it again, it'll be apart of the std namepace, so no worries.

Re:Programming in C++ on Linux

[Anonymous Coward]

If I get the job, Javascript will be my bread-and-butter programming language for a while.

I'm sorry, but I don't think Javascript even counts as actually programming :). Please learn C. I love Java too, but you'll have a much easier time finding a good software development position with skills in C/C++. If you already know Java, just pick up the Kernhigan & Ritchie text and read up on pointers and structs. You'll also need a book on system calls for your OS of choice if you're doing anything serious, but K&R is a good place to start.

Re:Programming in C++ on Linux

[b17bmbr]

if someone has been doing something a certain way for years, then it will become second nature. any changes and they get all tweaked. and as for programmers, especially older c/c++ guys, probably cut their teeth on vt100 terminals, etc., "the good old days...", VS would be like putting richard petty into the space shuttle. not to typecast or stereotype, but programmers (not wannabes like myself, i do java, php, etc.), guys who are real gearheads, are gonna be a little compulsive, like musicians. fine. lord knows we need good programmers. anyways, i see kids like that in my classroom, the minute you do something different, they literally freak out. i try to keep my class fairly consistent, but on occasion, i'll do something like have them read battle accounts then write poetry like a ww1 soldier (i teach history, btw) some of them just go ape shit. they literally can't think in that abstract sense. or i'll have them label a map with the countries, the battles, then chart the casualties. that sort of order throws the other half off as well. it's like, "what do i label?", "where do the KIA go?", etc. they refuse to do something in a specific manner.

and that's alot like an ide, especially one from microsoft. hell, you do it there way. period. i can totally see how a guy could be a c++ guru but get turned upside down with VS. remember, tools and carpenters are distinct items.

Re:Programming in C++ on Linux

[Anonymous Coward]

Yeah, Kernighan & Ritchie is pretty much the bible on C.

Re:Programming in C++ on Linux

[Anonymous Coward]

Which will run really well when you try compiling it with another compiler...

That's what #ifdef is for.

Re:Programming in C++ on Linux

[pe1rxq]

Just make sure you are not using a pre-ANSI version....

Jeroen

Re:Programming in C++ on Linux

[Couldn'tCareLess]

#include <iostream>

// ... everything else

#ifdef WIN32
char c;
std::cin >> c;
#endif

// ...

That'll stop the command prompt from disappearing at the end. There's probably a checkbox in the IDE somewhere so this is a bit of a fudge, but it's a quick and easy solution :)

Re:Programming in C++ on Linux

[Victor_Os]

No offense, but anyone who can't figure out how to use and become familar enough with the visual studio IDE to use it in a teaching environment shouldn't be called a guru of anything.

You are slamming a guy you know nothing about based on your (untrue) assumptions. Don't do that.

Re:Programming in C++ on Linux

[Anonymous Coward]

Wine tries to provide those libraries to already compiled programs so that they can run, but honestly it isn't very good for anything non-standard (but definatly getting better by the day!).

Wine also provides Winelib, which is an ELF library which can be used to compile and run your Win32 targetted code on non-Win32 systems.

Re:Programming in C++ on Linux

[Anonymous Coward]

Have You ever considered writing proper sentences?

Re:Programming in C++ on Linux

[zootm]

Hopefully C will be being phased out with most applications that don't require break-neck speed or legacy compatibility, in favour of more modern languages. I know some people disagree on this, but C and C++ are, in my eyes, not so useful as they once were. The performance gain in older languages in most cases really doesn't justify the productivity loss.

I agree 100% about Javascript, though. I've been using it (I write Mozilla extensions from time-to-time) and it feels like being forced through a thin mesh screen. Urgh.

Re:Programming in C++ on Linux

[Anonymous Coward]

If you don't undrestand what the errors are, then you don't know the language well enough yet. Stick with Visual Studio on Windows until you become comfortable with C++ and understand what's going on. Visual Studio is a great tool, and very good for learning. (cue the fanboi flames)
Once you get comfortable with the language and the environment, then work on the cross platform compatibility. By then you should have a better idea of what your errors are, and you'll start to see what you need to do to write portable code.

The best advice is to not get caught up in this holy war. Your job now is to learn, not to write enterprise quality, portable to everything under the sun code. Your instructor is just masking his laziness by complaining about how much Microsoft sucks.

Re:Programming in C++ on Linux

[Anonymous Coward]

What? My professor told me never to use iostream like that. The code should be like this:

#include <iostream.h>

// ... everything else

#ifdef WIN32
char c;
cin >> c;
#endif

// ...

Re:Programming in C++ on Linux

[JeffTL]

I never had any trouble doing the Deitel samples (and programming assignments in a class using that boiok) using g++ on OS X, and I'm 99% sure they all should work on Linux.

Perhaps the problem is that the relatively lax Microsoft compiler has let you get started with bad habits that GCC doesn't accept. use "g++ -Wall blah.cpp" and keep editing and recompiling until all the warnings go away.

Be sure to use a text editor where you can turn on line numbers (and syntax coloring, if you like that), such as vim.

Re:Programming in C++ on Linux

[AsimovBesterClarke]

> hitting CTRL+F5, or the "!" icon - and it'll run and when it terminates it'll ask you to press a key before finishing.

And people complain about Unix arcania.....

Re:Programming in C++ on Linux

[Branko]

What happens when you call an overridden virtual method from a virtual base class's constructor?

A base class method gets called. This is actually defined by C++ standard and all compilers should handle it this way.

Re:Programming in C++ on Linux

[Anonymous Brave Guy]

I know some people disagree on this, but C and C++ are, in my eyes, not so useful as they once were.

I don't so much disagree as think it depends on your perspective. C and C++ both were, and both remain, excellent at what they were designed for: being a portable assembly language and being a powerful systems programming language for skilled programmers, respectively. They also have niche uses elsewhere, such as writing high-performance libraries that use a lot of maths (3D graphics, for example). The problems started when they became popular for other tasks -- notably application programming by non-expert developers -- because there wasn't a lot of choice. Today there is, and it's more important now to choose the right tool for the job.

Re:Programming in C++ on Linux

[Anonymous Brave Guy]

My professor told me never to use iostream like that.

Either you're a fairly obvious troll, or your professor is sadly ill-informed. In case it's the latter: the use of <iostream> (and other headers with no .h suffix) and the std namespace has been standardised for many years. The old <iostream.h> stuff doesn't always work the same way, and is officially deprecated.

Re:Programming in C++ on Linux

[Branko]

Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

The easiest way to stop console program before exiting (and closing console) is to put a breakpoint in the end of main() (provided you did not use exit() indiscriminately). In Visual Studio, you also have an option of running the program (as opposed to debugging), using "exclamation mark" button. And, as another poster suggested, you can run your program from the command line directly.

Only the first solution will enable you to debug the program though...

Re:Programming in C++ on Linux

[spectecjr]

And people complain about Unix arcania.....

I don't expect my Grandma to be able to run a set of developer tools. Understand the difference?

Besides, it sounds like you've never used Visual Studio - it's not exactly hard to find this out - there are only two ways to run an app you're developing anyway, and both are available from the Debug menu. This one's called "Start without Debugging" - the other mechanism is called "Start".

Re:Programming in C++ on Linux

[zootm]

I don't so much disagree as think it depends on your perspective. C and C++ both were, and both remain, excellent at what they were designed for: being a portable assembly language and being a powerful systems programming language for skilled programmers, respectively. They also have niche uses elsewhere, such as writing high-performance libraries that use a lot of maths (3D graphics, for example). The problems started when they became popular for other tasks -- notably application programming by non-expert developers -- because there wasn't a lot of choice. Today there is, and it's more important now to choose the right tool for the job.

Good point, well made. That's very close to what I was trying to say.

Re:Programming in C++ on Linux

[Anonymous Coward]

You get comfortable with your tools, it's going to take you a while to get used to new ones. It has nothing to do with your ability as a programmer.

Yeah, but if one is a guru or a wizard they typically are in a high enough percentile of the totem pole that for simple everyday tools like easy as shit IDEs, Word processors, etc, they can handle it in a few minutes. I remember when I took a contracting position and it was my first exposure to VB6, it took me about 10 minutes to be familiar with every single feature of the IDE and a little prodding into the text and bin files it generated explained the whole thing.

The general term for this is grokking. Anybody called a guru has a knack for grokking most simple apps completely in a few minutes. Sometimes it has to do with stubborness, I find the Visual Studio interface extremely frustrating (like the GP), but I can't see how any so-called expert couldn't anticipate potential menu locations for different types of settings. Part of this skill is anticipating idiosyncracies.

Remember, keep this in context: This is about a guy trying to grok an IDE to do hello world, not do production work and acheive full workflow efficiency...
And when you get down to it, video compositing/modeling/illustrating workflow has virtually no comparison to actually dealing with IDEs, it's actually more comparable to the programming itself. I would compare your experience to someone picking up Python (or other new language) for the first time.

Re:Programming in C++ on Linux

[EvanED]

What he was takling about there is, IMO, irrelevant. It's clear that he has interest in programming on Linux from his other questions, so posting advice on a non-portable solution for anything is poor council unless there is no reasonable alternative.

Re:Programming in C++ on Linux

[Couldn'tCareLess]

In addition, the code given by the grandparent would not compile (at least not with a standards-based compiler), as cin is not within scope - a using declaration or directive is required (or direct resolution - as in the original code).

I'm guessing you know this, but the grandparent needs to have a word with their professor ;)

Re:Programming in C++ on Linux

[dcam]

Does anyone know of a good book on C++ programming in Linux?

How about just a good book on programming C++? Should cover most of what you want to know. Most C++ stuff is not platform specific.

The best C++ book that I know is free online here. If you want move on from there you could always buy Stroustrup's book, but I found it a little opaque. If you really want to move to the next stage read "The C++ Standard Library" by Josutti.

I thought C++ (or at least, C) was supposed to portable

C != C++, so comments that C is supposed to be portable, and therefore C++ being supposed to be portable are just silly. Anyway, C++ is portable, but it depends on how you write it. First off, if you use Microsoft specific stuff (eg #include , Win32API etc), of course it won't work. On the other hand, you might want to be aware that g++ does not support as much of the STL (Standard Template Library, read Josutti for details) as the Microsoft compiler. This may come as a surprise, but the Microsoft C++ compilers have consistently been the best at complying with the standards.

Anyway, I'd stick with VS.Net. It is actually an excellent C++ compiler, probably better than g++. You do need to understand how to use it though.

Re:Programming in C++ on Linux

[Anonymous Brave Guy]

FWIW, while the old <iostream.h> header was never standardised, AFAIK it always introduced the identifiers into the global namespace. That was one of the big problems, and one of the reasons for moving to the standardised <iostream> version.

Re:Programming in C++ on Linux

[spectecjr]

What he was takling about there is, IMO, irrelevant. It's clear that he has interest in programming on Linux from his other questions, so posting advice on a non-portable solution for anything is poor council unless there is no reasonable alternative.

In other words, the fact that he's complaining loudly about something, and then gets corrected about that thing he's complaining loudly about means nothing to you?

Of course not. It doesn't matter how misguided the reasoning, if you can push Linux on someone, do it, right?

Re:Programming in C++ on Linux

[Couldn'tCareLess]

Yuck! Just checked and you're quite right. Thanks for the heads-up :-)

Re:Programming in C++ on Linux

[EvanED]

No, it means something. See the bit about 'no erasonable alternatives.' In actuality, there are two reasonable alternatives. One is to run the project without debugging (see a couple posts up the tree a bit), and one is to use a cross platform means such as adding a cin.ignore at the end. If the alternative was to do an incantation while dancing naked around the Dietel book, sure, the suggestion about adding system("pause") would be a worthwhile one to make. However, since you gain very little by this method over one of the two I mentioned, and lose a significant benefit, I don't think it's appropriate.

I'm also not entirely sure how I'm "pusing" Linux by suggesting that he write code that will work on an OS it's clear there's a good chance he'll be using... Sure, if the poster had said nothing about Linux, I could see it, but not ni this instance.

Re:Programming in C++ on Linux

[fredrik70]

If you work as a teacher and have been given the VC++ editor to use as the IDE of choice I suggest you relly should spsend a few days/weeks getting to terms with it *before* classes starts. VC++ is nothing special in ways of an IDE, not better/worse than any other I've seen. Just sounds like bad planning to me of the teacher.

Re:OS X?

[mark-t]

Linux actually has a larger market share.

Re:OS X?

[Anonymous Coward]

No. No it wouldn't.

OS-X has the market share of Linux with the cost of Windows. If you want a Server, Linux is a better option. If you want a desktop, Windows generally wins out. Why the hell would it be smarter to "move apps to OS X"?

Re:Stupid question

[Anonymous Coward]

you, sir, are a moron.

My Java Programs Port Really Nice

[Apoptosis66]

Just moved J2EE webapp from windows to linux. Really nothing to it ;)

Apoptosis

Re:My Java Programs Port Really Nice

[Jessta]

I suppose it ran as slow and resource intensive as it did on windows?

Re:My Java Programs Port Really Nice

[Simon Lyngshede]

Well you didn't really port it did you. Your Java app still runs on one platform, the JVM.

Re:OS X?

[Stevyn]

Yeah, but aren't most computers running Linux backend servers? In terms of desktop users that need program X, I'd imagine there are more Mac users than Linux users.

A nice idea, but..

[gayak]

I'm not that surprised IBM releases something like this, and looking at the documents, they seem well written. Yet they only seem to scratch the surface, and help porting the "background" part of the program. Porting the GUI will be an ultimate challenge anyway, there's no easy to way to port Win32-calls to X. And even the actual program will take a lot more than just what's told in these 2 parts. How many are they going to release, 2^n ? Somehow seems more like a marketing tool instead of real usage. Obviously someone from /. was going to post this article here, and the document has done it's publicity stunt. Offtopic, first article was released in June 2004. If it takes 8 months to write a short addition to it, how long would it take to actually port something?-) And will "part 3" in 8 months bring again new headlines to /. by some moderator hoping for Microsoft's death? - Yak

Re:A nice idea, but..

[Anonymous Coward]

The easiest way to port Win32 GUIs is using Wine. Also, if one was going down this route one might also question the logic of going to the trouble of porting the file/mmap/synchronisation functions away from Win32.

Re:A nice idea, but..

[Anonymous Coward]

they seem well written

But not everything is as it seems.
The mmap example is particularly egregious (the use of the LPSTR cast is clearly clueless, as is the utter lack of knowledge of how to handle pointers and declarations (witness, *token = malloc()))

kill immediately followed by wait WNOHANG is cheerfully clueless as much as the description going along with it.

Combined with the poor language skills (both computer and English) and rather ponderous coverage I think there are better things to spend your time on.

But...

[Duncan3]

What's funny is that all the "Linux" code will compile fine on Windows with Services for UNIX installed correctly.

Windows and OS X will already compile and run 99% of all Open Source code anyone cares about.

Re:But...

[Anonymous Coward]

That's because most programs for Linux are written with portability in mind, including the libraries. That's why the Linux code compile fine on other platforms, including Win32, and not always the other way around.

Re:But...

[Anonymous Brave Guy]

That's because most programs for Linux are written with portability in mind, including the libraries.

Even the Linux kernel itself? I've never looked, so this is a genuine question, but a lot of people around here used to complain about the number of GCC-specific extensions the source code used.

Good For Porting Example Code

[Anonymous Coward]

While well meaning, the articles are only really useful for porting example code.

In reality, any large codebase will interact with APIs that don't have any mapping to Linux APIs, such as GUI components, services, and the registry. I can't think how these articles would be useful without wrappers for the above types of functions, and anyone familiar enough with Linux and Win32 application developement to write these wrappers will already know the equivalent Linux functions for Win32 functions.

To make matters worse, the first article is riddled with typos.

Should be: Migrating an App the Worst Possible Way

[IrresponsibleUseOfFr]

Migrating a Win32 app the way they suggest is going to be painful and time consuming. In addition, there are numerous things that they don't mention, like associated performance costs: is creating a thread going to be more expensive or cheaper on Linux vs. Win32? Don't look to the article for the answer. It doesn't even mention the biggest parts like the graphics/windowing library.

Secondly, it is making a wild assumption that your win32 app is written in a that is conducive to a Unix/Linux process model. Namely that you spawn processes and use environment variables as opposed to having a message loop and handlers (the way most windows apps are written).

Third, if it was so straight forward to port a Win32 app, why not just write a library that maps the windows calls onto the equivalent Linux calls instead of manually changing all your source?

Finally, why not look at a binary solution like Wine first and not touch your source at all?

This is the worst way migrate app. The source works and manually mucking with it like this is a good way to break it and introduce all sorts of bugs. Look for a binary solution like Wine. Then look to see if somebody implemented a Win32 on Linux library next to recompile (like Cygwin in reverse). Then, the last choice is to factor out your platform specific portions of your code and replace them with OS neutral calls. But beware of the performance of your app, it will probably take a hit. But, hacking apart your app like this makes me cringe.

Why Not Port Wine?!?

[vinn]

I don't get it. IBM seems to have some massive aversion to Wine. It seems to me the easiest thing they could do would be to port Wine to the Power architecture. It would consume a little time, but surely nothing as suggesting every application developer rewrite massive parts of their Win32 app. These articles basically suggest an app needs to be rewritten from scratch, which will immediately make any ISV laugh at Linux on Power. (Why would you bother porting a Win32 app to Power? Why not just keep using a cheap Intel box running Linux?)

Winelib was specifically designed to help with porting and you can do it tiny controlled steps:
1. Port from MSVC++ to the MinGW compiler and develop things like a Makefile.
2. Test the app.
3. Port the code from Windows to Linux (not as trivial as you'd think - there are problems with case sensitivity, etc.)
4. Test compiling.
5. Finish compiling using the custom Wine tools, such as winegcc (a wrapper around gcc that makes it behave like MinGW).
6. Test your Winelib app.
7. Begin ripping out chunks of Win32 specific code and replace them with native equivalents - Wine dialogs for KDE/GNOME ones.
8. Test

That's a valid and controlled migration path. Asking developers to basically rewrite massive chunks of code involving threading, memory management, and other such exciting things is a nightmare. Oh, and after rewriting you get to debug it all. Would you trust an enterprise app that just had it's whole threading model replaced?

The part I find amazing though, is just how much they haven't addressed. What do you do when your app relies on COM? What about Windows common controls? What about networking?

Anyway, it looks like IBM missed the ball - a few engineers porting Wine to Power could have solved many of their migration issues. It certainly would have solved every single one mentioned in these articles. Instead they want the software developers of the world to take on the task of rewriting their apps.

Re:Why Not Port Wine?!?

[bombshelter13]

Wine emulates the Windows API... it does not emulate the x86 instruction set.

So even if Wine was for some reason compiled to run on Power, you'd still have to add something to emulate an x86 chip.

Re:Why Not Port Wine?!?

[Soko]

I don't get it. IBM seems to have some massive aversion to Wine.

Stop thinking purely as a techie/develper for a second, will you? THINK for a second about the whole, big picture, not just implications for developers.

IBM is pushing Linux, has it's own line of pretty nice processors and just sold off it's PC division. And now they want native ports of applications to thier chosen OS and platform. Hmmmmm...

I'm no business genius by any stretch, but do you see any place for Wintel in the picture that's being painted?

Soko

Re:Why Not Port Wine?!?

[Anonymous Coward]

Because Wine is not an emulator... it depends on the CPU architecture. If you port the source it will run on any CPU version of Linux.
Have you really not discovered why IBM is interested in Linux ??
Linux run on ALL IBM HW...

Re:Why Not Port Wine?!?

[entrigant]

You missed the point. Unfortunately WINE has become known for being able to run windows executables on linux, when its true power lies in providing windows api's on linux that you can compile against. The point being you take your windows source code, compile it in linux, and link it to the wine libraries providing a win32 api in linux. If you do this, you don't need an x86 emulator because you have freshly compiled POWER code linked to WINE's libraries which provide a source compatible win32 API.

Of course the matter is oversimplified, and wine definately doesn't cover the entire win32 api yet. It can still provide an easier path than completely rewriting an app. I hope this clarifies things a bit about how wine can be used to not only port windows code to linux, but to linux on a different architecture as well.

Re:Why Not Port Wine?!?

[Anonymous Coward]

IBM still has not provided a reasonable alternative for x86 server hardware, which is why their x86 server division still is a very prominent part of their business (judging by the advertisments).

Why exactly would someone run Linux on Power? (Unless they are migrating from AIX or need a very large system) -- it seems that Linux/Power and Win32 are two entirely different markets.

Re:Why Not Port Wine?!?

[ciroknight]

I think one of the reasons IBM won't touch Wine is legality concerns. Sure, it's an open source re-engineered version of Win32, but there's no way to completely trust the source, to say that some of it didn't come directly from Windows. And Microsoft could very easily pull that trap on anyone, if they felt the need to.

Besides, why use WinAPI when you can natively port the code? It saves a boatload in interpretation time, and is better interoperable with other programs on the system (some/most of which won't speak WinAPI). Generally I would totally agree with you, but when it comes to Wine, even I'm skiddish about touching it.

Re:Why Not Port Wine?!?

[Anonymous Coward]

...and the real reason why they insist on the mantra "wine is not an emulator" is that wine is a portable win32 API compatibility library. It will work fine on PowerPC, you just have to recompile your windows app for a different processor architecture. Recompilation is not needed on x86 because the wine people have implemented a windows-compatible loader and linker, which are able to link windows binaries to the wine libraries, and even native windows libraries, when running on linux.

Re:Why Not Port Wine?!?

[gmhowell]

there's no way to completely trust the source, to say that some of it didn't come directly from Windows

I thought Darl McBride stopped posting on slashdot...

And Microsoft could very easily pull that trap on anyone, if they felt the need to.

MS doing anything like that would result in a MAD of large swaths of the computer business.

Re:Why Not Port Wine?!?

[KidSock]

... its true power lies in providing windows api's on linux that you can compile against.

As cool as that would be I seriously doubt people will get very far with this approach. There are too many libraries that WINE simply doesn't support without linking against MS' DLLs. There's structured storage, NDR / RPC, MAPI, workstation management and security network functions, etc, etc, etc. Sure they might have a few individual ops that have been cobbled together using libsmbclient or some OpenLDAP code but the API is not nearly as complete and robust as it needs to be to actually compile a stand alone binary that doesn't require emulation.

Re:Why Not Port Wine?!?

[imroy]

x86 emulation is only needed if you want to run the original EXE file. If you have the source code, then you can use libwine to compile your windows source on Unix platforms. It then doesn't matter what architecture you're on, except perhaps for endian differences.

Re:Why Not Port Wine?!?

[Anonymous Coward]

Go away and come back when you have a clue. Find out what winelib is.

Re:Why Not Port Wine?!?

[IamTheRealMike]

Sure the motivation is obvious, that doesn't change the fact that it's a dumb idea and isn't going to happen. Even when you factor Wine into the equation which makes porting for most apps actually economically feasable, you still have fun things like MFC, ATL, Visual Studio dependent build systems and so on. Such basic articles are a waste of time: any developer actually interested in doing a port could have found this information out in a few hours of research, and avoided all the mistakes in this article.

Re:Why Not Port Wine?!?

[IamTheRealMike]

Yes, yes, legality concerns. This is what IBM always say, though they never bother to clarify exactly what their concerns are.

It's getting very boring seeing IBM publish un-ending reams of information that totally ignore the realities of the Windows software market. If you want to see the sort of things porters are up against go look at the recently open sourced Open Workbench, a free alternative to MS Project. Look at the source. See how dependent it is on Win32, MFC and COM, even though parts are even written in Java!

IBM constantly spread this sort of FUD about Wine, and it's sad to see a company that supports Linux on the server side so heavily be so counter-productive on the client side. IMHO either they should clarify exactly what they mean so an open and educated debate can occur, or they should shut up. If they don't they're no better than SCO.

As to code stealing - there is a CVS repository dating back many years (nearly 80,000 changesets), and one man has maintained it pretty much since the beginning. There's no evidence of Microsoft submitting their own code anonymously, so claiming it might have happened is like claiming Elvis might be living on the moon: not grounded in the real world. Would entrapment like that even be legal itself?

To be honest I think a far more likely story is that some guy high up in the IBM Linux heirarchy tried Wine in 1998, couldn't make it work, decided it was TEH SUCK and has been carrying his prejudices ever since. It would not be the first time I've seen that happen. Of course, the hundreds of thousands of people that use it every day would disagree but hey ... that sort of thing never stopped stupid irrational biases before.

Re:Why Not Port Wine?!?

[sekbeep]

It is my understanding that WINE reimplements the Windows system calls in Linux, not so much the Windows API. Subsequently, I doubt it will ever be 100% compatible with the Windows environment -- although very close.
Personally, I would rather reengineer the application in wxWidgets, Qt or some other cross-platform GUI API, particularly for mission critical applications.

Re:Why Not Port Wine?!?

[entrigant]

Yes, and I agree 100%. However, with the greater context in mind, if IBM would throw some of its resources behind WINE and a POWER port of it then things might improve faster than they are. I think it'd be awesome if WINE finally reached a level of compatibility that allowed almost any windows program to be executed or compiled on other platforms. I doubt it will happen, but one can dream :).

Re:Why Not Port Wine?!?

[vinn]

Stop thinking purely as a techie/develper for a second, will you? THINK for a second about the whole, big picture, not just implications for developers.

IBM is pushing Linux, has it's own line of pretty nice processors and just sold off it's PC division. And now they want native ports of applications to thier chosen OS and platform. Hmmmmm...

That was thinking wihtout techie hat on. They're basically saying that the way to get an app on Power is to rewrite it from scratch. IBM will save the first few hours of frustration by showing people how to get started. The idea of that scares the hell out of any ISV and it's sort of a tactic of last resort.

If I was an ISV with an app that could be ported to an OS with second-tier priority on an architecture that has almost neglible marketshare, I doubt I'd do it. The payoff just isn't there.

Re:Why Not Port Wine?!?

[Anonymous Coward]

This is pure bullshit. Wine has a perfectly adequate structured storage implementation, NDR / RPC is partially implemented which is good enough for most apps and MAPI as well. Can you give any examples of programs that use workstation management / network security functions other than the Windows Computer Management program? I sure can't.

OpenLDAP and libsmbclient are not used anywhere in the Wine source, so I don't where you got that crap from.

Wine is perfectly robust enough to run large apps like Microsoft Office and Adobe Photoshop. However, you cannot create a stand alone binary (i.e. without the wineserver) unless you eliminate every last Win32 function from your code. Why? Because if you want Win32 semantics like inter-process file locking and synchronization primitives then you need a supervisor process to keep track of these. They can't be handled by the OS.

Re:Why Not Port Wine?!?

[IamTheRealMike]

We provide an NDR/RPC/DCOM implementation, MAPI is most often used for "please open the users mail app with this To address" which is trivial to implement and the rest you mentioned are hardly used by any apps at all. What kind of program needs "workstation management"?

Re:Why Not Port Wine?!?

[Anonymous Coward]

IBM seems to have some massive aversion to Wine.

mmm, port wine cheese...

Re:Why Not Port Wine?!?

[Rob Y.]

>There are too many libraries that WINE simply doesn't support without linking against MS' DLLs...

True enough, but remember this article was directed at people trying to port their own code from Win32 to Linux. WINE should at least provide a good starting point. They don't *have* to use MS's DLL's.

But the real reason IBM doesn't deal with porting GUI-based code is that they're not interested in desktop Linux. They're talking about porting command-line based code only.

And the previous poster's point about buying a cheap X86 box rather than run a POWER-based Linux desktop misses the real value of a POWER WINE port. The ability to port WIN32 code to MacOS. I've had to resort to running my WIN32 code on Linux under WINE and accessing it via X-windows from OS/X - which, believe it or not, works fairly well. Then again, I've avoided using MFC or any MS DLL's.

Re:Why Not Port Wine?!?

[fm6]

You don't emulate an API, you implement it. Hence, "WINE Is Not an Emulator."

There actually is a PowerPC port of WINE. For obvious reasons, it only offers source compatibility with Windows.

Re:Why Not Port Wine?!?

[KidSock]

So what library are you using for structured storage? Last I checked creating and writing into a new stream was very poorly supported. That's great!

You do RPC?! Wow, so I can take some custom IDL, compile that to get a proxy, create a named pipe transport, and call server code using signing and sealing with the Kerberos session key? That's fabulous!

As for examples how about:

Retrieve the group membership information for a user?

Create Kerberos principals that threads can then impersonate?

Schedule a job on a remote server?

Enumerate open files on a server so an application can break files locked by a certain user?

It'd be nice....

[yuriismaster]

But realize one thing: sometimes those libraries make your life SOOOO much easier to program. When you're writing a GUI (even in Java), certain libraries make the process much more simplistic. Window Handlers, Toolkits, and other toys exist to make the coders life much easier.

If we didn't make these libraries, we'd all still be coding our temperature converter GUI in assembly and it'd be ugly and broken and would take 1000 times as long to code.

I dont claim to know much about the differences between Linux and Windows, but my guess is that when you build an app for windows, using windows' libraries makes the whole thing snap together well. (which actually presents a security hole, but if those libraries were written well...)

If you want to make code portable, you sometimes have to give up the tricks provided by the operating system. That is why, I suppose, that standards-based applications are 'better' because any app written to that standard can be used in any other app written to that standard. Windows may accept those standards, but you can bet your ass they aren't going to translate THEIR standards into OUR standards. </aimless rant>

Re:It'd be nice....

[starfishsystems]

This is also why so many applications are now designed for the web. In effect, it takes care of the portability layer. For the cases where you really only want something like a "temperature converter GUI" it seems like an ideal solution.

It's such a compelling solution for these cases that I think the industry tends to want to shoehorn all applications into this form. And I find nothing more pathetic than the misapplication of a perfectly good idea to the wrong problem.

Re:OS X?

[Anonymous Coward]

Wouldn't it be smarter if you Mac Zealots didn't troll every single discussion? You guys are the worst advertising imaginable.

Use GTK in the first place

[Anonymous Coward]

Just use a cross-platform GUI library in the first place.

Design for Portability

[RotateLeftByte]

IMHO, the ease or difficulty in porting an application really begins at the design stage. If you design for a standard(GUI apps excepted) like POSIX then porting is much easier. Granted that many things on Windows become more difficult but usually not impossible. I have written many apps over the years for diverse platforms and usualy only have to rewrite one module that contains the platform specific code. For example, calling SYS$ & LIB$ functions on OpenVMS. However, whe it comes to the GUI then things get a lot more indeterminate which it where the auhor is coming from. There are some tradeoffs to be done here. Either:- 1) Design for performance 2) Design for portability If you take the former and for example, design the GUI using Visual Studio tools then you will get something that will work and perform well on Windows but moving to other platforms is nigh on impossible. So, where do we go in the future? Well Microsoft would want you to go down the .NET route but they ave singularly failed to release it for other platforms. Mono is there but it does not have the cachet of Mictosoft support which is needed in many companies. Java is pretty portable and there are lots of skill out there to continue development. There are other niche languages & environments that are portable but these have their roots in OSS and sometimes trying to itroduce something like Python into a totally Microsoft shop is like trying to make the Red Sea part. {I know as I tried this and was regarded as a subversive influence.} The overall situation is cloudy but there are breaks of sunlight where Portability is a prime consideration and the company can reap the benefits in a MultiPlatform world.

Re:Design for Portability

[Malc]

In my experience, designing for portability is expensive and simply not worth it just on the off-chance it might be needed in the future. C and C++ only provide the most basic of cross-platform portability, and only if you don't want to do a GUI or any serious I/O beyond simple file operations. I don't think libraries like Qt provide a satisfactory end-user experience from a GUI perspective either (it just doesn't feel right under Windows). Separation of concerns is always a good idea, and simple things like minimising business logic in UI classes will go a long way towards allowing switching out the UI code later. But let's not pretend, it will always be a lot of work.

Re:Design for Portability

[m50d]

Java is incredibly slow for GUI though. People will say I'm trolling but it's a fact. I'd say try WxWidgets. It's actually native on win32 now so good performance, looks reasonably good, and like Qt includes a few extras like some networking stuff.

Now with paragraphs!

[dejavudeux]

Sorry, I got lazy and decided for the first time not to preview. That will teach me.

>Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

This is a real annoyance for me, too. I've searched through the dialogs a little and didn't find it. (Although if I program with the IDE a little more I would just Google for the option.)

Incidentally, another quick hack you can use in this situation is to add a std::cin.getline() at the end of the program. However, I feel bad saying that because you'll be far more productive in the long run if you just look it up.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Stupid question

[cyfer2000]

and why did we port those mainframe programs to Win32 10 years ago?

KEEP THE CUSTOMER SATISFIED, that sounds good.

Re:Stupid question

[mirko]

Because some could not wait 10 years to get the labour done a cheaper way.

Re:OS X?

[Anonymous Coward]

Consider the source. This information is coming from IBM, who have been been proponents of Linux. While IBM may make the G5 processor in the new line of Macs, they also make the iSeries, pSeries, and zSeries line of servers, all of which use POWER architecture and are capable of running Linux. I didn't RTFA, but I'm pretty sure what IBM is talking about here is companies moving their custom code off of Windows based servers and onto one of their servers running Linux. They aren't talking about porting your favorite desktop app.

Re:OS X?

[Anonymous Coward]

That's what I was wondering. Linux users will demand that you release your software for free. Apple users on the other hand are accustomed to paying 3 or 4 times the value of the products they buy.

Linus Torvalds vs Andy Tanenbaum

[Anonymous Coward]

This article reminds me of the famous flaming between MINIX author and Torvalds. And I quote Linus:

"Portability is for people who cannot write new programs"
-me, right now (with tongue in cheek)

http://groups-beta.google.com/group/comp.os.mini x/ browse_frm/thread/c25870d7a41696d2

Where did this come from?

[bigberk]

And what the hell is POWER and pSeries? I'm pretty much going to ignore this article. I've been writing win32 software for quite some time and am seriously fed up with that platform. Rather than tweaking my software so that it works with Wine I'm much more interested in rewriting the GUI from scratch using wxWidgets. With a wx based application, you can then compile it into native Linux (GTK+), native win32, or even Mac OS X apps. To me that seems like the most promising route. I've used some wx based applications like Audacity and they're just amazing, really look like they belong on each target platform.

Re:Where did this come from?

[Anonymous Coward]

POWER is IBM's line of 64-bit RISC processors. The G5 is based on POWER.

pSeries is what IBM decided to rebrand the RS/6000 as a few years ago. They generally run AIX, but can also run Linux.

Re:Where did this come from?

[d1v1d3byz3r0]

POWER = the PowerPC architecture
pSeries = the line of IBM servers that use the PowerPC architecture

Re:Where did this come from?

[pvanheus]

wxWindows will only fix your GUI. Have you actually read the article? As others have noted, it doesn't deal with GUI apps, but rather with the underlying operating system differences (such as fork() vs. CreateProcess()). Using wxWindows ain't gonna do anything to fix that!

Re:Where did this come from?

[Anonymous Coward]

wxWidgets does a lot more than just GUI. It also includes threading (including mutexes and semaphores), collections and data structures, file I/O, networking...pretty much everything you need to write a portable application. It's a nice library.

Re:Where did this come from?

[sekbeep]

Windows = GUI = 99%

Re:Where did this come from?

[dustmite]

Firstly, simple things like spawning threads/processes are typically the least of your worries when porting a Win32/MFC app, because these are small simple APIs with no or little dependencies and easy to abstract. It usually takes a few hours to give these wrappers and add a few simple preprocessor directives (e.g. #ifdef WIN32) to compile the right implementation on the right platform. GUI stuff is usually the big pain.

Secondly: I wonder what all these classes are then: wxCriticalSection, wxThread, wxMutex, etc. wxWidgets covers a lot of stuff, not just UI stuff. We use it for our apps, and it really is a great solution, not only is it a well-designed easy to use API, but has "native look and feel" on each platform.

Re:Where did this come from?

[Anonymous Coward]

Thank you for offering an opinion about something you, quite obviously, know nothing about.

Re:Where did this come from?

[Paralizer]

For GUI, you may also want to look into Qt (http://www.trolltech.com/). It's a free library, and can create windows for X, Windows, and the Mac. Code-wise, it seemed to me to be a short learning curve, I learned enough to write a few simple GUI applications in just a couple weeks. My only complaint is that the Windows version doesn't look quite right, some of the widgets are a little different from the native set.

Re:Where did this come from?

[bjpowers39]

Actually, both the pSeries and the iSeries use the PowerPC processor. Even the zSeries (essentially mainframes) use the PowerPC processors to control IO channels. If you are using an IBM server and you have anything other than the xServers (intel line) you have PowerPC in your rack.

Re:Stupid question

[0x461FAB0BD7D2]

Actually, it's neither. The article describes the use of a portability layer abstracting the APIs.

Re:Should be: Migrating an App the Worst Possible

[Anonymous Coward]

> it is making a wild assumption that your win32 app is written in a that is conducive to a Unix/Linux process model

Just read it in reverse and you can now easily port Linux apps to Windows!

good point, why not separate GUI from core?

[thrad]

In my opinion, GUI is not all that important part in the software. Yet, nowdays its really impossible to make portable (unless you use java for gui, which hardy a good choice). So why not logically separate GUI from app core?

Good example of that is mldonkey. Their server-client does not come with any gui by default, but it just provides an network interface (tcp) for it. So there are thosounds of GUIs now for all the platforms, and they work great.

Not to mention technologies like j2ee :)

Re:good point, why not separate GUI from core?

[Anonymous Coward]

Well that approach might work for midonkey (which has very limited user interaction), but try it with a word processor.

Many Windows apps are basically entirely "front-end" code -- think VB database apps and so on. They are already seperated, but that doesn't make a rewrite cheap or easy.

Visual C++ sucks...

[katharsis83]

I'd recommend using gcc/g++ to learn the languages. Using Visual C++ lets you make certain mistakes without punishing you for them; gcc/g++ WILL let you know when you haven't initalized a variable; Visual C++ - most of the time - will assume it's been set to zero and let you work from there. It makes bad habits easier to form.

Also, code written in gcc/g++ is pretty much guranteed to work in VC++; the reverse is not always true.

Re:Visual C++ sucks...

[hobo2k]

Whatever compiler you use, it is a good idea to learn which option adjusts the warning level and set it to the max.

I don't recall which warning level is needed for uninitialized variables, but level 4 definately will catch it.

Re:OS X?

[bigberk]

Why the hell would it be smarter to "move apps to OS X"?

Because unlike Linux, customers will actually pay for the OS X software, funding your time/effort and making it worthwhile for you to develop even more good software for that platform. Also I suspect there are more serious Mac users out there. Think of all the multimedia people and Engineers who use Macs because of the power. (I'm not a Mac nut, btw)

Re:Stupid question

[Anonymous Coward]

What I was getting at is if it was a porting or the application ran in a virtual OS.

The article (which you likely haven't bothered to read) specifically mentions porting and talks of changes to source code. So if you're wondering if it's talking about porting or something else, I guess you already have your answer.

Of course, ask a stupid question and you'll get the answers you have. Being female is no excuse for not first trying to comprehend the material.

Yes, here is howto:

[Anonymous Coward]

http://developer.apple.com/documentation/Porting/C onceptual/win32porting/win32porting.html

WINE compile against

[Anonymous Coward]

I am not that familiar with WINE, but isn't there a package to install on Windows that integrates nicely with VisualStudio where you can simply check to see if your application will also work on Linux under WINE? That way, it would make developers conscious of whether they were using libraries that would make it incompatible with WINE. Is this already possible?

Re:Should be: Migrating an App the Worst Possible

[GbrDead]

The author might have meant: "Porting Windows programmers to POSIX" :-)

How to port CLI programs to OS 9

[hunterx11]

#include

SIOUX basically just creates a simple MacOS 9 app with a window that acts as a console. Just add that, and standard I/O will behave almost exactly like it does on a *nix machine.

Re:LOL

[secretsquirel]

I for one thought that was fucking hillarious.

binary semaphore and mutex is not the same !!!!

[kemelma]

The second article "Migrate Win32 C/C++ application to Linux on POWER, Part 2: Mutexes" worth nothing, since you can't use semaphore (SysV semaphore) instead of mutex. It seems that the author do not know/understand the very basic difference between binary semaphore and mutex - and the difference is that there is no owner for semaphore and there is always owner for mutex. This means that once mutex taken/locked, only the thread/process which holds the lock able to release the lock, and this is not true for binary semaphore ... since it has no owner and any process/thread can unlock it.. I can even say that the example demonstrated in second article is dangerous.. Since it leads to misunderstanding and production of wrong/problematic code. At the moment there is no standard way to map Wind0ze inter-process mutex to Linux, this could probably be done using FUTEX API, but it is still changing, not standard and not well documented. Regards, Mike

Re:binary semaphore and mutex is not the same !!!!

[IamTheRealMike]

There are lots more mistakes like that, they leak handles in the Win32 examples and stuff. I wasn't impressed with this article when it was first posted to OSNews and I'm not impressed with it now. It's about the worst way you can port Windows software (unless you feel like scrapping your mature and tested codebase, that is).

If you do want to have a Windows program ported to Linux you could try Wine, or you could hire us to do it for you (CodeWeavers don't just make products, we also do commercial consulting and compatibility work).

Re:binary semaphore and mutex is not the same !!!!

[kemelma]

yeah right .. and how'd you treat WaitForMultipleObjects ? as far as i can see Wine does not solve this ... at least i can't see how can you solve this effectively without kernel intervention ...

Re:binary semaphore and mutex is not the same !!!!

[IamTheRealMike]

Ask and ye shall receive.

Or what, did you really think we could run apps like Office and iTunes without such a basic sync primitive?

Re:binary semaphore and mutex is not the same !!!!

[aulendil]

Where did the author compare semaphores and mutexes? I may be blind, but the only place I can even see semaphores mentioned is in pointer to the next part of the series.

Now, I assume you know what your talking about regarding Windows mutexes, I won't say anything about that, but read - and understand - TFA before you go out and insult the author for his lack of understanding. It might very well be the author is stupid/dumb/whatever, but not on the gorunds you mentioned.

Re:binary semaphore and mutex is not the same !!!!

[kemelma]

before rushing to post you comments i warmly recommed you to complete your reading of the mentioned article

and in particular, please pay your attention to

Listing 17. Equivalent Linux sample code Process 1

and after that i might consider to discuss the issue with you.

-M

Re:binary semaphore and mutex is not the same !!!!

[aulendil]

and after that i might consider to discuss the issue with you.

Why? I obviously am blind...

Re:binary semaphore and mutex is not the same !!!!

[fitten]

Well... they also left out CriticalSections from Win32, which are really fast mutexes for threaded code (CriticalSections aren't shared across process boundaries but all the threads in a process can use them).

Re:binary semaphore and mutex is not the same !!!!

[Duhavid]

Since Critial Sections are basically the same idea as mutexes, I dont seem much harm in leaving them out. Unless the reader of the article doesnt understand that they are implementing the same basic idea, in which case, should that reader be doing this work?

Oh, one other difference between Critical Sections and Mutexes ( win32, anyway... ). With a Mutex, you can specify a timeout ( wait n milliseconds for the lock, and return with an indicator "did I get the mutex or did I time out?" ). Critical Section have no such thing, you wait forever ( or you do the "try" variant, and implement your own "spin" for it ( bad idea? I think so ) ).

Anyone else out there either have a bad feeling ( or actual experience ) about Critical Sections ( vice Mutexes )? Every app I run into with Critical Sections leaves me wondering ( based on unprovable experience ) if there isnt a flaw in there somewhere. My understanding is that CS's are strict UserLand programming, no kernel code involved, so, how did they do that reliably?

Re:binary semaphore and mutex is not the same !!!!

[fitten]

While mutexes and CriticalSections are basically the same thing, CriticalSections are lots faster than mutexes (which require kernel context switches to manipulate).

I looked at them pretty deeply a few years ago and found no problems. While you may not be able to timeout on it, per se, you can do a loop with a microsleep in it to poll it if you really need that functionality (sleep for a millisecond in the loop), but as you say, this is not a good solution and you should use something else if you expect something to be locked forever and you'll need to timeout while waiting for it. If you have something that is locking a CriticalSection for long periods of time, then your problem is either doing something wierd (that long time of locking is going to be a serious bottleneck) or you are breaking the reason for using CriticalSections (lightweight atomic locking within a process where you know that a lock won't be held for long). Threads/processes that lock mutexes for longs periods of time are usually pathological in my experience.

If you've had problems with programs that used CriticalSections in the past, I imagine that there was something else going on.

Things I've implemented with CriticalSections: threadsafe queues, stacks, linked lists, a weird sort of priority double queue list thing (I'd have to describe the problem we were trying to solve to accurrately describe this thing), producer/consumer task queues, standard global data that required locking, and all sorts of things. I've also implemented these things with mutexes and binary semaphores on both Windows and various Un*xes and Un*x-alikes. I don't hesitate to use CriticalSections where they are a good fit.

Re:binary semaphore and mutex is not the same !!!!

[Duhavid]

"you can do a loop with a microsleep in it to poll it if you really need that functionality"

Yup, you can. But I hate to see the CPU go to waste like that polling, when a mutex does not incur that overhead.

"If you have something that is locking a CriticalSection for long periods of time, then your problem is either doing something wierd (that long time of locking is going to be a serious bottleneck)"

Nope, not the problem. When I have my way about it, locks are lock, do the minimal needed, unlock. I had to rewrite some code once upon a time that a coworker of mine had written. Lock, wash up, drive to the 7/11, check the evening paper, paint the dog, etc, etc, then unlock. ( And I think therein lies the trouble, see, others were allowed to write MT code when were inexperienced ( why? dont ask me... :-), then I inherited their mess and had to make it right.

I have never been able to prove a problem with Critical Sections, but the code I have written with Mutexes pretty much always ( after some debugging, of course ) does what I expect. I keep inheriting Critical Section implementations, and having all the usual MT problems. Perhaps *that* is the problem. :-) But I keep on wondering if there is some edge condition that explains why Mutexes in kernel code are "more correct" ( for that edge condition ) than userland. Course, my last MT project was done with Critical Sections ( so as not to upset "those who are 'in'" ), and it seems to be working just fine, now that I think on it more. Yup, it is a bias.

Thanks!

Re:OS X?

[Anonymous Coward]

Wouldn't it be smarter if you Mac Zealots didn't troll every single discussion? You guys are the worst advertising imaginable.

Thank you. I've been planning to purchase an iBook in the near future and run mainly Gentoo on it. I was really excited about the Mac mini as a cheap(!) alternative to a mini-ITX PC to run a server or MythTV. After seeing most of the comments on the "How to Install Debian on Mac Mini" article (to the effect of: 'MacOS rules. Linux is dumb. You're not allowed to run Linux on a Mac, because it's dumb.'), I'm actually reconsidering. I don't want to be associated with that culture.

Please guys, do Apple a favor and SHUT THE FUCK UP.

Re:Stupid question

[Mercedes308]

Being female is no excuse for not first trying to comprehend the material The only person to imply that is you.

Re:Should be: Migrating an App the Worst Possible

[cduffy]

Third, if it was so straight forward to port a Win32 app, why not just write a library that maps the windows calls onto the equivalent Linux calls instead of manually changing all your source?

What do you think WINE is? It's exactly that library, plus a loader and relinker and other related tools. You certainly can compile win32 programs against it for porting purposes.

WINE is a binary solution only in the worst case -- if the port is being done by someone with the source, they can recompile against winelib and so be portable to non-x86 targets.

No, Mongo, stop! Never kill a customer!

[Anonymous Coward]

It reminds me Monty Python's restaurant sketch.

Coders sometimes go mmmmmad from customer's requirements.

Programmer loves to make everything perfect, nice and neat and in a moment, when everything goes smoothly, the customer comes with their little silly unimportant requirements!!

Oh, the war wound, aaarrrghhh!

Re:OS X?

[secretsquirel]

My my, have we learned nothing from tv commercials or George Bush? come on now say it with me, repitition, repitition, repitition. Yes, it is brainwashing, and yes, it works.

Moron, should learn English

[Anonymous Coward]

In addition to the farcical nature of an article like this (this 1:1 API mapping doesn't begin to get into the nuances in actually going over from a Win32 model (which has things like SEH, IOCP, no signals) to POSIX (which has signals, totally different process and thread model, shared anonymous mappings and forking) many of their examples are written carelessly with no consistent style (which adds to the professionalism), but are outright wrong.

For example, the kill followed by an immediate WNOHANG wait is falacious. There is no guarantee that the thread will be processed by the time the waitpid is called. This is a laughable way of handling child processes, and I don't see how it helps.. I would still have to instruct a Win32 programmer on process hierarchy and SIGCLD semantics.

Next, look at that memory mapping example. They have a mem_shared_struct (I won't even get started on their weird naming conventions), and they define a pointer to one called token. Then they go on to do things like:
*token = malloc and
(*token)->hFileMapping.
What the fuck is that? This "senior programmer" clearly doesn't have a clue when it comes to C. I ask these types of pointer questions as prescreening to entry level candidates.. jeez.

There are probably more egregious errors, but life is too short.

Shameless Java Plug

[boingyzain]

Here's how to migrate applications between operating systems... Use Java ;)

not much help

[savuporo]

Well, considering that most of the apps i've written under MSVC utilize either MFC ( yea i know its 'orrible but gets the job done ), ATL and COM, with very little direct code interfacing to Win32 layer, this doesnt help much.
For similar app under linux its easier to start from a scratch and just lift the parts of the code that are separate classes/libs with no or little platform-specific dependencies.

Re:OS X?

[Rakishi]

It's been basically shown that Macs are not more powerful than PCs for multimedia (cost wise, high-high end PCs are faster asfaik but the cost is insane). Macs aren't slower either so there is no incentive to switch to PCs, but there is also no incentive to switch to Macs (power wise I mean). In other words: they used Macs in the past and they continue to use Macs since it doesn't really matter.

Direct X is not much of a problem.

[Anonymous Coward]

http://sourceforge.net/projects/dxglwrap/

Just expand dxglwrap to incude the functions you use. This is Direct X to opengl. Note there are performance problems ie Slower.

The trick is having a platform independant lib. Openoffice and Mozilla depend on a corelib system.

Note porting from Linux to Mac or Amiga is not a problem. It is just porting from windows due to no standard compad because they did not want it.

Only direct hardware access software not access by a standard lib have problems. Ie direct device access. This is they way it sould be.

Re:Direct X is not much of a problem.

[Anonymous Coward]

Note porting from Linux to Mac or Amiga is not a problem. It is just porting from windows due to no standard compad because they did not want it.

Yeah, that's OBVIOUSLY why OpenOffice.org STILL doesn't have a native Mac port. Obviously porting from Linux to Mac is "not a problem". It's just... uh... problematic.

Re:Direct X is not much of a problem.

[Xabraxas]

neooffice

zero length arrays

[Joseph_Daniel_Zukige]

What, you don't want to write a macro that converts all the zero length arrays to four^H^H^H^Hone length empty arrays, and modify the allocation to remember that zero means one?

Re:OS X?

[rjshields]

Firstly, Linux users pay for software. Secondly, serious people use Linux. Thirdly, that macs are more powerful is an illusion.

Re:Should be: Migrating an App the Worst Possible

[owlstead]

There are several assumptions that you make that are not that []
- Associated performance costs; for most (business related) applications, you don't give a darn. You want it well designed, but the difference in creating a thread? I don't think that would matter much (linux is very probably faster anyway).
- About having a message loop and handlers; it seems to me that this is about an application that is written from the GUI down. If you cannot seperate your core logic from your GUI, there comes a time where you will be hit *big time*, such as when you are going to port your application.
- As for the library that maps the windows calls to linux/posix ones: yes, that could be a good idea in some circumstances, but it might be much harder than you think. You will have an additional library to maintain, and if you expand your original program than you will probably have to expand the library within as well - in the end you'll have another wine.

Obviously if wine works, there might be little reason to bother, but Wine won't work always. A Win32 library for Linux IS wine, stop looking further. Sometimes you need to hack your app this way, for instance if you would want to make a Linux compatible library...not much fun to have a linux library implemented by a .dll.

strncmpi(...)

[Domini]

eek!

strcasecmp() ? not quite... (the 'n' still missing... what now?)

Re:strncmpi(...)

[unkaggregate]

strncasecmp()

Yes it does exist in glibc.
When I port code in fact I often add at the beginning of the source file:

#ifndef WIN32
#define strcmpi strcasecmp
#define strncmpi strncasecmp

So far it works well.

Re:strncmpi(...)

[johannesg]

strcasecmp() ? not quite... (the 'n' still missing... what now?)

While there is no universally agreed standard for this, you might want to look at strncasecmp().

Re:strncmpi(...)

[Domini]

Ah yes... could not remember so well... did much porting from Linux to win32 (native and Cygwin) at some point.

I remember not having a 'n' version to something like vnsprintf() or something... could not remember which it was though. Perhaps I eventually found it to be one of those underscore functions... -ponder- like _vnsprintf()
-shrug-

Also had some trouble with missing helper defines like:

S_ISDIR()

and some other low-level socket defines being either missing or different. (I did some funky tweaks to sockets like disabling the Nagel algorithm for realtime sockets...)

Re:strncmpi(...)

[Malc]

Win32: _stricmp, _wcsicmp, _mbsicmp (or _tcsicmp for those doing it properly)
or
_strnicmp, _wcsnicmp, _mbsnicmp (or _tcsnicmp for those doing it properly)

Orders of magnitude

[mangu]

Programs for Linux are supposed to be so portable, but many times they are just as dependent as their Windows brethren.

They may not be 100% portable, but they are, definitely, not *just as* dependent as Windows programs. Setting a symbolic link pointing to /usr/bin/local is somewhat easier than converting an application from DirectX to OpenGL or from MFC to Qt, for instance.

The problem I have with my iBook

[Joseph_Daniel_Zukige]

is that I found it was far too easy to do most of what I wanted without installing openBSD or Linux (Debian or whatever). So I kind of lost my motivation for heading that direction until I can afford to buy a new iBook (I have an old clamshell, which is serving my personal site, and, no, I have not tuned it for a slashdotting, so no urls.) and a couple of Mac Minis.

You gotta watch that trap if you do go with Apple hardware.

I18N - UTF-8 vs UTF-16

[KidSock]

One notibly important difference between Win32 and Linux is that the internal Unicode encoding is UTF-8 as opposed to UTF-16LE. This takes some getting used as it requires special consideration when working with text (e.g. when iterating over individual characters). I have prepared a document and a text.h header file [1] that could assist people with porting Win32 applications to Linux. Or at the very least it explains how to maintain I18N support as you migrate code.

[1] The header is part of a library but you can easily remove the library specific #defines.

Re:I18N - UTF-8 vs UTF-16

[Carewolf]

You need special consideration when using UTF-16 as well. Unless you are ignoring the auxiliary planes... UTF-8 is much safer in this regard, since any non-ASCII value will break if you treat it incorrectly, where as even large projects are completely misusing UTF-16 somehow thinking every point is an individual character.

Re:I18N - UTF-8 vs UTF-16

[Malc]

I think you're referring to surrogates. How common are they? Is the risk of encountering them low enough that it can be ignored on most projects? UCS-4/UTF-32 is the only safe thing to use, but hideous for both space and speed performance.

Any text strings that use variable byte characters are a pain in the arse to work with.

Re:I18N - UTF-8 vs UTF-16

[Malc]

Personally I've just moved TCHAR.H around. I worked on a cross platform product a few years ago. I wrote it for Win32, and somebody else handled a Mac OS version. I kept the UI, etc separated out. It wasn't until late in the project that we decided that the Win32 build would be Unicode instead of multi-byte. I had used the TCHAR.H defines throughout all of the common code which of course made this decision easy as Microsoft have done a good job with the I18N stuff. TCHAR.H copied over to the Mac just fine and there were no problems with the common code on that platform.

Call By Reference

[Anonymous Coward]

The (*token)->blah is an example of "Call By Reference" and when using C, that means passing a pointer to a variable rather than the variable itself and using (*foo) everywhere instead of foo.

The code snippets are difficult to understand because they are so severely snipped: we see "return" statements but we don't see any function declaration . With suitable function declarations it would make sense.

Consider for example:

int main()
{
char *x;

scanf( "%as", &x ); // call by reference
printf( "%s\n", x ); // call by value
free( x ); // cleanup
}

The argument about whether call by reference is good program design is too long and complex to even start on but since the original program was win32, good program design is probably way off the radar anyhow.

Re:Call By Reference

[Anonymous Coward]

The (*token)->blah is an example of "Call By Reference" and when using C, that means passing a pointer to a variable rather than the variable itself and using (*foo) everywhere instead of foo.

Hmm...
Assuming blah is a member of struct s, then
(*token)->blah
will only make sense if token is of type struct s**, which is not the case in their examples. To use the call by reference terminology: the value is a pointer to struct, so the "reference" must be passed as a pointer to pointer to struct.

However, they declare token simply as a pointer to the struct type, so the use is incorrect. I can imagine that the snippets came from a function where the argument type was double indirection, but like I said, I expect better editorial control.

On a side note, amongst most C language lawyers, the notion of calling anything "by reference" is frowned upon because it can "confuse" things with a concept that really doesn't exist in C. Everything in C is pass by value as everything in C simply has a value and there are no special case semantics (though there are array and function decomposition rules, but they are not specific to any particular context, function call or otherwise), and the whole convert to unsigned char* and print out sizeof for the representation applies to all values... C++ references are fundamentally different as they have totally different semantics: What normally would never be an l-value in C can be an l-value in C++, and it really changes a number of things at a fundamental level in the frontend of a compiler.

BTW, I am not arguing with you and this flame war has erupted on comp.lang.c numerous times so no reason to start it again, I know exactly what you're talking about. Personally I don't get terribly worked up by either interpretation, it depends on the student and his/her background. comp.lang.c is populated by compiler writers (yes, there are some amongst the assholes), and having developed C language processing tools I can see where the whole "there is no $@*!# thing as reference in C" camp gets their point of view.

My whole view of the need of well written standards and precise terminology (pedantry if you will) changed markedly after I got tasked writing a Visual Basic runtime (VB has no good documentation, nor does the Win32 API, when it comes to precision, ask the Wine folk about that). However I agree, for the student, it is helpful to draw analogies from other familiar languages in order hasten picking up unfamiliar concepts.

Re:OS X?

[Anonymous Coward]

Yes. They used Macs in the past and they know how much less Mac OS X needs maintenance than Windows in the long run. Macs save them time and money in getting the job done.

power

[Joseph_Daniel_Zukige]

Think of all the multimedia people and Engineers who use Macs because of the power.

I think there will be a lot of misunderstanding of your reference to power.

The power, for instance, to do stupid things like host your personal web site on your old 300MHz iBook while it is being used as the family computer is a concept that seems to slip right past some people.

I heard about some thing called GTK

[al912912]

The hardest part of porting to LINUX will be refactoring all of the GUI stuff.

Haven't you heard of it, I think it might help you in your problem.

Any way, if you are making GUIs in Linux, it's the best way to go.

On the other hand, why isn't everyone talking about mono & .NET, they can also become very useful when porting. ------------ al912912

Yes and no

[Moraelin]

Writing perfectly portable code is possible, but as they say "there ain't no such thing as a free meal." Let's take your DirectX vs OpenGL example, just as a random example, to illustrate the problems.

1. It costs extra time and money.

And it costs time and money to also _test_ it on the new platform. Otherwise you won't even know what functions don't exactly work the same. Or you won't even know that the widget sizes are different on the other platform, and the whole GUI is a disfunctional piece of junk with truncated texts and buttons falling completely out of the dialog box.

(Writing the code is not the alpha and the omega, as you undoubtedly already know. Testing and debugging can easily account for 10 times more time.)

The promised DirectX-vs-OpenGL example: Now _Direct3D_ is pretty much an equivalent of OpenGL. No, not the same function calls, but you can get the same results.

But DirectX offers a lot more than that. Direct3D is just a part of it. You also get networking, sound, etc. If you wanted to stay portable and _only_ use OpenGL, you'd have to write all those extra bits yourself. Which costs time and money.

2. Performance problems, here we come.

Of course, you could just use a wrapper that encapsulates, abstracts and emulates everything. Proper software engineering, right? The problem is: it costs performance.

DirectX-vs-OpenGL fits nicely here too: as fate would have it, Matrox already tried handling that via a wrapper. Back in the days of the G100 and G200, Matrox thought the're smart. No use writing two different 3D libraries that do the same, right? So they actually wrote their OpenGL implementation as a wrapper around DirectX.

The problem? Performance was abysmal. No, not just bad. It _killed_ 3D gaming. With Doom 2 and such being the "killer apps" of video gaming back then, Matrox lost gamer market share (and game developper mind share) with both hands. And who rose like a star? NVidia, who to this day still has the fastest OpenGL implementation.

Just in case you wonder why no games are written using one of those wrapper libraries, now you know why. Because noone wants to make a game that looks like classic ass (low polygon count) or gets single digit FPS. Or both.

3. Those pesky users.

There's one thing that all these emulation and one-lib-to-rule-them-all apologists just don't get: reusing existing skills is good.

When Joe Average gets a Windows app.. actually, screw Joe: when even _I_ get a Windows app, I expect it to look and behave exactly like every other Windows app. No, I don't want it to look like Swing, I don't want it to look like QT, and I sure don't want Mozilla's skinned idiocy, and I'm gonna puke if I have to use another idiotic GTK file dialog in _Windows_, etc. I want it to look and _act_ exactly like one thing: the Win32 widgets. Nothing else.

And if I were on a Mac, I'd expect it to look and feel like on a Mac. I would _not_ want an app that looks and acts like Windows (e.g., wants me to right-click) in the middle of an Aqua desktop.

It's possible to get it right, yes. See for example IBM's SWT widget set for Java. But it's also quite the norm to get it awfully wrong: witness Sun's Swing.

Re:Yes and no

[Anonymous Coward]

There's a few things you overlooked.

1. Most widget sets in Linux expect you to use box positioning. Using pixel positioning is asking for trouble in _any_ modern GUI anyway.

2. SDL. Truly, either you've never used Linux or you've lived in a cave for the past ten years to never have heard about it.

3. Writing complete software and then deciding you might want to port is asking for trouble. Wrappering around the problem and just pretending it didn't exist is even more so. The problem here is in something else than software or its environment.

So all are problems, but only when the goal is to get another product out there fast, just any product damnit. When designing and writing portable software none are but trivial issues, solved by sensible selection of the software components.

Re:Yes and no

[zootm]

2. SDL. Truly, either you've never used Linux or you've lived in a cave for the past ten years to never have heard about it.

I heard somewhere that the biggest problem with SDL is that it's designed to be simple, so a lot of more-advanced functionality simply isn't present. Is there any truth to that?

Re:Yes and no

[qray]

It's possible to get it right, yes. See for example IBM's SWT widget set for Java. But it's also quite the norm to get it awfully wrong: witness Sun's Swing.

This is an age old problem repeated over and over again. At least today, the new UI widgets coming in has slowed considerably. But back in the days when C/C++ UI frameworks were being born, the problem with the SWT approach was that there was considerable lag in supporting the latest greatest GUI widgets that were available on the OS. So you're app would looked dated. It didn't have a nice tree control, or whatever the latest thing was. I imagine it's similar for trying to do such wrappers for video given the advances in video rendering

And as you pointed out DirectX is more than just a 3d API and it had much different goals than OpenGL even in the 3d API arena.

--
snog wat ma tradag bagram

Re:Yes and no

[Quattro Vezina]

When Joe Average gets a Windows app.. actually, screw Joe: when even _I_ get a Windows app, I expect it to look and behave exactly like every other Windows app. No, I don't want it to look like Swing, I don't want it to look like QT, and I sure don't want Mozilla's skinned idiocy, and I'm gonna puke if I have to use another idiotic GTK file dialog in _Windows_, etc. I want it to look and _act_ exactly like one thing: the Win32 widgets. Nothing else.

That's a fallacy. Windows hasn't had anything resembling a consistent look and feel since Windows 3.1, if even then.

Even Windows applications made by Microsoft don't have a consistent look and feel. IE draws its own widgets. Office not only draws its own widgets, but it drastically changes those widgets with every version (fyi, Office XP was patterned on a theme for the WinXP beta that MS later decided not to include in Windows). Same goes with Windows Media Player--it's even less consistent than Office. Visual Studio does the same thing--try running VS2003 on Windows 2000 and you'll see what I mean.

Speaking of Office, not only does it draw its own widgets, but it creates its own open and save dialogs. Office 2000's open and save dialogs look like the Windows 2000 dialogs, but they still look like the Windows 2000 dialogs even on older versions of Windows. "Older versions of Windows" also includes Windows NT 3.x. Try running Office 97 or 2000 on NT 3.x and note the stark contrast between Office's 3D widgets and NT's fugly flat widgets.

Also, I'll add that some of the most popular non-Microsoft 3rd party apps do this as well. WinAmp was the most popular media player on Windows for a long time, and it never had anything remotely resembling the Win32 widgets.

Re:Yes and no

[Spoing]

1. But DirectX offers a lot more than that. Direct3D is just a part of it. You also get networking, sound, etc. If you wanted to stay portable and _only_ use OpenGL, you'd have to write all those extra bits yourself. Which costs time and money.

You wouldn't write the replacement libraries yourself -- you'd use SDL or other existing libs. It's not as simple as variable substitution, though it's a hell of a lot simpler than write-from-scratch!

The performance using a wrapper issue also doesn't apply; Winelib isn't a wrapper and outside of Winelib you'd write normal non-win32 code...so if the performance is poor...well!

Look and feel issues; nobody gets this for free...porting to/from Windows and MacOS/OSX is a problem. Hell, using Win9x apps on WinXP looks odd much of the time. The widgets are often a hodge-podge of styles.

Re:Yes and no

[Spoing]

1. I heard somewhere that the biggest problem with SDL is that it's designed to be simple, so a lot of more-advanced functionality simply isn't present. Is there any truth to that?

As of this morning, there are 118 SDL expansion libraries beyond the base libSDL; Extra SDL libraries

Re:Yes and no

[zootm]

Nice! I guess the main problem now is finding the "best ones" for developers to use.

Re:Yes and no

[Anonymous Coward]

[Matrox] actually wrote their OpenGL implementation as a wrapper around DirectX.

The problem? Performance was abysmal. No, not just bad. It _killed_ 3D gaming. With Doom 2 and such being the "killer apps" of video gaming back then, Matrox lost gamer market share (and game developper mind share) with both hands. And who rose like a star? NVidia, who to this day still has the fastest OpenGL implementation.

You don't know jack, do you?

(a) Doom 2 never used 3D hardware, DirectX, OR OpenGL.
(b) Matrox's 3D cards have never had any market share among gamers. Their 2D cards were briefly popular in the mid 90s. NVidia's competitor was 3DFX, who championed their own Glide API.
(c) Wrappers are perfectly viable. Glide-to-OpenGL/Direct3D wrappers were very common around the turn of the millenium, and generally worked quite fast enough; the problems were with compatibility, not speed. Even today, a number of DirectX games run perfectly acceptably under Linux using an OpenGL wrapper in the form of Cedega.

Nice troll, though.

Re:Yes and no

[Anonymous Coward]

When Joe Average gets a Windows app.. actually, screw Joe: when even _I_ get a Windows app, I expect it to look and behave exactly like every other Windows app.

Yet that is a concept not even Microsoft has figured out. Have they ever once made a program that looked like it belonged on Windows (I'm talking about before they update windows to look like the application)?

Re:Yes and no

[Quattro Vezina]

I believe Unreal Tournament 2004 uses SDL (at least the Linux version does), so it can't be too simple.

Re:Yes and no

[zootm]

The unreal games are fantastic for their modularity - in Windows, they can be configured to use any one of several renderers (DX, OGL and a few proprietary ones which have probably disappeared now). A lot of places don't see the benefit in implementing such an abstraction layer, though. A real pity.

Re:Yes and no

[Anonymous Coward]

Even Windows applications made by Microsoft don't have a consistent look and feel. IE draws its own widgets.

Yes, IE draws its own widgets. And for good reason. But IE draws its own widgets that have been painstakingly crafted to behave (almost) exactly like built-in widgets. What's the problem?

Office has traditionally used its own widgets, and while those deviate quite a bit more, they're still operate in a way fairly similar to the native ones. Sometimes they're very different, but they're usually easily recognizable to someone used to Windows.

Windows Media Player is just shit.

Re:Yes and no

[Quattro Vezina]

Yes, IE draws its own widgets. And for good reason. But IE draws its own widgets that have been painstakingly crafted to behave (almost) exactly like built-in widgets. What's the problem?

I wasn't referring to the HTML elements. I was referring to the menu bar and toolbars at the top of the window. And, yes, I can tell a difference. I've been able to tell the difference since IE3 first came out. In fact, there technically is no menubar--it's just another toolbar.

Oh, and my point is that there's no problem with that, just that some people seem to have different standards of consistency for native Windows (especially Microsoft) apps than they have for OSS apps.

Sometimes they're very different, but they're usually easily recognizable to someone used to Windows.

Just like Mozilla XUL-skinned apps, OpenOffice, and Swing spps--yet that's what the great-grandparent was complaining about.

Windows Media Player is just shit.

I'll agree with you on this one :P

WMP is one of the worst media players of all time. I'll go as far as to say that playing video is far more pleasant on Linux than on Windows. Why? Because Xine kicks ass, especially with a good frontend like Kaffeine 0.4.x (not 0.5). I've never, ever had to hunt for a codec when using a Xine-based player. WMP can't play jack without hunting down codecs from all over.

Re:Yes and no

[Anonymous Coward]

you are one of the few people that care or hell even notice that the apps look different.

ive asked many people about different apps, one i ask about in particular is limewire, which has a VERY different interface.

I ask them if the difference bothers them, and half the time it is literally "oh yeah it is different, i never noticed that before"

developers care that it looks different, end Users dont.

Re:Yes and no

[SwimsWithTheFishes]

When Joe Average gets a Windows app.. actually, screw Joe: when even _I_ get a Windows app, I expect it to look and behave exactly like every other Windows app.

I think he means the ported off of Windows app should crash and send his confidential data to Microsoft in an "Error Report".

malware?

[Joseph_Daniel_Zukige]

and the avoidance thereof, could I suggest?

Sure, the concept stuff is out there, but I have not seen any serious exploits in the wild yet.

If you want to look at it from the customer's perspective, there are more things to consider than market share and water-cooled over-clocked games beasties, fun as the latter are.

Re:Stupid question

[Anonymous Coward]

If you don't understand and don't know how to ask the question, you won't understand the answer. So why even bother asking?

Tell that to Oracle

[mangu]

Well, there are some companies that do sell software for Linux and get a profit from that. But they must make some adaptations to their business models. It's not that Linux users don't want to pay for software, the problem is that Linux users are used to test their software before buying. With free software one can download lots of programs just for testing and settle on the one that's best suited for the purpose. With commercial business software, one usually goes through a much longer evaluation program before buying, because there's no turning back once the purchase is done. So, if you want to get a profit from Linux software, be prepared to offer much better demos than the usual crippleware.

And source code delivery has nothing to do with it being commercial or free, in either the "beer" or "speech" sense. When the software is important enough, having the source code is an absolute necessity which every system administrator will insist upon. There's a disturbing meme going through the industry that "COTS" (commercial, off-the-shelf) software can be sold without source code. That's bullshit. When your company's business is totally dependent on a system, you must have access to the source code, no matter what the licence is.

Re:Tell that to Oracle

[Ingolfke]

When the software is important enough, having the source code is an absolute necessity which every system administrator will insist upon.

You addressed yourself on this point... That's bullshit.

There's a disturbing meme going through the industry that "COTS" (commercial, off-the-shelf) software can be sold without source code.

Your wording implies that this is somehow a change, a new trend moving through the industry... yeah right. Open Source and commercial software are not new bedfellows, but neither is the idea that you keep your commercial code locked up as far away from the users and the competition as you can.

When your company's business is totally dependent on a system, you must have access to the source code, no matter what the licence is.

What are you going to do with that source code? Wouldn't the issue be that you purchased a piece of software to do a certain task and it doesn't, so the vendor needs to improve/fix their software. Even if you did find a bug, why are you supporting the vendor's software by digging through their code to identify the bug? That's there job... that's what you paid for. And even if you did patch the issue and fix it yourself, what good would that do you because that would invalidate your support contract? So what's the point? I guess you could use the code to better utilize any APIs exposed by the vendor, but again, why should you have to... why don't the APIs work like they should and why doesn't the documentation explain how to use them?

Plus, this is really pretty impractical. Even in a scenario where you have access to all of the source code, like w/ a LAMP setup, do you really know enough to risk editing the code, recompile it, and run it in production system that is absolutely critical to your business. And do you do this at the risk of forking away from the main branch of code, again for your business critical system? Do you review all of the code for Linux, Apache, PHP, MySQL, all of the related libraries and modules, and every new patch?

Having access to the source code can have its advantages, but it's not a must, and closed source commercial software is a viable and common business model that can provide a great deal of value (and has) to end users.

Re:Tell that to Oracle

[mangu]

What are you going to do with that source code?

If everything goes as planned, nothing at all. But if Murphy's law is working, source code can be the difference between life and death. If your software is specialized enough that you cannot substitute it by another, you cannot depend on one supplier, even if there is no more than one supplier. Suppose that one vendor goes out of business and you need support, then what?

If your needs are general enough that there is one well defined "main branch", then yes, of course, you are better off sticking to it. Sure, do that for your email and web-server needs. But what if your business is spacecraft control or nuclear waste disposal or titanium welding or any other specialized process. How do you define a "main branch" for those businesses?

My own speciality is the first one of those, spacecraft control. Twenty years ago, when you bought a satellite, you also bought the corresponding software, with the source code included. Today, the two or three companies that supply spacecraft control software insist that you don't need the source code. They seem to think that one will spend upwards of $250 million on hardware and be satisfied with their extended warranty. I repeat: BULLSHIT! There's absolutely no way that we will spend that kind of money without having both the source code and the trained people to do whatever is needed with that source code.

Re:Tell that to Oracle

[Ingolfke]

If your needs are general enough that there is one well defined "main branch", then yes, of course, you are better off sticking to it. Sure, do that for your email and web-server needs. But what if your business is spacecraft control or nuclear waste disposal or titanium welding or any other specialized process.

I agree w/ you here and think you've made a very good point, w/ this added destinction.

There's absolutely no way that we will spend that kind of money without having both the source code and the trained people to do whatever is needed with that source code.

Again, thanks for the clarification... many of us work in "normal" shops w/o this kind of specialization and expenditure, so a view into a different kind of environment is helpful.

Re:Tell that to Oracle

[fitten]

This is why commercial companies that don't give out source code directly will frequently enter a Code Escrow agreement with a client, for exactly these reasons. If the company that makes the software disappears for some reason, the client that has the Code Escrow gets a copy of all the source to continue to do with as they need in-house. Otherwise, the client doesn't get to see the code.

Another thing is where you've come from and what you expect. Spacecraft control (and the government sector as a whole) are quite different from commercial (I've worked for years in both). I've seen exactly what you've seen, but I've also seen somewhere buy several million $$ worth of Sun hardware and they've never asked for the source code for Solaris, for example, or Oracle.

Re:Tell that to Oracle

[Anonymous Brave Guy]

It's not that Linux users don't want to pay for software

I'll bet you a lot of money it is.

Some people like F/OSS because of the open philosophy. Some people like it for the geek coolness factor. But an awful lot of people like it simply because it's free-as-in-beer.

There's a disturbing meme going through the industry that "COTS" (commercial, off-the-shelf) software can be sold without source code. That's bullshit.

Considering that the business model has been working successfully for years, it would appear that you are mistaken. What's more disturbing is the recent trend for open source fanboys to prioritise access to source code and/or immediate interoperability concerns ahead of getting software that actually does the job well.

Now, I'll grant you that any smart person buying a specialist product would at least want a clause in the support contract saying that if the supplier goes belly-up then the escrowed source gets opened. But neither forcing the opening of source before that point nor forcing it even at death for trivial software where there are plenty of alternatives available is a necessity, and that's got the COTS market covered on both counts.

Re:Tell that to Oracle

[innerweb]

Considering that the business model has been working successfully for years

The business model works particularly well for consultants like myself who are needed to go in and customize COTS solutions when the COTS does not do what the user thought it would. It does not work as well for the end user, but as they do not know enough to roll their own, or find alternative solutions, they buy what has been sold to them. They do not know if the marketing is correct. They do not know how to determine whether or not the software will take them into the future. They only know what they have been told in advertisements and reviews (another form of advertising in most cases).

What's more disturbing is the recent trend for open source fanboys to prioritise access to source code and/or immediate interoperability concerns ahead of getting software that actually does the job well

I find this amusing. "Actually does the job well" (IMO) means does it work with what you have (interoperability) and can you extend it for future needs (open standards or in some cases, open source). Buying a COTS application that can not be adapted to your business model is kind of like buying a car that can not travel the roads you need to drive on, only much more expensive. When a COTS applications is put into place, you are accepting the limitations of the software. When you start running into the dead ends, the only solutions are to hire developers to customize the COTS, pay the COTS company to customize, change your business model to match the software or do nothing and do without. Choose one that makes actual fiscal sense.

I have worked with everything from one of the top five document producing companies in the world to little corner stores. My experience is that open standards are the real issue. Open source is nice for finding bugs that mess up your system, but open standards allow you to add business functionality that otherwise would be cost prohibitive in the COTS world.

In one of the shops, we used to kick out so much mail that we had our own zip code. We were in the top five mailers in the world. We had several document creation systems. All of them were open standard and all of them had our hacks attached to do things the original authors never imagined, nor were they (original developers) willing to do once we imagined doing them. By being able to use open standards documents, we were on one project alone, able to save over $35 million per year in manpower, customer satisfaction, fee prevention and fine prevention by writing our own code. Using COTS models (except one small company) at that time and today would not have been possible. Certain companies may be willing for a fee to disclose some of their standards (though most do not disclose enough, let alone provide correct documentation), but normally the COTS providers do not provide anything terribly useful for end user customization. MS at least tries with their VBA, OLE, DLLs, et al but falls far short of the stuff I have used that is truly open standard (not nescesarily open source).

All I can say is that if more COTS companies start implementing open standards (QIF, OFX, etc) instead of copyrighted, encumered standards then the market will improve dramatically for COTS and end users.

InnerWeb

Re:Tell that to Oracle

[Anonymous Brave Guy]

I think perhaps we're talking at cross-purposes here.

I am not saying interoperability is bad, nor that open standards are not a useful safeguard in an uncertain world. I am simply saying that they are not as important as having software that does the job properly in the first place. Interoperability, open standards and easy extensibility are only means to an end, not ends in themselves.

I confess to not understanding your arguments about customisation of COTS either. No matter where someone gets their apps from, they have to trust a supplier sooner or later. From a business perspective it doesn't much matter whether that supplier is a megacorp or a consultant. No-one making the purchasing decisions in management is going to look at the code even if you've got it; this often-claimed advantage of open source software is more illusion than reality.

Similarly, in the real world people get new features added to COTS all the time without paying any consultants or having the source code. Despite all this potential for customisation and consultancy work that the F/OSS community likes to advertise, the dominant and best word processor is still Microsoft Word, and the best C++ IDE in the world is still Microsoft Visual Studio by a very long way. The extra resources Microsoft brings and its ability to listen to a wide customer base to assess the most important requirements for future versions are vital so they can add features people will pay for via upgrades. Despite all the talk of lock-in and incompatibility, they actually do offer worthwhile extra features in most new versions of their products, and that is why so many people continue to buy them (or don't, when they produce a turkey that doesn't really offer anything new that people want).

Can you name a single task that MS Word can't do, but some business has paid a consultant to develop as a custom feature for a F/OSS word processor? Just one thing, in the most popular type of application in the world? If you know one, how about ten? How about a hundred? You need this to be happening routinely to make your point about the flexibility of OSS and custom-development being an advantage over COTS software...

Re:Tell that to Oracle

[Anonymous Coward]

No-one making the purchasing decisions in management is going to look at the code even if you've got it; this often-claimed advantage of open source software is more illusion than reality.
Having both made purchasing decisions, and examined the code for software - I would disagree with you on this point. Source code is exceedingly helpful, even if it is only used 1% of the time.

Re:Tell that to Oracle

[innerweb]

I apologize is this comes across as harsh, but responding at 1:30 in the morning is leaving my brain a little fuzzy and I am having a hard time thinking... So, I am the one who needs help here, not you... ;-)

Can you name a single task that MS Word can't do, but some business has paid a consultant to develop as a custom feature for a F/OSS word processor?

Your question misses the point I was making. Buying COTS is not bad. Buying COTS without consideration for how it fits into the current environment is bad. A word processor, no matter who makes it is a widget in the workflow. As you will note, I did say that the real issue is open standards, not open source.

As far as a company that has paid an OOS developer to include some new feature in an OOS word processor, I can not personally site one. I have personally been involved in trying to expand MS Word's functionality to do things it could not do, or to try to fit it into a workflow. VBA is only able to do so much. Other tools have can have distribution limitations (I have never run into a mainframe that uses MS Word.)

Despite all this potential for customisation and consultancy work that the F/OSS community likes to advertise, the dominant and best word processor is still Microsoft Word,

Every customer I have moved to OO has not moved back. All of them prefer OO to MS Office (MS Word dominant - agree, best - not agree). And, it is not the price they like, it is the product. They paid me to set it up and install it, so they did not get it for free. True, cheaper, but not free. I have only one client who has had any crashes in OO. All of them have lost documents in MS Office. Same for Firefox from IE and Thunderbird from Outlook, though OO seems to be a better product. The major difference between me making money installing and setting up OO and a store selling a copy of MS Word, is the amount of money they (the store) can make on MS Word. If you were a retail store, would you sell the product that makes you a few dollars, or the one that makes you almsot a hundred dollars (or twenty for discounters)? MS Office is dominant because it is pushed through more channels. It has more exposure. It is included with every MS OS on every OEM that I am aware of (though you may have to pay for it to use it still). Many people are under the illusions that only MS Office works with MS Office and therefore do not try anything else. I can not remember the last time I needed MS Office.

I confess to not understanding your arguments about customisation of COTS either.

Most people (most businesses) buy COTS with the expectation (based on the sales and marketing materials) that the COTS package will do everything they need to do. They base their projections, cost analyses and future business on these false assumptions. Compounding that problem is/are the people who sell the stuff who have a bad habit of saying I don't see why you could not do that (plausible deniability, they never said it could). Accounting has big issues there. Especially tieing it into workflow. Customizing COTS package is typically much harder to do unless you have much experience with the package's quirks, errors and traps. At least if the package uses open source, you can figure out what the documentation really should be saying. If it at least uses open standards, then there is also a chance that work can be done outside the COTS app.

COTS is a great tool sometimes. Sometimes it is a business killer. Businesses have gone under by not using the correct software solution. COTS fails just as often at the task as roll your own. Thie problem with COTS is it takes you down a path you have little control over without very large resources. I have had several clients who have had to change the way they do business to match what a COTS product could do because they became so locke dinto the COTS. It killed several of them until I helped them get off the solutions. Things like word processor

Re:Should be: Migrating an App the Worst Possible

[MichaelSmith]

Of course it could _help_ in migration even with the source. You could partly port the application and partly extend wine until it ran the application

I don't get it...

[Anonymous Coward]

If Linux is all that it say it is, why develop a porting mechanism from an 'inferior' OS? Why brute force specific Win32 apps into Linux? Aren't your equivalent native apps suffecient? Or there aren't any at all?

Why bash MS' OS, media player, office yet at the same time green with envy with their 'inferior' products?

Re:I don't get it...

[psyon1]

If Company A Inc. has spent the last 10 years writing and perfecting a Point of Sales program that runs on the Windows OS, they dont want to spend another 10 years writing one for linux. Porting saves time.

Re:I don't get it...

[dustmite]

Feeding the troll .. ugh ..

How do you manage to equate existence of applications for an OS with quality of underlying OS? That's absurd. The apps run on top of the OS. That's like saying that my old rundown jalopy is a better car than your Porsche because I put an expensive radio in it.

eat?

[Joseph_Daniel_Zukige]

I'd just rather eat.

I think I hear an echo from Byelorussia

Of course, I also hear an echo from my own stomache.

Somehow, the words, only monopolizing the PC OS market have the strangest ring to them.

int b[0] when you mean int* b is a *bad* habit

[The Darkness]

In gcc declaring an array of 0 length does not allocate space for the pointer! It's basically an inline memory pointer. Given:

struct {
int a;
int b[0]; // inline ptr
} test;

Assuming a 4 byte int and the object is at address 0. (yes, yes, NULL pointer and all that rot)

sizeof(test) = 4
&test.a = 0x0
&test.b[0] = 0x4
&test.b[1] = 0x8

One use is to allocate the memory yourself and then use the struct to map that memory. The sizeof() would give you the header size. Then (sizeof(header) + allocated data storage) is the total size to alloc.

See: Zero Length (gcc)

IMO, it is a very bad habit to use "type name[0]" when you mean "type* name".

Doing what you claim (sorry, you're AC) is the "Microsoft way" will cause memory corruption in GCC.

Cheap POWER?

[Jezza]

A serious point, if IBM is really serious about people to port their Windows apps to "Linux on POWER" (which does have a nice ring to it) then why are all IBM's POWER based systems so expensive?!

Now Apple can make a PowerPC based system for £339 (BYODKM as Steve might say) why can't IBM create something similar? Preload it Linux and we'd all be happy little "porters". Now if they really wanted us to do this then a laptop would be really great. But presently IBM will only sell expensive POWER systems.

Now after you've ported your "killer app" to LoP, how the heck do you deploy it? On what? Some mega-expensive POWER Server? Doesn't IBM realise that Windows apps are usually run on the desktop or laptop? I mean they're not suggesting we're using Windows as a server OS are they? ;-)

PS. Anyone from IBM reading this - yes I would buy an IBM LoP box if it was sub £500 BYODKM.

The best way to handle Win32

[Anonymous Coward]

#ifdef WIN32
# error "Get a real operating system."
#endif

What about good old C++ abstraction and #ifdef?

[unkaggregate]

I regularly do this all the time: I write a basic main() routine for both platforms (these are usually console apps) then add #ifdef WIN32...#endif and #ifdef LINUX....#endif for each case. If necessary, complex functions are split off into subroutines, internal libraries, or C++ classes (and #ifdefd like so). Then just make a Makefile for each platform (For Win32, the usual .DSP .DSW duo as I use MSVC 6, and Linux a simple Makefile that includes -DLINUX in the CFLAGS) and compile for each.

The same can be applied to GUIs, though for Windows you'll have to write a WinMain wrapper.

Re:What about good old C++ abstraction and #ifdef?

[grumbledoak]

You have just more than doubled your production costs, and that's just for two architectures. Good luck selling these at a profit. And God help your code maintainers.

Can I have a Mac version, please ?

Re:What about good old C++ abstraction and #ifdef?

[unkaggregate]

Not if you do it right. The point is to abstract things into classes, libraries, or small #ifdefs so that you can generally use the same code for all platforms, then write the platform-specific stuff in code that is only included for a particular OS or platform. For example, look at open-source projects like cdrdao where there is a general C++ class to send SCSI commands, and the C++ class itself (chosen by platform) handles the low-level details of getting there. This allows you to compile cdrdao for Linux (using the SG_IO ioctls directly to /dev/cdrom) but you could easily port it to Windows (using WNASPI32.DLL).

Re:What about good old C++ abstraction and #ifdef?

[pclminion]

You have just more than doubled your production costs, and that's just for two architectures. Good luck selling these at a profit. And God help your code maintainers.

You presume that there is a large amount of code in between those #ifdef's. Anybody with even a hint of skill will make the parts which can be made portable, portable, and the remaining platform-independent code will be trivial and easy to understand.

It sounds like you're suggesting that there is some way to write completely platform-independent code without actually worrying about which platforms you'll be running on. That's only possible in ideal situations and sophomore programming assignments. In reality, machines are different, and this requires platform-specific code.

It might be hard to grasp by someone who's never written anything real, but sometimes you have to step outside the bounds of strict ANSI C to do what the customer needs done.

Closed-source software companies can be abusive.

[Futurepower(R)]

Agreed. Closed-source software companies can be extremely abusive in hiding the fact that some crucial element of their software doesn't really work. You may have to use the software for 3 months (off and on, few people can drop everything to evaluate software) to discover that it is so much hassle that it is useless to you.

And once you pay for their software, you have absolutely no recourse. In decades of evaluating software, I've never known a company that listened to their technical support people.

In Japan

[Anonymous Coward]

Girls port software for guys!

OpenSTA

[xarak]

The guy who can migrate OpenSTA for me gets a crate of Champagne.

WxWindows is now WxWidgets.

[Futurepower(R)]

Those who aren't working with cross-platform GUIs may not know that WxWindows is now WxWidgets.

See the name change page. Don't use the word "windows" unless you mean a Microsoft product, because Microsoft owns the word in the UK and in the United States.

Corrupt governments don't just support overly broad trademarks against their people, they kill Iraqis for oil profits, too.

Re:WxWindows is now WxWidgets.

[sconeu]

Actually, it's debatable if MS owns the word "Windows" in the US. It hasn't been fully tested in court (or did the Lindows case do that?), and many people think that MS may lose said trademark on "Windows" without the preceding "Microsoft", should it ever be tested.

I believe the Lindows court loss was in Europe somewhere.

Re: hungarian notation and newbies

[Anonymous Coward]

Most of the examples/documentation use lpszHungarian notation. Newbies naturally attempt to copy the examples they're given. Newbies make mistakes. As a result, you're likely to see a lot of badly written windows code that uses hungarian notation.

Note: You're also very likely to find very beautiful, very badly written linux code that uses prfx_lwrcs notation. Why? Linux examples are in that style, and linux newbies have access to the indent program.

In conclusion: Newbies will be newbies. Don't judge a style based on what a newbie can break with it. ;)

Testing

[Mike McTernan]

I cant write code myself, so obviously there is a lot that i dont know. But is it really that hard to write code that is portable?

Part of the problem is that unless a developer tests their code on another platform, you don't know if it is truely portable (unless you are writing a pretty basic application that is compiled with -ansi -pedantic). As you can imagine, a lot of developers will not take the time to do this testing, maynot want to support other platforms, or maynot own other platforms on which to test their code.

Lots of typos

[Anonymous Coward]

This was posted on OSNews.com a while back. Not only did people find lots of typos, but also lots of semantic errors. It appears the author hasn't done much Windows programming and never tried to compile the code samples he displays.

It should be taken with a grain of salt

Re: hungarian notation and newbies

[Anonymous Coward]

WhatAboutMacintoshNotationThen?

Oracle is the worst example...

[Kjella]

...of a Linux business model. If you really need an Oracle database, it is because it is a major, vital part of your company where you can accept nothing less but full ACID compliance, replication, load balancing etc. etc. If you could run it without support, you don't need Oracle. Basicly, you're buying an Oracle server which happens to run some OS.

Yes, other sofrware is fairly critical to your business too, like desktops / email / webserver / whatnot. But they are not more critical than that you most of the time can work with the "find stable version, test new version, upgrade to new stable version" kind of support, at least when it comes to non-internet accessible software. And the rest are for many businesses mozilla, apache, openssh and whatever you use for an email server. All well supported by a community, nothing you need commercial support for.

Kjella

LOL WHAT

[Anonymous Coward]

.

LOL WHAT

[Anonymous Coward]

Re:OS X?

[IamTheRealMike]

There aren't any hard statistics either which way - the few that I've seen (from IDC) show Linux either matched 1:1 with the Mac or ahead. Which doesn't surprise me - Linux is free and works on Intel PCs, and MacOS X is expensive and only works on dedicated hardware. If Linux does have higher market share that's no reflection on MacOS, just the realities of hte market.

So there's this huge programmer shortage?

[Anonymous Coward]

Seems like it would be better to hire a consultant who has win32 and pthread experience to do the porting since that person would know all the gotcha's. I happen to know there are people with those skills available.

Hey!

[ggvaidya]

I thought that was the best part of it!

*imagines a crocodile picking off Mr. Iwritespam Formoney while he's trying to port "New Smileys For Your Computer!" to Linux ... mmmm, spammer!*

Yes and yes (and no)

[Anonymous Brave Guy]

That's a fallacy. Windows hasn't had anything resembling a consistent look and feel since Windows 3.1, if even then.

While what you say is true to an extent, I think you're ignoring a valid point. Sure, Microsoft plays fast and loose with its own apps, particularly the menu, toolbar and open/save dialogs. Others tailor the interface somewhat as well. But the vast majority of the conventions -- the things an average user will just assume to work -- are the same in pretty much all native Windows apps. A right-click brings up a context menu. You save your work by going to File->Save, and you'll find the Open, Print and Exit commands in the same place. The max/min/restore buttons are at the top-right of the window if applicable. And so it goes.

Some variations on the theme work very well. I was impressed with the simple but effective variation Firefox has adopted for its "find" feature, for example. Others suck: after my first experience using the GIMP on Windows, when it insisted on trying to use completely unfamiliar UI conventions, I gave up.

But the bottom line is that most native Windows apps do have a high level of UI consistency, and if you're going to vary the theme, it should be for a clear reason (such as the Firefox feature I mentioned) and not just because you're developing an app with an inadequate toolkit that can't handle native widgets properly.

Native look and feel

[dustmite]

And if I were on a Mac, I'd expect it to look and feel like on a Mac. I would _not_ want an app that looks and acts like Windows (e.g., wants me to right-click) in the middle of an Aqua desktop.

You are 100% right --- ported apps should have "native look and feel" on each platform! A good cross-platform API that has been designed with this goal in mind since the start is wxWidgets.

events/conditional variables

[meshko]

Unfortunately it doesn't cover the really fun part -- mapping windows Event into pthread's Conditional Variable.

Re:events/conditional variables

[Anonymous Coward]

Converting from win32 Events to pthread condition variables is easy. It's the other direction that's hard.

conversion may not be the answer

[john_uy]

sometimes, it is much cheaper just to rewrite the entire software in a new platform than having to port the code. at least, you get to improve the previous software in terms of features and all the bad programming stuff. this is problem that we are actually facing, and we decided for ourselves to write applications (and i am still in the process of trying to convince to make it open source in the future.)

Re:conversion may not be the answer

[Paralizer]

There was a slashdot artical a while ago, here http://slashdot.org/articles/04/01/15/1837242.shtm l which, among others, suggests rewriting code (usually) "introduces new bugs and abandons all the small fixes and tweaks that made the original version work so well.".

If you just want a prewritten program to compile and execute natively on another platform, porting is usually the answer. I don't see how rewriting the entire software is going to be cheaper, especially when much of what is being ported can already be compiled without problem on your target system.

Re:conversion may not be the answer

[john_uy]

ahh yes. the program mentioned is written in c/c++. maybe for our case what we did was to reprogram software written in oracle developer to full java. :)

Re:OS X?

[dustmite]

Ha, I notice you carefully said "Windows generally wins out" and not "Windows is a better option". Because Windows is of course not a "better" desktop OS ... it only "generally wins out" because of other factors not relating to OS quality, and in fact the primary factor is lack of application support (games, business apps etc.). But hang on, this is exactly the topic of the discussion: porting apps to platforms like Mac OS to fix the "lack of application support" problem .. so what was your point again? Actually all you just did is reference the "chicken and egg" problem. And the reason people want to solve this problem is that there are better eggs out there .. or is that better chickens? Whatever. It's "smarter" from a macro-economic perspective because using a better platform increases productivity and efficiency and lowers downtime and training costs, increasing the competitiveness and productivity of the economy, and makes peoples lives easier.

Re:OS X?

[dustmite]

Why the hell would it be smarter to "move apps to OS X"?

To put it another way: it's smarter because allowing yourself (or your customers) to be locked in to a single vendor means that single vendor can charge monopoly ("what the market will bear") pricing for their solutions. In other words, it's smarter because if everyone does it, single-vendors can't extort exorbitant profits from you. If two platform vendors stood on equal footing, unless they fixed prices it would naturally reduce the extortion rates (I don't know about you, but 80% profit margins seem to prove this point!)

Something else to consider is that porting to any second platform from Win32/MFC etc. is usually "the" major step, and porting to a third platform is usually minimal, cost-wise, because once you've ported once, you've already done the vast majority of the work in organizing your code for portability. If you do it right, and choose the right APIs, the cost proportions can look more or less like this e.g.:

• (Step 1) Original Windows development: 2 man-years
• (Step 2) Linux port: 4 months
• (Step 3) Mac port: 6 weeks

This makes a Mac OS port almost a "no-brainer". Oh, and the above example is a real example of a project I'm currently nearing completion of.

The real falacies

[Moraelin]

No offense, but you seem to make two of them yourself.

1. Basically "if we don't have 100% consistency, we should go for 0% instead". Or, if you will, "bah, you already had a change of look-and-feel some 5 years ago, so suck it up and accept one daily, for each program."

Sorry, no. The real world isn't that clear-cut black-and-white. Sometimes you have to settle for "good enough" instead of "perfect".

2. More importantly, the underlying fallacy is "looks are all that matters." Seein' as what you came up with is flat buttons or different icons.

And that's not just a fallacy, it's also _the_ number one _failure_ of GUIs designed by programmers, graphics artists, marketting, etc. (Though each of them for very different reasons.) Generally anyone else who really has _zero_ clue about usability, and just thinks anything graphical will do.

What I'm more concerned with isn't "waaah, but they changed the 'new folder' icon in XP!" I'm more concerned with how things work. Which is why my point explicitly said "reusing skills" not "reusing graphics."

Take the Windows file open dialog for example. Sure, some apps might add a preview field next to it, or a couple of extra fields, but by and large it stayed the same since Windows '95. You can still do the same things (e.g., creating or renaming a folder right in the list), in the same way, in all apps that use it.

The important thing is: Once you've learned to use it once, you can do it mechanically, without even thinking about it. Even if you just bought/downloaded/compiled/whatever a brand new app, you already know how its file dialog works. That's one less thing to go through a learning curve about.

Now kindly open a GTK dialog box in Windows. E.g., open a file in Gimp. Ugh. WTF is that box? What was wrong with the "normal" box, that needed replacing? Or try it with a Swing app. Ugh. Why does everything look and act differently?

Try to answer those questions _without_ going into technical details about widget sets and libraries. Pretend I'm Joe Average, who doesn't even know what GTK is. And more importantly, who doesn't _care_ about such details. I just want to use the program, with a minimum of learning curve or thinking.

What was wrong, from a _functionality_ point of view, with the old dialog? What end-user functionality absolutely wasn't available through it, so that it needed a completely different dialog?

Almost Top Programmer's Productivity on G5.

[Anonymous Coward]

Visual C++ killed -> powerful KDevelop-3.1.2 + gcc-3.4.4-ss-20050211 + Mono-1.1.x + MonoDevelop.

Total Commander 6.5 killed -> magnific Krusader-1.51 + KDiff.

Rational Rose a/o Sparx a/o Visio killed -> niceful Umbrello-1.3.2.

VMWare-4.5.x killed -> marvellous Xen-2.0.4.

open4free © : using QT-3.3.3/KDE-3.3.2

A better option...

[Anonymous Coward]

...would be for developers to more strongly commit to the Linux / Open Source platform, develop more games, utils, apps, etc. for Linux, so that there is no more need to migrate to/from Windoze!

Unix Migration Guide

[Anonymous Coward]

You can use the Unix Application Migration Guide.

Reverse as needed.

Re:OS X?

[EzInKy]

Wouldn't it be smarter to move apps to OS X?

Only if you prefer the fire to the frying pan. Let us know when Apple supports 95% the available hardware out there.

Re:Stupid question

[DarkMantle]

Yes, but only if you have the source code (eg: you created the program, or a windows only OSS project.)

Having gone to a college that only taught windows based programming, this could be very useful. (No I haven't RTFA'd yet)

Choose the right toolkits

[Ricdude]

and they'll do the work for you. The ACE libraries are invaluable for cross platform network programming (Winsock? What's that?), and the TAO CORBA implementation can't be beat. I prototype code on my Win32 laptop all the time, copy the same source files to solaris, and recompile with no problems. Well, ok, it took a day to get the makefiles straightened out, but now, I can take the

For GUIs, I lean towards Tcl/Tk. It's as cross platform as it needs to be, and GUIs really come together fast with it.

Other portability considerations

[Dr. Manhattan]

"If you haven't ported your program, it isn't portable." An old saying in the programming world, and it has some truth to it. The best situation is to write the code on at least three platforms at once. This catches at least 90% of the 'gotchas' before they spread all over the code.

The other nice thing is that a bug that doesn't cause any symptoms on one platform might crash immediately and horribly on another platform. A lot of bugs get caught very early in the development cycle this way, too.

Separating out the GUI is important for real portability. Fortunately, the vast majority of apps can decompose pretty naturally into an "engine" and a "GUI".

Either:- 1) Design for performance 2) Design for portability

It's not impossible to design for both. Indeed, even games can be done this way - look at the original Quake, which had (at least) a software, Glide, and OpenGL renderer, and ran well even on hardware people literally throw out today.

But if you've got an already-written app, the saying above comes into play. Heck, I once worked with an app that had been designed to be portable, but the people writing it hadn't actually run it on anything but Solaris. Moving it even to other Unixes was a real chore; I'd run screaming before trying to port it to Win32.

All my desktop apps are totally cross-platform

[Anonymous Coward]

Because I use REALbasic [realsoftware.com] I can deploy my desktop applications on Windows, MacOS Classic, MacOS X and Linux by selecting target platform(s) and pressing a button. The finished apps do not require an installer (everything is in the executable.) REALbasic isn't suitable for everything, but more than adequate for the average desktop program. It has a Visual Basic Project Converter and a nice IDE. It also has OOP RAD. I'm done with C/C++ hell.

wxWindows

[johnsq]

I ported a Win32 MFC app which graphed a heartbeat line for a particular metric to wxPython http://wxpython.org/ recently and it's worked out great. It now works on Win32 (nicely wrapped up using py2exe and Nullsoft Installer) as well as any Linux system with the wxWindows libs installed. It was even easy to make a simple curses interface for the hard-core command liners. Our ops team has modifed the code now to measure and graph all kinds of metrics, all of which are multi-platform and don't require compilation via Visual Studio. Highly recommended.

MingW + Cygwin

[accessdeniednsp]

I'm not sure if this should be a reply to someone else's comment, so I'll start anew.

I'm the guy who helped port the gaim-encryption plugin FROM Linux over TO Win32. (The opposite of the article and this topic, I know). But, after I sent the patches back up to the maintainer, he was able to easily carry it in his source tree.

I used Cygwin and MingW to handle the compilation with his original autoconf, etc. build environment. Of course, there was the requisite GTK+ libraries, etc. that went along with it too. But the magic was MingW and Cygwin.

Perhaps this could give the various developers some insight that "it really can be done".

--
3. Don't forget to enjoy!

Re:Should be: Migrating an App the Worst Possible

[paulbd]

Namely that you spawn processes and use environment variables as opposed to having a message loop and handlers (the way most windows apps are written).

Time to wakeup and smell the ashes. Any GUI program worth its weight in polystyrene beads has an event (think "message") loop and handlers. On Linux too.

How to migrate a Windows app:

[pclminion]

It's easy, really:

$ cp /mnt/samba/xyzzy/programs/windows_app.exe .
$ objcopy -O elf32-i386 windows_app.exe windows_app
$ ./windows_app

;-)

PS

[Anonymous Brave Guy]

And to even use STL would require enabling rtti & exception handling on Mozilla which would bloat the code by another 25%.

I'm afraid that information is also many years out of date. Overheads for unusued RTTI and EH support are almost zero in any decent C++ compiler today.

Re:PS

[DrXym]

Sadly Mozilla doesn't have the luxury of running on "any decent compiler". While a good number of hosts use gcc 2.95 or cl.exe 12.x it has to support them.

Re:PS

[Anonymous Brave Guy]

Sadly Mozilla doesn't have the luxury of running on "any decent compiler". While a good number of hosts use gcc 2.95 or cl.exe 12.x it has to support them.

Sorry, but that just doesn't make sense. Mozilla doesn't run on any compiler at all; it runs on different platforms. To run Moz on my system, I click the icon for mozilla.exe. I do happen to have GCC installed on my system, but it's completely unnecessary for running the application.

The only people who care about the compiler are those who are building the project themselves. Obviously YMMV, but if I were running the project, I'd rather help those developers who wanted to use modern language features to make their life easier than cater to a handful of people who for some reason want to compile from source but only using compilers nearly a decade out of date...

Re:PS

[Anonymous Coward]

Clearly you are not an u1tr4 1337 runner of mozilla. To advance to the next level you really need a shell script that cvs updates from CVS, and rebuilds mozilla prior to running.

There's a fine standard for inter-process mutexes

[Jamie Lokier]

At the moment there is no standard way to map Wind0ze inter-process mutex to Linux

I don't know what special quirks Windows inter-process mutex have, but pthreads is recognised as the standard among many unixes for generic threading, and GNU/Linux provides pthreads inter-process mutexes just fine:

pthread_mutexattr_setpshared:

The process-shared attribute is set to PTHREAD_PROCESS_SHARED to permit a mutex to be operated upon by any thread that has access to the memory where the mutex is allocated, even if the mutex is allocated in memory that is shared by multiple processes. If the process-shared attribute is PTHREAD_PROCESS_PRIVATE, the mutex shall only be operated upon by threads created within the same process as the thread that initialized the mutex; if threads of differing processes attempt to operate on such a mutex, the behavior is undefined. The default value of the attribute shall be PTHREAD_PROCESS_PRIVATE.

Use that and your program will be portable to all platforms which implement pthreads properly. (Maybe even Win32 pthreads :)

Enjoy,
-- Jamie

Portable Building?

[Branko]

Is there a way to portably build portable C++ code?

GNU Make can do it in theory, but it lacks (direct) support for configurations (easy switch between debug and release build), lacks portable generation of dependencies, does not handle interdependencies between projects well (e.g. EXE that depends on DLLs), has difficulties when multiple compilers should build the same source tree (so target dirs for binaries should be separated), and is generally pain in the neck.

Is there a build system that does not require you to change project files (or makefiles or whatever you call them...) when you change the platform or compiler or configuration?

Re:Portable Building?

[Anonymous Coward]

use the autotools.

Re:Portable Building?

[Anonymous Coward]

Try cmake : http://www.cmake.org/

I'm impress with the easy of use.

regards

write the code portable from day one

[Anonymous Coward]

I've had much experience with writing code that compiles on windows and linux and found that when I used a pthreads library on Windows, I had no problems porting the code by changing only a few lines of code.

Avoid Microsoft specific API's. pthread libraries make your code generally compatible and handle all the mapping of the calls for you.

Re:Stupid question

[jk0]

I feel your pain..

WMP and why we hates it.

[Grendel Drago]

WMP can't play jack without hunting down codecs from all over.

I think that's more of an issue with the Windows DirectShow architecture than anything else. (I completely agree that the interface design is fugly, and needs to die die die.) The codec problem is still there in Media Player Classic, which, aside from that, is a rather good media player. (MPC gives better codec-not-found messages than WMP, though.)

I think it's like gPhoto: camera drivers are written modularly, to be camera drivers. They don't come with sixteen different sorts of cutesy crap-ridden software (which has some sort of "friendly" interface made of circles because they're friendlier); they're camera drivers, and that's all they do. Compare that to Windows, where you need to install a different kind of software, never mind a different driver, for a new camera.

Codecs are a bit like that. Want Real codecs? Whoops, you'll need RealPlayer. Want QuickTime codecs? Well, guess what.

There are hacks, like {Real,QuickTime}Alternative, but they're (a) not really legal, and (b) not widely used.

Sometimes I think the lack of mainstream software support for Linux is a good thing.

--grendel drago

Beat me to it.

[Grendel Drago]

Ah, you beat me to it. I'm doing some wxPerl development (for FreeMED) at the moment, and moving from one platform to another is trivial. I especially like the use of native dialogs for file-selection, color-selection, printing and so forth. If it's all done right, you don't even know that the app uses Wx. (I didn't know that Audacity did until quite recently.)

(Though I wish Wx::Config were implemented in the Windows/ActivePerl port. I had much desired to make use of it.)

--grendel drago

"First unix"?

[Grendel Drago]

I think the "first unix" figures for Linux are dwarfed by those for Mac OSX. I mean, its proponents keep assuring me that it's a "real unix"...

--grendel drago

Nevermind Non-GUI functionality

[Austin Milbarge]

Windows, Linux. They both systems support processes, threads, semaphores, shared memory, TCP/IP stacks, pipes and files, porting these structures was never that big of a deal. Why do you think most Linux apps still remain CLI? Because the real pain in the butt comes when one needs to port the GUI, since the bulk of the code always seem to be the GUI. Face it, for better or worse Windows remains the #1 windowing system. There are no *nix equivalents to MFC, .NET, VB or the Win32 API. If anyone knows of a good IBM article on how to port a full blown MFC app to GTK+, I'd love to hear about it.

Linux nonportability.

[Grendel Drago]

If I'm developing primarily on Linux, what sort of things do I need to look out for to make my application build on other Unices? On Mac OSX, which is sort of a pseudo-Unix in some ways?

Is there a good tutorial for this sort of thing? I'm sure folks would be better at not writing unportable kibble if they just knew better.

--grendel drago

Re:Linux nonportability.

[fitten]

It's actually gotten a lot better lately. Sticking to standard APIs is a start. Most of the time, man pages on Linux will tell you if it's Linux only or if Linux behaves a different way... one good example is for gettimeofday, the timezone structure never has and never will be surported by Linux, according to the documentation.

Unfortunately, there are a number of libraries for things that aren't portable. If you are planning to use some libraries to do something, make sure that they are supported on all the targets you think will use the software (sound and graphics being two).

Encouraging vs. enforcing.

[Grendel Drago]

His point is that HN encourages bad code. Not that it enforces it. Like talking on a cell phone in a car encourages bad driving.

And, who knows, maybe he has a valid point. I'm working in Perl at the moment, so my variables, depending how you look at it, are either untyped, or have built-in HN. ($foo is a $calar, @bar is an @rray, and so forth.)

Then again, I have GUI components which might use various widgets, and I need to call different methods on them based on what widget they're using. (GetValue versus GetSelection, for instance.) So I'll call an OK-button $self->{b_ok}, because it helps and because I'm going to use it later.

Though I've never seen the point in labeling every single variable by the Hungarian method. I don't use this for local variables; I use it for maybe one in ten variables, because it helps.

Am I for or against HN? Now I can't even tell. It works for me, sometimes, in some contexts.

--grendel drago

Re:Encouraging vs. enforcing.

[robocrop]

His point is that HN encourages bad code

I realize that. My point is that statements such as this are far too general to be useful.

And, who knows, maybe he has a valid point. I'm working in Perl at the moment, so my variables, depending how you look at it, are either untyped, or have built-in HN

They have their own built-in notation, which is perfectly reasonable. In such a case HN would probably be overkill.

But my point is, as in most situations when dealing with HN one should adopt a position based on situational ethics: is it applicable to the case at hand? If so then use it. If not, don't. You know, the logic we all supposedly learned in school. It grates on me to hear people kneejerk dismiss any concept such as HN for their own political reasons. Particularly when the person complaining about it tells me that if I use it, I must be a sloppy programmer who writes buggy code.

All naming conventions, coding standards, programming templates, etc work towards a common goal: making code immediately meaningful to the reader/maintainer - lending context to locality. This in turn makes code more useful, more extensible, and easier to write. And this should be our goal - no matter what tools we use to achieve it, no matter which hated company or individual backs the concept.

Re:Encouraging vs. enforcing.

[johannesg]

You know, the logic we all supposedly learned in school. It grates on me to hear people kneejerk dismiss any concept such as HN for their own political reasons.

I gave technical reasons. You responded by arrogantly assuming I don't like it because it is from Microsoft. Did you learn that in school too?

Particularly when the person complaining about it tells me that if I use it, I must be a sloppy programmer who writes buggy code.

I didn't actually do that. Here's something you may one day come to realize: on the message board called "slashdot" there are multiple users, each with his own ideas and agenda. Ranting against one after feeling slighted by another doesn't help at all.

All naming conventions, coding standards, programming templates, etc work towards a common goal: making code immediately meaningful to the reader/maintainer - lending context to locality. This in turn makes code more useful, more extensible, and easier to write. And this should be our goal - no matter what tools we use to achieve it,

Meaningful discussion: good.

...no matter which hated company or individual backs the concept.

Meaingless rant against perceived, yet utterly non-existant anti-Microsoftism: bad.

Re:Encouraging vs. enforcing.

[robocrop]

I gave technical reasons. You responded by arrogantly assuming I don't like it because it is from Microsoft. Did you learn that in school too?

First, your "technical reasons" used such biased language as "unpronounceable garbage". And I went through this reasons and offered my refutation of them.

I didn't actually do that. Here's something you may one day come to realize: on the message board called "slashdot" there are multiple users, each with his own ideas and agenda. Ranting against one after feeling slighted by another doesn't help at all.

The interesting point is, you are assuming that this remark was directed at you! That's is why I said "the person complaining" - to indicate that there were multiple people responding, and to specifically make a remark against the person using this tactic in his complaint.

Meaingless rant against perceived, yet utterly non-existant anti-Microsoftism: bad.

Given that the responses have all generally included situations in which the author would use a naming convention - sometimes HN itself - I think this is a perfectly valid position. Of course there is no way to prove it, but I am 100% certain that the majority of bitching and moaning we hear about HN and how "evil" it is results from the fact that people see it as a Microsoft idea, and we all now how cool it is to bag on anything from Microsoft. If Linus had proposed it, you'd have a Hungarian notation t-shirt.

Don't lecture me for pointing up the obvious bias on this site.

Re:Encouraging vs. enforcing.

[johannesg]

Meaingless rant against perceived, yet utterly non-existant anti-Microsoftism: bad.

Given that the responses have all generally included situations in which the author would use a naming convention - sometimes HN itself - I think this is a perfectly valid position.

So "ranting against naming conventions" equals "ranting against Microsoft"? I'm trying very hard to understand how you make that particular leap of logic... Could you possibly believe that Microsoft invented the concept of naming conventions?

Of course there is no way to prove it, but I am 100% certain that the majority of bitching and moaning we hear about HN and how "evil" it is results from the fact that people see it as a Microsoft idea, and we all now how cool it is to bag on anything from Microsoft. If Linus had proposed it, you'd have a Hungarian notation t-shirt.

I fail to understand why you bring this up again and again. Can we not dislike something simply because it is a bad idea?

Re:Encouraging vs. enforcing.

[robocrop]

So "ranting against naming conventions" equals "ranting against Microsoft"? I'm trying very hard to understand how you make that particular leap of logic... Could you possibly believe that Microsoft invented the concept of naming conventions

You are very obviously prevaricating. How can you claim to be "ranting against naming conventions" when you and others replying offer situations in which you would use them - and your posts are specifically against HN! Furthermore, the parent was specifically against HN!

I fail to understand why you bring this up again and again.

Because the fact that HN is singled out as the naming convention to lambast seems, to me, an obvious result of the fact that it is a standard pushed by MS.

Can we not dislike something simply because it is a bad idea?

Of course you can. But if one wants to label something a "bad idea" generally one has to provide reasons for this position, not speak in equivocal language about how they "hate HN, but see how naming conventions are sometimes useful, but HN is unpronounceable garbage, and I use Emacs ..." The reasons you enumerated in your first reply simply don't hold water, and your responses since then have continued to weaken your stance.

Perhaps it would simply be a better idea for you guys to - for the 100th time - not use HN if you don't like it and leave it at that.

My point here is that arguing this kind of stuff is a waste of time - and it only pisses people off to tell them that their preference is somehow inferior to yours, or an indicator of sloppiness, or whatever.

For example, I don't use Emacs. But I recognize that some people find it better, and I work with people who use it. I'm not going to tell them that Emacs sucks and has no use just because I find it archaic and convoluted. It's their choice. I grumble a bit when I have to fix a bug at their desk, but no real harm is done.

All of these "this practice/tool/compiler/OS sucks!" arguments devolve to such a position. If it affects your work, come to some form of compromise about it. If you believe it to be objectively useless, explain why and see if others agree. Otherwise why do you care what I or anyone else use?

Re:Encouraging vs. enforcing.

[johannesg]

How can you claim to be "ranting against naming conventions" when you and others replying offer situations in which you would use them - and your posts are specifically against HN!

It seems you are still mightily confused about the identities of the people posting here. As a clue, if you click on a message the name of the poster appears in the bar at the top. Messages that do not carry my name are not posted by me and do not represent my opinion.

Furthermore, the parent was specifically against HN!

The parent post of your post is my post, which is indeed specifically against HN. I'm being consistent here: I never claimed in any of my posts that I like HN in specific situations; I just don't like it at all. And I don't use emacs.

Perhaps it would simply be a better idea for you guys to - for the 100th time - not use HN if you don't like it and leave it at that.

No. HN must die. Its continued existence is polluting the minds of young programmers throughout the world. Once infected they become irrational, unable to distinguish between different posters on message boards, unable to understand the difference between type and meaning, and unable to carry a convincing argument.

Just to help _you_, the guy who likes HN in some situations is "sdpwslhnDcam" ("Slashdot poster who sometimes likes HN" Dcam). The guy who uses emacs is sdpwnlhnSwillden ("Slashdot poster who never likes HN" Swillden). I don't use emacs and don't like HN, and I'm sdpwnlhnJohannesg. And you are tsdwrtRobocrop ("trollish slashdot poster with reading trouble" Robocrop).

Since I don't take you seriously anymore, I'd suggest not bothering to reply. But you've already proven that reading skills are not your forte, and of course you are master of your own destiny, so feel free to post some more confused, meaningless drivel if you want. I've wasted enough time replying to it though.

Re:Encouraging vs. enforcing.

[robocrop]

It seems you are still mightily confused about the identities of the people posting here
I never claimed in any of my posts that I like HN in specific situations; I just don't like it at all. And I don't use emacs.

You seem insistent upon carrying out this fantasy that I can't keep the posters straight, probably because you've realized your position is completely without merit. Frankly I'm no longer doubtful as to why you are posting this type of garbage: you are obviously a submoron. You cannot follow a conversation, much less offer a premise, back it with logic or reason, or discuss in a calm, even-handed manner.

Allow me to lay it out for you. When a person uses a phrase such as "you and others", that indicates that the person is not speaking only to you, not speaking directly to you, and is in fact addressing what he or she sees to be a trend in a conversation. I have given you my evaluation of the trend of this conversation: that most of the repliers (including you) are specifically against HN with little valid reason; that most of the repliers do, however, use a naming convention of some type; and that this type of argument is just a religious debate dredged up by trolls such as yourself to spew your anti-MS, anti-everyone-but-you bile.

And, just so you know, when discussing one's strengths the proper French word is "fort", not "forte".

Re:Encouraging vs. enforcing.

[johannesg]

I didn't want to reply anymore, feeding trolls and all that, but this is just too funny:

And, just so you know, when discussing one's strengths the proper French word is "fort", not "forte".

Contrast fort with forte . But hey, if you feel your reading skills are not a place that is strongly defended by military, that meaning is also fine by me :-)

Re:Encouraging vs. enforcing.

[robocrop]

I didn't want to reply anymore, feeding trolls and all that

Sure you don't. And we all know who the troll is here.

Contrast fort with forte

A common misconception borne of ignorance. The proper word to signify strength in French is "fort", not "forte". You can ask any French-speaking person, but in the meantime from dictionary.com:

forte: French fort, from Old French, strong, from Latin fortis. See fort.

The term "forte" is a common misspelling which is used so frequently that it is documented. But it is still incorrect. Much like "ain't", which can be found in the dictionary, but still is not proper grammar.

I'm Hungarian

[Quasar1999]

I'm Hungarian, and a progammer, you insensitive clod!

Seriously, Hungarian notation was great... back in the 80's... and only at Microsoft... Let it die already... or at the very least, stop calling it Hungarian... One single Hungarain born, American residing, developer working at Microsoft came up with it... Why the hell don't they call it the charles notation?

separate the GUI and the activity

[oo_waratah]

I wrote an application that worked on Windows, Unix, Linux, and mainframe. I wrote the GUI separately calling the library function then a simple command line version for Unix.

What I should have done is totally separate the GUI and the application entirely. I could rewrite the GUI in in a portable framework on linux faster than any port of the Windows software. I could then install the framework on all the windows desktops and have them work the same. Not port but total rewrite in a portable framework.

Problem with a lot of GUI code is that the business logic becomes intertwined with the GUI logic. It is incredibly easy to do especially with the Rapid Application Development (RAD) tools and this cause nightmares in porting if your RAD tool is not cross platform.

There was no court loss for WxWidgets.

[Futurepower(R)]

There was no court loss for WxWidgets. Microsoft challenged the WxWidgets team over the name WxWindows, and they decided not to fight. This was sensible, since the law in Great Britain is more supportive of big companies than even that of the United States.

Story about Lindows: http://www.vnunet.com/news/1130639

Re:Portable code... Pretty Much Impossible

[skeptictank]

It can be done for different operating systems running on exactly the same computer hardware if you are willing to add more complexity (some times the complexity you add to make it portable can exceed the complexity of the program it's self) to your code. But once you factor in different computer hardware, it's usually easier to have a different library of source code at some level than it is to try to write uber-generic code that runs on all computers ever made.

Re:There's a fine standard for inter-process mutex

[kemelma]

yeah sure .. i knew this option ... but, as far as i remember, last time i checked it not worked properly .. is it possible to use it with completely not related (by fork) processes ? ...

anywayz the not-so-famous author of the article did not mention this option at all ...

Re:There's a fine standard for inter-process mutex

[Jamie Lokier]

is it possible to use it with completely not related (by fork) processes ?

I believe it works with NPTL threads (the current Linux threading library) - if you map a file or shared memory so it's visible in both processes, then you can initialise the pshared mutex and use it from both.

With the older LinuxThreads, I'd be surprised if it works.

-- Jamie

Re:There's a fine standard for inter-process mutex

[kemelma]

yeah .. gotta check it .. as always there are different NPTL support in various kernels/glibc-s .. :)

thanks,
-M

IBM writes buggy code?

[the_arrow]

In one of the first Linux code snippets in part 1, I found this piece of code:

int processId;

/* stuff removed here by poster for readability... */

if( ( *processId = fork() ) == 0 ) // Create child

This rather obvious error was the first thing I saw when just glancing quickly at the code. I hope that the rest of IBMs code isn't as shabby.

So are programs written in Ruby...

[leonbrooks]

...but they don't have that pause at the beginning while a 20MB+ VM spins up, they don't have Microsoft shipping mutant versions of the standard, and they're a lot more fun to write.

Finally, as a Java afficiondo, you can have the best of both worlds in at least two different ways as well.

A lot depends on what you mean by less efficient

[leonbrooks]

Sometimes a program can be a lot more efficient if it wasn't hobbled by starting with the only available native approach to doing things. Portability generally equals abstraction, and that abstraction can be valuable. The incredible number of applications badly nobbled by being jammed into Microsoft's bizarre idea of an MDI is a long-standing example.

And of course the time-consuming part goes away when you factor in the pain in tracking API changes and chasing down weird bugs when you tightly integrate, problems whiach are a lot more transparent with a more generalised set of underpinnings. This is not helped by the lack of alternate debugging platforms, on which you can quickly find out whether the problem lies within your code or the system you're writing to, not to mention flushing out subtler bugs by being able to change fundamental things like endian-ness and word size.

Then when the platform you tightly integrated with gets obsoleted, or your major client(s) change platforms, or the API you integrated with suddenly becomes expensive (as happened with MS-Office after they undermined their visible competition) you're up sheeite creek in a barbed-wire canoe, sans paddle.

Answered!

[leonbrooks]

...in an "I link". (-:

Application should be written to be portable

[Anonymous Coward]

If you can't use 100% Java and most of your Windows specific code is Interface/Graphics related:

• Use MinGW to develop pure C/C++ stuff.
• Use Eclipse's SWT/JFace to write user interfaces, compile library from it
• You can get .exe binaries with gcj + some hacking

Port Windows specific C/C++ code. There shouldn't be too much of it because all GUI code is in Java. So porting process should be quite painless. You still have advantages of C/C++.