Hello
I was wondering if the platform builderr IDE from windows is free?
i tried to search for it on their website but could not find it, just found the updates
It is not free, but there is an evaluation version for 180 days (if I am not mistaking). Sorry, don't remember the link, but it's there somewhere.
P.S. Any images built with it will only work for a year I think.
Yeah, it's hardly worth downloading, but the trial version suffices for most of our needs. Buy from MS's website.
V
thanks for the reply
is there anything comparable which is available for free
No...
Exactly what do you want to do?
Build a ROM for a new device from scratch? If so then you have no choice, you must by the PB.
But if you only need some of its functionality like creating MUI for localization, perhaps we can recommend an alternative. Just tell us what you need it for.
FYI, the platform builder trial can't be used to build a rom for our devices, from scratch. You require the system drivers etc that only the OEM (ie HTC) would have available. Or some very very very well connected friends.
V
Platform Builder available from MS site can be used to build only WinCE 5.0 ROMs. Windows Mobile ROMs are build with Platform Builder 5.0 for Windows Mobile (or something like that). MS regularly releases updates for it in the form of AKUs.
Unfortunately PB for WM or AKUs are nowhere available for free, and their price is too huge.
And even if you'l get them, you'll also need a BSP for your device. It is extremely difficult to create it from scratch without having any hardware information, but Linux source code for your device can be useful.
I come from years of Symbian PDA owning/development, and I had several languages available, besides C++: OPL (Basic-like), PersonalJava, J2ME, MidletPascal, Python, Jython, m-Shell... all of them for FREE!
What are the alternatives on a WM machine? Can I only develop in C++, or have I some FREE alternatives?
do you mean languages or programming envioments ?
embedded visual studio is free if you mean envioments
Rudegar said:
do you mean languages or programming envioments ?
Click to expand...
Click to collapse
both.
I just found info about the embedded visual studio you talk about. I see c++ allows API access,but VB cannot. Any workaround?
I also found WABA and EWE: for the first, site states "you can write native code by modifing WABA sources"; I guess it means writing additional C++ code?
for the second, it says it allows accessing native functions: does it mean you can use EWE to start/receive calls, send/receive SMS, access COM port,...?
The following languages/interpreters are used nicely on HTC Typhoon:
1. Jython 2.2 for Java 1.1.8 SE (along with Personal Java CE 1.1 and the JDK runtime/library);
2. Perl CE 5.8.0 from the Rainer-Keuchel portings;
3. nScriptm HPCARM 0.104 by Nakka/ S/K;
4. Rebol CE 1.5.5 by Carl Sassenrath.
An advanced application manager such as SPHelper is needed to solve the pointing device stuff ...
There is a Smartphone patch for Python CE from one of the developers at SF.net released in March I did not try yet, (perhaps someone interested will) ...
anfd said:
The following languages/interpreters are used nicely on HTC Typhoon:
1. Jython 2.2 for Java 1.1.8 SE (along with Personal Java CE 1.1 and the JDK runtime/library);
2. Perl CE 5.8.0 from the Rainer-Keuchel portings;
3. nScriptm HPCARM 0.104 by Nakka/ S/K;
4. Rebol CE 1.5.5 by Carl Sassenrath.
An advanced application manager such as SPHelper is needed to solve the pointing device stuff ...
There is a Smartphone patch for Python CE from one of the developers at SF.net released in March I did not try yet, (perhaps someone interested will) ...
Click to expand...
Click to collapse
thanks, that's very interesting, especially Jython: Is Java 1.1.8 supported by all HTC devices?
Yupp, it sure is ... but Sun Microsystems stopped releasing it alltogether to the end user, R.I.P Personal Java (this was the actual compatibility with CE) ...
The link is:
isiam.blogspot.com (I`ve made it as described) ...
anfd said:
Yupp, it sure is ... but Sun Microsystems stopped releasing it alltogether to the end user, R.I.P Personal Java (this was the actual compatibility with CE) ...
The link is:
isiam.blogspot.com (I`ve made it as described) ...
Click to expand...
Click to collapse
that blog is just the reason for which I asked about PersonalJava compatibility
I use PJ compatible PDAs since several years (SonyEricsson p800, Motorola a1000...), and I'd like to continue being able to use PJ applications even when I'll pass to Windows PDA!
I guess you can add Python CE v2.5 to that list as well now ...
It`ll be working fine on every single WM version existing, although I did not test`em all:
http://downloads.sourceforge.net/pythonce/PythonCE.WM.CAB?modtime=1191509518&big_mirror=0
Hi from EugeniaDevelopment chef,
This project is intended for porting the Windows Embedded CE 6.0 Kernel to Windows Mobile devices, based on Qualcomm MSM chipsets.
As you know, the MSM7 series chipsets are based on ARM11 CPUs.
Or more detailed... they're based on ARM1136EJ-S CPU!
Then... WHY this post?!?
I'd like to share with all the community my hard work for compiling the CE6 kernel for ARM11 devices, supporting ARMv6 instruction set.
The CE6 kernel is based on another kernel architecture, making the devices running it SO FAST...
I would like to say that this kernel IS compatible with current Windows Mobile builds, at least 6.5/6.5.x builds, as 6.5.x builds are alphas of Windows Mobile 7, based on CE6 kernel.
Infact, WM7 will be based on CE6 instead of current WM6.1/6.5/6.5.x that are all based on CE5.2 kernel codebase.
Now, I need some help to cook it in our ROMs because the MSXIPKernel i've generated remoduling all dlls is larger than old 5.2 XIP.
There are even some differencies from 5.2 XIP!
NK.exe is differently used: the base modules of MSXIPKernel are different and device.exe and filesys.exe now are both .dll due to the different architecture of the kernel that now integrates all in an unique process, both files in kernel mode and not in userspace anymore!
So, I've tried myself to port it to my ROMs before posting it there but with no luck.
I'm using the last ErviusVisualKitchen that includes bepe's platformrebuilder.exe... that CRASHES everytime I try to build the ROM with ALL dlls and modules of CE6 kernel.
If I integrate only coredll.dll module the kitchen goes on and builds the XIP and the ROM, but it won't boot because the new coredll looks for device and filesys dlls that in 5.2 are executables.
If I try to integrate new dll modules (device and filesys), the platformrebuilder will crash.
So, I'm asking for your help to making this fabulous project to continue and to make it working for having the FASTEST devices ever!
Here are the dlls, not remoduled with ErviusKitchen.
I decided to give you the original binaries because maybe ErviusKitchen won't remodule them correctly, making platformrebuilder to crash.
Ouh, and.. this kernel will work on all devices that has got Qualcomm MSM7xxx series chipsets..
For example: HTC Touch Diamond, TouchHD, TouchPro, Kaiser, Diamond2, TouchPro2... and more, more devices....
I hope I can get all of your help.
Anyway, you can download it here:
CE 6.0R2 Kernel
...If you want, I can post the entire ROM built with Platform Builder (not working on our HTC devices, as it's build for generic ARM1136EJ-S CPU).
NOTE: As for the device-specific drivers, we have OEMXIPKernel
Thank you all
How to use ?
Try sending a private msg to bepe, see if he can adjust his PRB to account for your kernel.
Okay, thank you
...if anyone has other ideas, write
this is probably the most impotant project on this forum.
Mods please make a sticky.
Converting to module didn't help.
Imageinfo.bin manipulation didn't work also.
Did you try porting it the old way? (XIPPORT)
If THAT doesn't work, try PMing bepe.
Tried to integrate this kernel into my ROM...
I copyed all the .dll's into MSXIPKERNEL
ROM - created without any ERRORS
Now i gonna try it...
Whoops... My mistake - i builded 21054 kernel without errors... 23049 - Platformbuilder error...
OMG stick this NOW, this is ground breaking stuff, da_g,nue2chem,bepe you should all take a look at this thread OMG!!!!
I think you may be a little confused?
It appears you have posted the MSXIPKernel package compiled from Embedded CE 6.0, compiled for ARM.
These CE 6.0 Binaries are not compatbile with CE 5.2, so attempting to use them in a Windows Mobile 6.x ROM as-is will not work. You state that "NOTE: As for the device-specific drivers, we have OEMXIPKernel" - do you mean the existing OEMXIPKernel, compiled against WM 6/CE5.2, if so this will not work at all with CE 6. I assume when you say "Ouh, and.. this kernel will work on all devices that has got Qualcomm MSM7xxx series chipsets.." you mean because it is compiled against ARMv6?
Also, you have posted several incorrect informations,
WM 7 is not based on CE6, but CE7.
WM 6.5.x is not in any way an alpha build of WM7. They are seperate code bases.
In short, to sum it up I don't think this project will be going very far unless you have access to whitepapers documenting the full hardware and are willing to code the OEM bits yourself using this info. I don't think it's worth doing though as you would be using the CE interface, and it would all need to be done over again when WM7 comes around...
Well, PRB doesn't crash for me in my visual kitchen when you add all other files from any other MSXIPKernel (dsm, rgu's etc).
Da_G said:
I think you may be a little confused?
It appears you have posted the MSXIPKernel package compiled from Embedded CE 6.0, compiled for ARM.
These CE 6.0 Binaries are not compatbile with CE 5.2, so attempting to use them in a Windows Mobile 6.x ROM as-is will not work. You state that "NOTE: As for the device-specific drivers, we have OEMXIPKernel" - do you mean the existing OEMXIPKernel, compiled against WM 6/CE5.2, if so this will not work at all with CE 6. I assume when you say "Ouh, and.. this kernel will work on all devices that has got Qualcomm MSM7xxx series chipsets.." you mean because it is compiled against ARMv6?
Also, you have posted several incorrect informations,
WM 7 is not based on CE6, but CE7.
WM 6.5.x is not in any way an alpha build of WM7. They are seperate code bases.
In short, to sum it up I don't think this project will be going very far unless you have access to whitepapers documenting the full hardware and are willing to code the OEM bits yourself using this info. I don't think it's worth doing though as you would be using the CE interface, and it would all need to be done over again when WM7 comes around...
Click to expand...
Click to collapse
I think they are all compatible with CE6.
CE6 has a different kernel architecture, but for drivers it all remains the same.
You're right, I'm not too updated, WM7 (Photon) is NOW based on CE7 Kernel, but if you search further, it initially was based on CE6 kernel Pre-Alphas of WM7 was CE6 based!
...and WM7 won't be usable with our devices, because it NEEDS a multitouch touchscreen, as you can see from minimum requirements by Microsoft.
Yes, for "it will work on all MSM7xxx" I mean that this is compiled against ARMv6.
All MSM7xxx chipsets has got a CPU that supports ARMv6 instructions set.
For example, MSM7201A (Diamond and other devices) has in its core an ARM1136EJ-S (yeah, the "J" was changed by Qualcomm, but it's an 1136EJ-S)!
And... the 5.2 kernel that we have now on our devices is compiled from Embedded CE 5.0 (updated) so it's compatible.
I didn't try porting with XIPPORT as the addresses with the CE6.0 Kernel are changed: it's larger than 5.2!
Well, it wouldnt hurt to TRY, right? I mean, the devices are pretty damn slow compared to android devices running on the same hardware, so if this COULD improve it, why not try it?
I'm sorry,
NK is very device specific, you cannot just take CE 6 NK and hope it'll magically work. We've been able to build CE6 ARM11 and Cortex for a long time, just press a few buttons in PB. But NK consists of OAL (OEM Adapation Layer) stuff, which is pretty device specific. More specifically, when NK gets to OEMInit, it'll simply fail, because this is where most of the initialization occurs, such as GPIO, MDDI client, NAND flash -etc. Even if you did get CE6 NK working, which would require you recompile CE6 with the OAL, which only HTC has, you would have to rewrite all the drivers since CE6 driver model changed a lot, (i.e., no more SetKMode(BOOL); - which HTC uses a lot).
Anyway, this project has been on the table for a while, and through a new (maybe old, well new for me) technique of disassemble-reassemble, we can maybe build an "Assembly" BSP that would let us run CE6. But its a lot of work, since again, ce6 driver model changed
Again, this topic has been repeated several times, so I will say what others have said in the past. If you have no clue about ARM assembly, please save your time, give up, and move on with other projects. A simple search will tell you about many people who got over-excited when they played with CE6 PB.
Da_ag. Why not give it a shot. This could open up the door to future developments beyond our wildest dreams for Windows Mobile. We, XDA as a community if we pull this off, might be able to create our own fully customized versions of Windows Mobile from the Kernel up. Also it would improve speed and usability of our current devices.
Please do not discount this project just because it looks hard. Isn't this the reason XDA was formed in the first place?
no2chem said:
I'm sorry,
NK is very device specific, you cannot just take CE 6 NK and hope it'll magically work.
Click to expand...
Click to collapse
CE6 doesn't even have NK(.exe) anymore say hello to kernel.dll and oal.exe! =)
kholk said:
I think they are all compatible with CE6.
CE6 has a different kernel architecture, but for drivers it all remains the same.
You're right, I'm not too updated, WM7 (Photon) is NOW based on CE7 Kernel, but if you search further, it initially was based on CE6 kernel Pre-Alphas of WM7 was CE6 based!
...and WM7 won't be usable with our devices, because it NEEDS a multitouch touchscreen, as you can see from minimum requirements by Microsoft.
Yes, for "it will work on all MSM7xxx" I mean that this is compiled against ARMv6.
All MSM7xxx chipsets has got a CPU that supports ARMv6 instructions set.
For example, MSM7201A (Diamond and other devices) has in its core an ARM1136EJ-S (yeah, the "J" was changed by Qualcomm, but it's an 1136EJ-S)!
And... the 5.2 kernel that we have now on our devices is compiled from Embedded CE 5.0 (updated) so it's compatible.
I didn't try porting with XIPPORT as the addresses with the CE6.0 Kernel are changed: it's larger than 5.2!
Click to expand...
Click to collapse
alright believe what you like but the facts will not change. no2chem told about it all already so I won't repeat him
Da_G said:
In short, to sum it up I don't think this project will be going very far unless you have access to whitepapers documenting the full hardware and are willing to code the OEM bits yourself using this info. I don't think it's worth doing though as you would be using the CE interface, and it would all need to be done over again when WM7 comes around...
Click to expand...
Click to collapse
you don't need access to so many papers. but they do ease the workload for you
again see what no2chem said... we're going to have lots of fun with this i guess.
I don't understand a thing, with this, you should be able to get CE 6 kernel without the BSP ?
cmonex said:
CE6 doesn't even have NK(.exe) anymore say hello to kernel.dll and oal.exe! =)
Click to expand...
Click to collapse
Right cmonex. I wanted to say that but you written before me
But.. now I've got a question.
IF CE6 doesn't have NK.exe anymore (and from what I see it doesn't have any NK.dll) and it's all based on OEM Adaptation Layer (OAL), THEN we won't use nk.exe anymore, right?
So.. CE5 uses PQOAL, monolithic kernel.
CE6 uses OAL, and it's all modular.
From THIS site, that explains the CE6 Kernel Architecture, I read the following:
"The OAL is linked with the generic kernel code to form the full kernel module."
Click to expand...
Click to collapse
"By splitting up the OAL from the generic parts two interesting things happen. First, the foundation for a well defined interface between the OAL and the kernel module is laid. It is no longer possible to just "extern" some kernel specific function in the OAL, as in the old monolithic architecture where the OEM sometimes use undocumented kernel functions to "backdoor" its way around some OAL "quirks" -something that may affect stability and compatibility of the kernel. In CE 6, the kernel functions are exported to the "oal.exe" as a function table (NKGLOBAL) as part of an initial handshake procedure. In the same way, OAL functions that are needed to support the core kernel are exported to "kern.dll" in a similar function table (OEMGLOBAL). "
Click to expand...
Click to collapse
And from MSDN I read the following:
So what did change? In CE6 we split up three components that previously linked together to make the kernel executable, nk.exe. CE5 the kernel, OAL and the Kernel Independent Transport Layer (KITL) all linked into nk.exe. In CE6 these are broken into kernel.dll, oal.exe and kitl.dll.
The primary reason for this change was updateability. In the past, if Microsoft released a kernel update, the OEM would have to take the updated kernel and link it again with their OAL to produce a new nk.exe. Now the OEM only has to distribute Microsoft’s new kernel.dll.
Click to expand...
Click to collapse
We CAN DO IT if we know how to split NK.exe into OAL and Kernel.
OR.. if we don't want to do never-used work, we need only to extract the OEM Adaptation Layer (OAL) from our current NK.exe.
Then we can link the OAL extracted from 5.2 Kernel to the NEW CE6 kernel.dll
Note that CE5 kernel does support the splitted modules, infact there are some BSPs that are built with OAL.exe/kernel.dll and NOT with NK.exe.
Read that on instructions for how to port a BSP from CE5 to CE6.
If someone can "extract" OAL from a Diamond NK.exe, I'll be happy to try if all works on MY device!
no, you can't just extract OAL from CE5 kernel, its linked at compile time into the fun monolithic kernel we know as NK. The architects of CE6 (in a smart move) seperated the OAL from kernel libs, much like the MDD-PDD model you see in many drivers since CE5.
So in ce6 you can just update the kernel by updating kernel.dll ideally. anyway like cmonex and i have said, just wait, we're working on reversing a bsp for rhod_w soon