When will 0.3.15 release?

[hto]

The aforementioned Java-based GUI code is not a part of your C/C++ code. Your program just invokes it. It is merely an implementation detail, whether the OS code is native code or interpreted code.

[Z98]

Think you mean application code.

[hto]

No, OS code. The application code should be native machine code, that's what BlackRabbit wants.

[BlackRabbit]

No, OS code. The application code should be native machive code, that's what BlackRabbit wants.

Actually, technically, I am not trying to arrive at a situation where my application is native code. Windows Phone 8 already allows that.

I am trying to arrive at a situation where the image that is generated by my C/C++ is code is eaten by the CPU, and only by the CPU. I do not want a software interpreter of any kind in between eating the bytes of my image.

I want the same situation that I would get if I were to ALT-Tab to Ubuntu right now, write "Hello, World!" in C/C++, compile it GNU, and execute it.

[hto]

When it writes "Hello, World!" to a graphical terminal window with TrueType font, the TrueType bytecode interpreter is invoked. If the whole GUI code is interpreted, it's just another step in that direction.

[PascalDragon]

I am trying to arrive at a situation where the image that is generated by my C/C++ is code is eaten by the CPU, and only by the CPU. I do not want a software interpreter of any kind in between eating the bytes of my image.

And this is the case on Android. Your code compiled to a binary assembly language is nowhere interpreted by the Dalvik VM (that's why you must distribute a native library for each platform (armv5, armv6, x86, mips) that you want to support). There is only a call based interface between the native code and the VM (the Dalvik VM (which is written in native code as well, btw) keeps an additional stack (or multiple ones) to call to native code and to be called from native code).

Regards,
Sven

[BlackRabbit]

There is only a call based interface between the native code and the VM

I tried to be clear in previous posts, but there is obvious a disconnect somewhere. So let's try this:

I want a smartphone that comes with absolutely no VM, of any kind, anywhere. When the customer (who happens to be a software engineer), takes the phone out of the box, and hits the power button, s/he spend three days hunting around the OS, trying to find a VM of any kind, but is unsuccessful.

[PascalDragon]

I want a smartphone that comes with absolutely no VM, of any kind, anywhere. When the customer (who happens to be a software engineer), takes the phone out of the box, and hits the power button, s/he spend three days hunting around the OS, trying to find a VM of any kind, but is unsuccessful.

Ok, this was clear. Though I indeed thought that this might be what you want I've not read this out of your posts however.

Regards,
Sven

[BlackRabbit]

Ok, this was clear. Though I indeed thought that this might be what you want I've not read this out of your posts however.

One more thing:

After having such a "bare-bones" smartphone/OS combination, where there are no virtual machines on it whatsoever, and my C/C++ application has been running on the smartphone/OS combination for, say, three months, if someone comes to me and says...

I think it is pretty cool that you run your C/C++ applications on the bare-bones OS like that. I prefer, however, to run my applications a different way: I prefer to have a VM invoke a small bit of interpreted code written in [interpreted language], that, in-turn, invokes my C/C++ native code so that the native code executes against the physical CPU just like yours, but when I want to get access to some parts of the physical machine, I call back into [the interpreted interface], so that, for all practical purposes, my code is doing the same thing as your code...

...I would be OK with having the VM on the OS, as long as *I* am not required to write my applications in that way in order to use the smartphone/OS combination. Or, better said, I would like to write my application knowing that it will be executed under my preferred model on a smartphone owned by someone who will not have to do anything to get the phone into this state (root it).

Linux (not Android), of course, provides this model, so theoretically, someone could take vanilla Linux, start putting it on smartphones, and bring back, at least to a small percentage of devices in the smarthphone market, totally-unrestricted access to the OS on hand-held consumer devices. But my current applications use Windows device drivers, and am also heavily dependent upon Windows synchronization primitives like WaitForMultipleObjects and CreateWaitableTimer that do not port as well as I would like to Linux. This is one of the primary reasons that I am so interested in ReactOS. I want the raw OS primitives of Windows (that rules-out Linux), with unrestricted access to the device (that rules-out WP7 & WP8), and without having to pay Microsoft an embedded-OS license fee (that rules-out Windows Mobile & Windows Embedded).

As I mentioned earlier, I am not the only one who wants this. There are also corporations who want this.

[oswetto]

zguo committed changeset 58636 to the project
Branching for 0.3.15 release after two days of no response from a certain sphere of plasma.
1 hour ago