The revolution in porting(i386 only)

[Kemp]

I personally call "impossible" on your claims Your libraries will be providing this generic API, sure, but these libraries will still have to be talking to the particular OS the app is being run on, which means you have two options:

• The libraries are compiled along with the app, which means it will be cross-platform in terms of no editing required of the source but it will still have to be recompiled for each platform
• You provide a seperate virtual machine for each platform, so the app will run fine anywhere that has this virtual machine but you'll have to find a way to link the program into the machine at runtime. In this case you have just created Java with C syntax and no way to enforce security (due to pointers).

[ark]

It's the fear of pointers that gives Java it's "magical" portability.

Not at all. C and C++ are extremely portable languages and the concept of pointers is embodied in them. Compilers just tend to target specific hardware. I'll come back to this.

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.

The difference between a Java bytecode and a machine language for an imaginary piece of hardware is not clear to me from this. Java's portability comes from two major aspects: 1) that it targets a virtual machine (again, it's not clear to me why the JVM in particular has some property that makes it especially suited to portability that cannot be duplicated in other languages) and 2) it provides an extensive standard library that is intended to hide all OS-dependent libraries, which is one of the primary causes of portability headaches in C and C++.

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.

Making a virtual machine language that the C or C++ compiler would target. It's true, faking direct memory access would probably kill performance, but then there's no reason why it has to be done. Contrary to the opinion of some (not necessarily you), C++ pointers can be used quite effectively in the same manner as Java references; saying that the trickier pointer operations are slow on your hardware does not negate their usefulness in general, nor does it cripple the language. In fact, I rarely ever do pointer arithmetic in C++ and the only time I ever do non-portable casting is when dealing with OS-specific C APIs.

