Skip to main content

CDC Windows port

10 replies [Last post]
olaf_razzoli
Offline
Joined: 2006-12-04

Hi all

I would like to know if the porting of the CDC for X86 and Windows 2000 (as reported in the cdc_porting_guide.pdf, table 3.6) will be available as open source.
I presume a similar version can be derived from the Linux porting currently available, but if such a port already exists I think it would be helpful.
Thanks in advance for any reply

Olaf Razzoli

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mores
Offline
Joined: 2005-01-21

What is the current state of WinCE/ARM ?

Are there any docs/wiki on how I can get it to build ?

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> What is the current state of WinCE/ARM ?
>
> Are there any docs/wiki on how I can get it to build ?
> [Message sent by forum member 'mores' (mores)]

Hi mores,

I've started a Wiki page on the WinCE/ARM port at:

http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedPlatforms...

For the latest info, Davy P. has posted the initial work that is needed
for the port at:

http://www.cs.kuleuven.be/~davy/phoneme.php

See the forum thread at:

http://forums.java.net/jive/thread.jspa?threadID=21524&tstart=0

Hope this helps. Let me know if you have any specific questions.

Hinkmond

> http://forums.java.net/jive/thread.jspa?messageID=197556
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

mores
Offline
Joined: 2005-01-21

Thanks.

I can now get to the "Know Problem of PPCPeers are broken".

I see many things documented in the forums...
Should these items be tracked in the "Issue Tracker" instead ??

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Thanks.
>
> I can now get to the "Know Problem of PPCPeers are broken".
>
> I see many things documented in the forums...
> Should these items be tracked in the "Issue Tracker" instead ??

Good question. I think for now, it's more informal since we should try
to get the first Pocket PC port back up and running with the same
functionality as it had back in 2003.

If there is a specific problem that is keeping you from making progress,
please feel free to bring it up as in issue on this forum.

After we get the initial port running OK, I think we should at that
point switch over to the more formal IssueTracker approach.

Would that be OK with you? Others (any comments)?

Thanks,
Hinkmond
> [Message sent by forum member 'mores' (mores)]
>
> http://forums.java.net/jive/thread.jspa?messageID=197967
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

garyradams
Offline
Joined: 2005-04-12

Just to add some additional motivation for the
Java ME runtime being used on various platforms,
you also should consider the optional packages
that are not generally available on the SE platform.
e.g.
JSR82 Bluetooth
JSR120/205 WMA 2.0
JSR177 SATSA
JSR179 Location

These JSRs require special hardware or network support
to be deployed on real platform ports. Emulation
drivers are provided for the tools environment,
but the real drivers often require something
special in the way of platform dependent device
drivers.

Gary Adams

cjplummer
Offline
Joined: 2006-10-16

Yes, there will be a Windows 2000 port available "very soon now". I'd like to be more specific, but I don't think I should be quoting internal schedules here. Windows 2000 support will be part of the phoneME Advanced mr2 release, which will include ports for the following (in various states of working order)

Windows/x86
WinCE/ARM
WinCE/MIPS
Linux/ARM
Linux/MIPS
Linux/PowerPC
Linux/x86
Linux/Sparc
VxWorks/x86
VxWorks/Sparc
Symbian/x86
Symbian/ARM
MacOSX/PowerPC
Solaris/Sparc

Like I said, these ports will be in various states of working order, and will also be on the subversion repository trunk, which means at any point in time one or more may be broken.

For the initial mr2 release, I suspect all but the VxWorks, Symbian, and WinCE/MIPS ports should be in fairly good working order. VxWorks is still based on CDC 1.0, so needs some porting work to CDC 1.1 just to get it to build. WinCE MIPS is also broken at the moment and not being maintained. Symbian has been worked on recently, but I'm not sure of the state. Also, the x86 JIT seems stable, but still needs some work, so it is off by default for Linux/x86 and Windows/x86.

Chris Plummer

ga24
Offline
Joined: 2004-01-18

Porting - sheesh....

This brings up something that has always bothered me - why aren't all of the JME products written in pure standard JSE Java? As in, eat your own dogfood...

After all, if the JSE java compiler itself can be written in Java (and has been for many years), why on earth can't/wasn't JME?

