The revolution in porting(i386 only)

[iammisc]

Look at http://sourceforge.net/projects/xpapi and http://xpapi.sourceforge.net.

Reply if you think this is useful.

[Solar]

Yes, sure it's useful... just like POSIX, wxwindows, GTK or any of the other cross-platform APIs...

Not trying to frustrate you, but what makes the XPApi different (aside from having yet to be implemented)?

[iammisc]

the point is THERE's NO NEED TO PORT!!!!! The whole point is that you just created a binary that will run unmodified on linux and windows(currently). You only have to distribute one binary for an application and it will work in the xpapi. It is not just an api. It is a PE loader, like wine, that will link the binary in userspace at runtime. This pe loader runs on linux and windows and can load the same executable image on both operating systems and link it to the correct shared library. So while it is like posix, wxWidgets, gtk, there is one thing thats different: no need to recompile.

I have proof too cuz the whole thing already works. I have got the C standard library working except for the functions in math.h which I will implement tomorrow. I will make a really limited release tomorrow as well.

Have fun.

[Colonel Kernel]

It is a PE loader, like wine

How is it different than WINE?

It's already possible to write binary-portable programs in Java that run on Windows and Linux. Ditto for C#, if you're using .NET on Windows and Mono on Linux. How is this better?

[Pype.Clicker]

btw, i see they're in "stage-1: planning", and the latest news announce "hurray, stdio.h and time.h are available" Couldn't access the rest of the website due to php errors ::)

i see no package released, either, so that justs seems to be a claim in the void to me ... they made a PE loader, but that's virtually all, right ?

[iammisc]

WINE is a pe loader. Correct. But it emulates the windows api. XPAPI on the other hand has its own api.

The website is not yet done. The homepage needs to be updated and a release has just been made which implements only the ANSI C standard C library.

I dont think you get the idea of the project. Wxwidgets motto is write once, compile anywhere. the xpapi's is compile once, run anywhere(i386 for now though).

Imagine compiling a program ONCE and running it on any operating system. This could potentially solve the lack of software for alternative operating systems.

[ark]

Imagine compiling a program ONCE and running it on any operating system. This could potentially solve the lack of software for alternative operating systems.

Java seems to have already proved that this works nicer in theory than in practice.

Still, I'd like to see more efforts of this nature for C and C++, if for no other reason than to forever put to rest the idiotic notion that Java has some magical properties that make it cross-platform where C and C++ are supposedly not (not meaning that as a Java bash so much as a lack-of-programmer-education bash).

[zloba]

i think this could be a useful idea, minor details aside.

[Solar]

So your peers aren't POSIX, wxwindows and GTK, but Java and .NET/mono... the question remains unanswered, what makes you so much better than the mainstream that someone should consider xpapi instead?

Get me right, this is 50% constructive criticism and 50% keeping you from essentially wasting your time on a "yet-another" type of project.

If it's for your entertainment value, fine. If it's for learning about how these things work, excellent. If it's for becoming a real alternative, you have to have an answer to the question above.

[chasetec]

Imagine compiling a program ONCE and running it on any operating system. This could potentially solve the lack of software for alternative operating systems.

Java does this but has no limits on cpu type other than the availablity of a JVM. Now that Java is getting relicensed and will start to be included in Linux distros I think you'll see alot more consumer apps in Java. I'm not saying it's not technically interesting but it just seems to be an unneeded middle ground between Java and POSIX.

Java seems to have already proved that this works nicer in theory than in practice.

Still, I'd like to see more efforts of this nature for C and C++, if for no other reason than to forever put to rest the idiotic notion that Java has some magical properties that make it cross-platform where C and C++ are supposedly not (not meaning that as a Java bash so much as a lack-of-programmer-education bash).

Huh? Java does, it's called a JVM along with just in time compilers. I recompile apps often for multiple OSes but it's alot easier to copy Java binaries.

[Schol-R-LEA]

Forget JVM; this sort of thing was already old when UCSD Pascal was a major operating system. I've said it before and I'll say it again: for all the sound and fury in the computer industry, there haven't been any really new developments since the introduction of the spreadsheet model and the LZ compression algorithm family, back in 1978. Most of what were are seeing today are refinements of things that were first developed between 1960 and 1970 - before most of the people here were born. Hell, I'm barely a year older than the original Unix myself. Curiously, Linus Torvalds was born the same month that Ritchie started working on the PDP-7 Unix (Dec 1969), but that's besides the point.

[Colonel Kernel]

Huh? Java does, it's called a JVM along with just in time compilers. I recompile apps often for multiple OSes but it's alot easier to copy Java binaries.

The JVM doesn't guarantee portability of an application -- at best it guarantees that the same code can (in theory) run on different machines, but it doesn't help with API differences. For example, every J2EE app server provides slightly different APIs for basic infrastructure (ever tried to implement an XML web service in Java that does custom serialization?) I'm not much of a UI guy, but what I've seen of cross-platform Java GUI APIs is also pretty weak. I read recently that Eclipse has its own home-grown UI framework for this reason.

