Do you think it's worth working on executi
Project: | JNode Core |
Component: | Code |
Category: | task |
Priority: | minor |
Assigned: | Unassigned |
Status: | by design |
Jump to:
Description
Do you think it's worth working on executing MS PE executable format?
I'm interested in working on this task.
I'll be glad to see your comments.
Thanks
Faran Negarestan
- Login to post comments
What's the benefit?
I'm not sure what the benefit would be?
JNode can not execute native code, we even don't have JNI support and PE executables are allways binaries I guess?
Peter
Benefit of executing native code
I think executing MS PE is a great feat becasue it opens new horizons of usefulness for this OS but it may not be in accordance with jnode development philosophy. I want to know that binary compatibility with windows is a technical issue or a theoretical matter ?
Use another OS instead
Hi
There is a great (for some) OS that runs PE files. It is called Windows and probably Vista will also run them.
Since JNode is intended to run java programs and there are huge technical and mindset issues to make this work, we'll not honour this request.
Kind regards,
Ewout
PE or ELF or COFF or
PE or ELF or COFF or something else doesn't matter,
native execution "to be or not to be - wat is asked for", as I understand.
Well, from point of view of usability it may be preferrable using pure java application instead something likes "my old good Norton Commander"
BUT: sometimes we may whish to add some processor/architecture specific code to hardware driver, which may NOT be added automatically by compiler/assembler for some reason.
Isn't that a point to support native code "sections" someday in future?
Try fixing the compiler / nano-kernel
If we come across a (non-hypothetical) device like this, the first options should be to change the compiler to generate the required instructions, or to extend the nano-kernel APIs with a new native method to do the job.
The only reason I can think of for supporting native code sections would be to allow proprietary binary-only device drivers to be used with JNode; e.g. for those pesky 'winmodem' devices some of us are stuck with. IMO, that eventuality is years away.
Such devices are quite
Such devices are quite materialistic (for example linux-2.6.xx/arch/arm/mach-pxa).
I'll explain what I mean - some smarty RISC machines
use processor-clone-specific-coprocessors.
Instructions for the may not be generated directly by compiler
as coprocessors may have internal state and even require execute some commands with interrupts disabled.
PXA processor control power management (clocks switching,suspend, resume, turn off peripherials ) through ASM instructions for coprocessor. Support of such features likely need some kind of custom (board specific) native code execution.
Anyway I'm absolutely agree that first encounter the problem in real life and then let's try to solve it (but NOT vise versa)!!!
#1
JNode is a Java operating system. There is no attempt to ever run any other binary formats.