If it was some kind of a dubious decison made back in the day, why isn't this being fixed on a priority basis?

Its not a footprint issue, its not a performance issue (heck, you have to slow down the emulators to make them representative)... Its kinda mostly Java (at least for CLDC), but why isn't it all Java?

This looks bad for Java, needlessly (or, I await enlightenment), plus it brings up all of the usual "C" questions like this one, plus it requires actual porting work. This situation is so bad people aren't even asking about the Mac version....

(of course each major target must be tested, but, assuming no JSE bugs, native code, porting is free).

mlam
Offline
Joined: 2006-10-13

Dear ga24,

JavaME is not just about a development tool (perhaps you are thinking of something like the Wireless Toolkit which has an emulator for development purposes to simulate JavaME devices). Instead, the ports we speak of are for the virtual machine and underlying native component of the libraries that make up the real (not simulated) JavaME platform that gets deployed on small embedded devices. It is equivalent to the JRE of JavaSE. Hence, footprint and performance is an issue.

And respectfully, we don't think of JavaSE nor JavaME as dogfood (no offense intended to dogs or anyone). I hope that clears up the confusion. Thank you.

Mark

ga24
Offline
Joined: 2004-01-18

Hi Mark:

1. "eat your own dogfood" is an expression sometimes used by developers, at least in some geographical areas, to refer a company using their own product. It is not intended to be a criticism, or to suggest that a product is only fit for dogs and/or is inferior. It is also not intended to make a statement about dogs, good or bad.

It would appear that a better expression would be "eat what you cook". I, however, did not come up with the expression.

The point is to "serve" the product to yourself before you serve it to others. And if you don't use it yourself, when you can (i.e. in the CDC and CLDC development kits in the case of Sun), you're not "serving" it.

You raise a good point that this expression would be off-putting to someone who is not familiar with it.

Please do not be off-put - that was not the intention.

Ah, the dangers of slang/jargon :).

2. The original question was regarding X86 and Windows 2000.

Looking up in the referenced document, indeed, there is a list of hosted operating systems and targets, and they're all over the map. In other words, the CDC development, emulation and transfer application is not written in Java.

If it was written in Java, all platforms would support all devices. Plus, the document makes reference to "C" libraries.

My question is why isn't CDC/CLDC written in Java, since to do otherwise is extra work, particularly now, when the supported platforms are being expanded.

Rather than port the application all over the place, why not rewrite all the non-Java parts in Java?

3. I am speaking from a JME developer perspective, not a JME device manufacturer perspective. And referring to the development environment, including the JME compiler, emulator and device communication software, not the device itself.

Glenn

mlam
Offline
Joined: 2006-10-13

Hi Glenn,
1. I understood your use of the term. I wasn't offended, but thanks for your clarification.

2. I'm not sure which specific document you were referring to, but I think the CDC documents usually refer to availability of ports of the CDC runtime (as opposed to CDC tools, though some CDC tools do make use of the CDC runtime ports). The list of ports is all over the map because that is how many types of device platforms that the CDC runtime port is available for (in varying states of working order).

Regarding an x86 and Windows 2000 port, we understood the question to mean a port of the CDC runtime, not the tools. Some people do use x86 and Windows 2000 in embedded devices and may want to run the smaller CDC instead of the full JavaSE for various reasons. Or some people may want an actual port of CDC for their desktops. It is not out of the question.

Regarding ports of the tools, there are various reasons (technical or otherwise) why the emulation is not entirely done on top of JavaSE. I don't speak for the tools team, but my educated guess is that one reason is to give application developers a more realistic feel of the JavaME VMs and libraries. Another is that the code for the JavaME VMs as written in C do exists already from the runtime ports, while an emulator written in the Java language that approximates the same thing does not. Hence, it is actually less effort to use the actual VMs and runtimes that will be deployed in the target devices (though with a few modifications) than to use another emulator that requires a lot more work to implement but may or may not actually give the developer the feel of the real target VM. Your perspective on whether this is a good idea or not may vary depending on your development needs.

3. I understand your perspective as a JavaME application developer. But I think you misunderstood the intent of the available ports list. That's all I was trying to clarify.

Regards,
Mark