Neither Java nor the original poster's project magically solve API portability problems, but at least Java has been around for many years and has lots of APIs and third-party libraries to choose from...

[ark]

Huh? Java does, it's called a JVM along with just in time compilers. I recompile apps often for multiple OSes but it's alot easier to copy Java binaries.

Java does what? I am well aware of what Java is and isn't capable of. My point was simply that some people seem to have an almost religious reverence for Java that the language doesn't deserve* - it achieves its "cross-platform" capabilities in reality by targeting one platform and only one platform: the JVM. Implementations of the JVM are written for different operating systems - in effect providing cross-platform abilities through the use of what might just as usefully be called "Java platform emulators".

Though some programmers whose programming experience can best be summed up as Java + a pathological fear of pointers seem to think this is a capability unique to Java and that anything that takes a similar approach (e.g., C#) is "copying Java", there is no reason why other languages which are more typically used to target specific hardware can't be used to target a VM instead and thus achieve the same cross-platform abilities that Java provides.

As for the theory vs. practice of "write once, run anywhere", while the widespread porting of the JVM has certainly made this a near-reality (and certainly the simpler the application the more likely it is to work as promised), the experience of the development world is that it is naive to assume that you really can write once and expect your code to run anywhere without at least some platform-specific debugging.

* Please note I use Java frequently and I am not saying that -all- or even -most- Java developers have this religious reverence, but I have personally observed this kind of attitude from many Java developers.

[chasetec]

The JVM doesn't guarantee portability of an application -- at best it guarantees that the same code can (in theory) run on different machines, but it doesn't help with API differences. For example, every J2EE app server provides slightly different APIs for basic infrastructure (ever tried to implement an XML web service in Java that does custom serialization?) I'm not much of a UI guy, but what I've seen of cross-platform Java GUI APIs is also pretty weak. I read recently that Eclipse has its own home-grown UI framework for this reason.

Sounds like you've used some vendor specific libraries, by definition a J2EE app server has portable libraries. As for the web services stuff the answer is yes, take a look at the latest version of JAX-WS and JAXB. About the Eclipse thing, you're talking about SWT. Swing had some limitations for a bit but Sun has fixed them now, in fact I read an article recently about Eclipse running on top of Swing.

Neither Java nor the original poster's project magically solve API portability problems, but at least Java has been around for many years and has lots of APIs and third-party libraries to choose from...

Maybe I don't get what you mean here because a Java SE JDK/JRE comes with a huge API. What is the API portability problem you have in mind that Java or POSIX for that matter doesn't solve?

[chasetec]

Huh? Java does, it's called a JVM along with just in time compilers. I recompile apps often for multiple OSes but it's alot easier to copy Java binaries.

Java does what? I am well aware of what Java is and isn't capable of. My point was simply that some people seem to have an almost religious reverence for Java that the language doesn't deserve* - it achieves its "cross-platform" capabilities in reality by targeting one platform and only one platform: the JVM. Implementations of the JVM are written for different operating systems - in effect providing cross-platform abilities through the use of what might just as usefully be called "Java platform emulators".

Though some programmers whose programming experience can best be summed up as Java + a pathological fear of pointers seem to think this is a capability unique to Java and that anything that takes a similar approach (e.g., C#) is "copying Java", there is no reason why other languages which are more typically used to target specific hardware can't be used to target a VM instead and thus achieve the same cross-platform abilities that Java provides.

As for the theory vs. practice of "write once, run anywhere", while the widespread porting of the JVM has certainly made this a near-reality (and certainly the simpler the application the more likely it is to work as promised), the experience of the development world is that it is naive to assume that you really can write once and expect your code to run anywhere without at least some platform-specific debugging.

* Please note I use Java frequently and I am not saying that -all- or even -most- Java developers have this religious reverence, but I have personally observed this kind of attitude from many Java developers.

It's the fear of pointers that gives Java it's "magical" portability. From a bytecode perspective the JVM and the language allow Java programs to be portable by preventing hardware specific programming. While some people consider the JVM a virtual piece of hardware it should more be looked at like a bytecode specification. Since JVMs don't really have to implement specific hardware it becomes easy(er) to translate bytecode to native code during execution and have only a little speed hit.

How exactly would you make C/C++ as portable as Java? Make a compiler that produced Java bytecode from a C program? Faking direct memory access would kill performance. Write a virtual machine that emulated i386? Have you tried Bochs? Languages that are typically used to target specific hardware have hardware specific concepts in the language themselves, not just the compiler. Even if you could somehow make a compiled C program portable across cpu architectures I'd really want to see you convince a Java programmer that it's portable after explaining the purpose of sizeof

In practice I see non-portable Java apps all the time but it's not usually a Java caused problem. More then likely it's because someone wrote some JNI code to run a old c lib or they've used some Oracle stored procedures, etc. I'm not religious about Java but I have yet to see the portablitly problems that people mention with Java. It almost always seems to be that someone used a vendor specific API when they shouldn't have of.