It might require using the languages in ways different than you would on a different hardware platform, but that doesn't mean it can't be done. C++ would likely be more pleasant to deal with, because an OO library seems to cover issues like strings more simply (though even in C I don't see where the situation would be all that different from using the str functions, many of which are highly optimized internally by the library author).

Write a virtual machine that emulated i386? Have you tried Bochs?

No, I haven't.

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

Most of the hardware-specific items in C or C++ are compiler hints instead of requirements (in particular, I'm thinking of register here). I don't really see sizeof as a problem, even though it would be of reduced usefulness in targeting a VM, since it would presumably always return the same size for whatever given data type you were asking for (much the same way that Java "solves" the portability problem by simply declaring that ints are always 32-bit twos-complement).

Now, whether someone could have written a VM for C++ to target and not written a Java to go along with it at the time that Java came out, I can't say for sure. It may be that an ultra-hyped new language was needed for the whole VM for portability thing to catch on.

[zloba]

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?

Better for whom? (.NET programmers, Java programmers, C/C++ programmers)

and by "XYZ programmers" i mean those who work specifically in XYZ, by choice or necessity, and perhaps have lots of code in it.

but at least Java has been around for many years and has lots of APIs and third-party libraries to choose from...

so has C/C++ and Posix. (which the poster says the project implements).

[Kemp]

so has C/C++ and Posix. (which the poster says the project implements).

Actually, he just said it was like POSIX as it tries to provide a standard API. The "success" of POSIX in achieving this is, of course, another matter entirely.

[zloba]

he just said it was like POSIX as it tries to provide a standard API

my mistake. i meant whatever "C standard library working except for the functions in math.h".

though i think it can be made to just provde a good Posix-like API like that, filling the gaps where they exist. (given that Posix is implemented in most systems already, to some extent)

i'm not too enthusiastic about the XPAPI thing though, unless it addresses those annoying portability issues better than Posix.

[Colonel Kernel]

Sounds like you've used some vendor specific libraries

We're using Apache Axis, which, lo and behold, IBM does not offer support for on WebSphere. I wouldn't call Axis "vendor-specific" exactly...

by definition a J2EE app server has portable libraries.

Whenever there's a standard with definitions in it, vendors love to ignore those definitions.

As for the web services stuff the answer is yes, take a look at the latest version of JAX-WS and JAXB.

I think part of the problem is that we're not allowed to use the "latest version" of anything, because the customers who will be using this thing are very conservative and slow to upgrade. The webservices situation before the latest version of whatever looks pretty bleak to us.

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?

For Java, I've already mentioned the custom serialization issue that I've encountered. I haven't found any similar issues in the Java APIs themselves... it's the holes that are filled by third parties where the problems occur. Until these holes are filled by the "standard" Java class library, there will be portability problems. As for POSIX, I have less experience with it, but I have noticed that different OSes support different subsets of POSIX. That's not really portable. It certainly isn't binary portable, which is what this thread is about.

[iammisc]

I personally call "impossible" on your claims Your libraries will be providing this generic API, sure, but these libraries will still have to be talking to the particular OS the app is being run on, which means you have two options:

* The libraries are compiled along with the app, which means it will be cross-platform in terms of no editing required of the source but it will still have to be recompiled for each platform
* You provide a seperate virtual machine for each platform, so the app will run fine anywhere that has this virtual machine but you'll have to find a way to link the program into the machine at runtime. In this case you have just created Java with C syntax and no way to enforce security (due to pointers).

Let me get thsi straight. WINE loads PE files right? WINE has an api right? It uses the windows API. But imagine a WINE which used its own api that doesn't need to implement all these "bugs and undocumented functions" that is the Windows 32 API. This is exactly what XPAPI is doing. There is no cpu architecture portability but rather operating system portability. It is NOT a bytecode interpreter. IT basically does the task of the operating system: loading and linking executable files. After all the executable files ARE i386 bytecode, the only thing left to fo is to relocate memory. which the linker already does. LOOK at the source and try to understand before saying that something is impossible when it ALREADY WORKS.

Your statement of impossibility is firstly wrong BECAUSE I have already compiled and ran the EXACT SAME BINARY on both Windows and Linux. So it is possible.

What makes this different is the ability for programmers to use any language that gcc supports(ada,fortran, c, c++ ,AFAIK pascal) and run it on different operating systems. Of course a native XPAPI standard library would have to be written.

Maybe I haven't done a good job of explaining.

This is how the XPAPI works:

I compile an XPAPI program on Windows.

I load the program with XPAL(the application loader). Which maps the file to memory. Reads the PE headers. Reads the pe imports.. Fixes up the relocations. Links the executable file correctly and finally calls the start point.

The program can then call functions from the imported libraries.

The program exits.

XPAL says "XPAL: Finished"

And you finish the application.

Now I can copy this file over to Linux and this process will happen again except the API will act in the same way. Right now it just maps to system functions. But soon there will be a completely expected behavior on all operating systems.

Once again this project is not:
-a C compiler that compiles into a bytecode
-not even a C compiler. IT is a set of gcc arguments and linker scripts
-not a bytecode interpreter
-not a cross-architecture thing

It IS:
-a set of gcc arguments and linker scripts which allow you to create xpal programs
-a set of libraries which can be native to the operating system or to XPAL. These libraries provide consistent api and behavior. You must realize that I don't statically link anything. PE has a nifty feature to generate import libraries which basically allow me to import from fake dll's which xpal maps to the correct xpal written one which provides the api's
-an runtime application loader and linker
-a cross-operating system "thing"

XPAPI=The Cross-platform API
XPAL-The Cross-platform Application Loader

The term cross-platform is confusing but XOSAPI looks bad.

Please stop telling me it won't work when It already does.

Thank you. Have a GREAT day.

[Colonel Kernel]

What makes this different is the ability for programmers to use any language that gcc supports(ada,fortran, c, c++ ,AFAIK pascal) and run it on different operating systems. Of course a native XPAPI standard library would have to be written.

I understand what you've described, but you're assuming that what you've already done is the hard part. It's not. Writing those native XPAPI standard libraries is much harder, but even it isn't the hardest part. Convincing everyone to use your APIs, now that's going to be hard.

I still haven't heard a compelling reason why I should want to learn a brand new (mostly non-existent) API with no commercial support and write all my cross-OS code in it. There are other things out there that already solve this problem adequately, and for which I can get lots of support (and that I won't get fired for using).

I'm with Solar on this one.

[iammisc]

So if I complete the xpapi which I hope to do and I can provide some compelling reason to do it then you will use it?

Okay, here goes. I can't complete it right now and I can't really convince you to use it. But if you want you can compile your application many times each on a new operating system, requiring a different install for each or you can use the xpapi. Use what you want, it is not my choice it is yours.

Now if you were like me about 5 years ago and didn't have a linux computer and you wanted your program to run on linux too without you having to worry about it and learning all the linux or learning all the windows stuff, then use the xpapi. It should save a lot of trouble.

[Candy]

You're making an API with framework / library that is crossplatform and that is like normal programs but cross-platform? And that features its own binary loader?

Add it to the list of .NET with 4 languages (which is crossplatform), J2EE, Wine. These all feature exactly that with the given features. The third is the only that's based on an existing API and that supports x86 bytecode, yours would be a mix between the 1st and the 3rd.

[iammisc]

Please do not compare my project to Java because java is not native hardware run machine code and to wine because they have to implement a buggy, undocumented api.

I know with the help of mono you can run .net on other platforms. .Net is a good idea, but I am a little wary of Microsoft stuff. If they really meant it to run on other operating systems, then why didn't they port it to linux as well?

[Candy]

Please do not compare my project to Java because java is not native hardware run machine code

Bullshit. JIT compiles it to machine code before executing, causing a minor startup performance hit but no runtime penalties.

and to wine because they have to implement a buggy, undocumented api.

My point of the comparison was that you are between the two. The only advantage not implementing the Windows API has for you is not being required to hack around. It removes the big advantage though, you don't have a predefined backing of applications.

I know with the help of mono you can run .net on other platforms. .Net is a good idea, but I am a little wary of Microsoft stuff. If they really meant it to run on other operating systems, then why didn't they port it to linux as well?

.NET is equal to Java, it's also not binary code and it's also JIT compiled. Do not separate them, that's prejudice.

[iammisc]

Bullshit. JIT compiles it to machine code before executing, causing a minor startup performance hit but no runtime penalties.

Yeah. but it has some penalty. Also, with java you are limited to one language: java.

.NET is equal to Java, it's also not binary code and it's also JIT compiled. Do not separate them, that's prejudice.

Ok so i'm prejudiced against programming languages.

[Kemp]

Heh, just because I find this semi-flamewar amusing I'll chuck in some more (dis)information.

Also, with java you are limited to one language: java

You can write a program to convert any other language into JVM compatible bytecode, it may require some hacky solutions if the language isn't designed to be safe, but it can be done if people wanted. What is produced has no inherent dependancy on the particular syntax of the text you wrote.

Off-topic randomness aside...

You've done a better job of explaining since my post that you quoted, so I see where you're coming from now. It still sounds like you're implementing my second method.

You provide a seperate virtual machine for each platform, so the app will run fine anywhere that has this virtual machine but you'll have to find a way to link the program into the machine at runtime. In this case you have just created Java with C syntax and no way to enforce security (due to pointers).

I load the program with XPAL(the application loader). Which maps the file to memory. Reads the PE headers. Reads the pe imports.. Fixes up the relocations. Links the executable file correctly and finally calls the start point.

The program can then call functions from the imported libraries.

Don't take offense when people compare what you have written to Java or .NET apps, it is very nearly the same idea, you are merely running x86 machine code in your virtual environment rather than JVM bytecode or whatever .NET uses. Virtual environment doesn't imply that the code is cross-platform bytecode or anything like that, it simply means that the environment the app sees isn't the real one that exists on the machine, in this case the system API it can use isn't the one provided by the host OS. The whole bytecode confusion presumably descends from the first famous one being the JVM. To clarify my point, during execution your system and the JVM (afaik) are very similar concepts. Both are running machine code linked into their own API libraries. The fact the Java apps start off as bytecode is irrelevant to this point. Further, comparing your system to the JVM should not be taken as so much of an insult, it is simply a well-known system that we can use to help visualise yours due to the similarities between them.

I hope this post (possibly my longest post for quite a while) will help you understand where some of our comments are coming from. I personally would like to see where your idea ends up, though the hardest part is definately ahead of you. As an example of something that you may want to look out for, you'll probably find that adding an extra layer between the app and the graphics routines in the OS will slow it down considerably, and certainly anything that likes to directly access the drivers will probably be absolutely killed.

[Candy]

Don't misunderstand me, I can see clear advantages to your technique compared to both Java and .NET, as well as comparing it with Wine. I think your idea is a pretty darn good one at that, but I do think it's going to need quite a good supporting library and implicit inherent support for both developers and users. It's going to need more than a good idea.