Related
This thread has been opened for those who are curious to know how the compiler "just in time".
Functional characteristics in general:
The JIT compiler translates bytecode into native machine code at runtime. This compilation process (also known as dynamic translation) is executed only once, and creates a link between the bytecode and the corresponding compiled code. The purpose of this process is to increase the speed in which to run Java programs.
A JIT compiler is based on two concepts in the recent run-time environments: bytecode compilation and dynamic compilation.
In a system for compiling bytecode as Perl, GNU, Java, etc.. The source code is translated into an intermediate representation known as bytecode. The bytecode is then interpreted or executed in a virtual machine (VM).
In a JIT environment, the first phase is the compilation of bytecodes, which transforms the source code in a portable and optimized intermediate representation, called bytecode. Subsequently, the byte code is installed on the target system. When the code is executed, the compiler execution environment translates into native machine code. The translation into machine code can occur for files or function: the functions can only be completed when they are to be executed, hence the name "just-in-time
The just-in-time compilation allows a good compromise between execution speed and code portability. During the compilation of the bytecode is executed most of the "heavy work", ie all those operations that require a long time to run, as the syntactic and semantic analysis of source code and a first phase of optimization, the compilation from bytecode to native code is much faster.
In particular for android devices:
Here some information on the operation related to android
Essentially, Java is usually translated from source to Java bytecode (an intermediate step between Java itself & processor specific machine code) when the app is compiled. When it is executed, this bytecode has to be interpreted into machine code. What JIT does is cache the results of such interpretation, so that, for example, if a particular section of bytecode is executed multiple times, it will only have to be interpreted that first time. JIT for Java has been around for a good while.
Android uses their own special Java Virtual Machine, which we hear of often - the Dalvik Virtual Machine. This works on similar principles to a typical JVM, but it produces a type of intermediate bytecode that is optimised for execution on devices with limited resources. This code, incidentally, is called a Dalvik Executable, which explains all the .dex sufficies in Android.
As this Dalvik Virtual Machine is relatively new, the further refinement of just in time compilation for it is only now reaching a stage where it's production ready - or at least hopefully will be soon. All pretty exciting as it can boost performance by around 200-300%
robin04 said:
I hope to have been sufficiently comprehensive
Click to expand...
Click to collapse
No, not really. I'm missing the point of this post . Is it a question, is it ment as an answer somewhere else? Did you click on 'post new topic' instead of 'post reply' somewhere?
dipje said:
No, not really. I'm missing the point of this post . Is it a question, is it ment as an answer somewhere else? Did you click on 'post new topic' instead of 'post reply' somewhere?
Click to expand...
Click to collapse
is not difficult to understand.
I just opened a new thread to explain how the JIT.
Who is curious to know how can read the thread.
Anyway thanks for the comment. I'll do some changes to the thread to clarify the reason for its existence.
dipje said:
No, not really. I'm missing the point of this post . Is it a question, is it ment as an answer somewhere else? Did you click on 'post new topic' instead of 'post reply' somewhere?
Click to expand...
Click to collapse
It's only useful if you realise you don't know what JIT is
I now have a better understanding of how it works, thanks!
why is it so difficult to bring this to a hero rom? the JiT compiler by google seems to be nearly ready ...
Need to know to compile the kernel
Forgive my ignorance, but I thought this was how Android apps always work — they come as bytecode and the phone translates them into native code when needed... right?
How else does it work?
Here's some info on JIT & here's how it pertains to Android
Essentially, Java is usually translated from source to Java bytecode (an intermediate step between Java itself & processor specific machine code) when the app is compiled. When it is executed, this bytecode has to be interpreted into machine code. What JIT does is cache the results of such interpretation, so that, for example, if a particular section of bytecode is executed multiple times, it will only have to be interpreted that first time. JIT for Java has been around for a good while.
Android uses their own special Java Virtual Machine, which we hear of often - the Dalvik Virtual Machine. This works on similar principles to a typical JVM, but it produces a type of intermediate bytecode that is optimised for execution on devices with limited resources. This code, incidentally, is called a Dalvik Executable, which explains all the .dex sufficies in Android.
As this Dalvik Virtual Machine is relatively new, the further refinement of just in time compilation for it is only now reaching a stage where it's production ready - or at least hopefully will be soon. All pretty exciting as it can boost performance by around 200-300%
HTH
cauli said:
Here's some info on JIT & here's how it pertains to Android
Essentially, Java is usually translated from source to Java bytecode (an intermediate step between Java itself & processor specific machine code) when the app is compiled. When it is executed, this bytecode has to be interpreted into machine code. What JIT does is cache the results of such interpretation, so that, for example, if a particular section of bytecode is executed multiple times, it will only have to be interpreted that first time. JIT for Java has been around for a good while.
Android uses their own special Java Virtual Machine, which we hear of often - the Dalvik Virtual Machine. This works on similar principles to a typical JVM, but it produces a type of intermediate bytecode that is optimised for execution on devices with limited resources. This code, incidentally, is called a Dalvik Executable, which explains all the .dex sufficies in Android.
As this Dalvik Virtual Machine is relatively new, the further refinement of just in time compilation for it is only now reaching a stage where it's production ready - or at least hopefully will be soon. All pretty exciting as it can boost performance by around 200-300%
HTH
Click to expand...
Click to collapse
Thanks for the deepening. Add this post to the first
FunkTrooper said:
Forgive my ignorance, but I thought this was how Android apps always work — they come as bytecode and the phone translates them into native code when needed... right?
How else does it work?
Click to expand...
Click to collapse
In a typical Java environment, without JIT, the application is always interpreted. This makes the applications exceptionally portable, since the underlying architecture (CPU instruction set etc) is largely immaterial.
In a JIT environment, some or all of those bytecodes (as JIT usually works by method) are compiled directly down to native code as the application is run (hence Just-In-Time). Some or all of the application then effectively becomes a native application targeted at a specific architecture rather than an fully interpreted application.
Simplistically, the net result is that a JIT-compiled app is usually slower to start, but faster to run.
See here for some details of Android JIT compilers.
On a related note, not all Android applications are fully interpreted java anyway. If an application uses the NDK, portions of it may be written as native code (see here).
Regards,
Dave
Interesting thread, one thing I don't know is if the native code produced by JIT is just cached or stored? Ie if its cached, starting an application will take a while the first time, then really quick the second time until that app is taken out of the cache
Or is it that the JIT native code replaces the java on that device, so once run, its always quicker even if the phone is rebooted etc?
tomfreay said:
Interesting thread, one thing I don't know is if the native code produced by JIT is just cached or stored? Ie if its cached, starting an application will take a while the first time, then really quick the second time until that app is taken out of the cache
Or is it that the JIT native code replaces the java on that device, so once run, its always quicker even if the phone is rebooted etc?
Click to expand...
Click to collapse
Aiui the cache exists in memory purely for the duration of the program's execution & hence is recomputed everytime the program is run. This is consistent with a discussion I found after a quick google where some posters ask why isn't it stored longer term. You might find it interesting, though note being a forum thread one can't rely on its accuracy
Note, this is not to be confused with the Dalvik cache in which some optimisations are performed on the .dex when an app is first run (or in the case of system apps, in advance - this is what the .odex files are). I /think/ & this is speculative on my part, there might be some overlap in the types of optimisations but essentially, the Dalvik cache optimisations are less far reaching than JIT's & still result in Dalvik bytecode (more or less) unlike JIT.
I probably can't add anymore as that's pretty much all I know at the moment. Adding guesswork isn't going to do much for the archival value of this thread.
Interesting read, thanks for posting that. Will be really interesting to see what practical benefits this brings to Android.
Just curious of the versions of JIT. Correct me and enlighten me if you can...
JIT is being developed by google and IS or WILL BE open sourced?
The code being currently used in ROMs is not a final version?
How often has this code been updated. Has it been just one release or is google (or others) releasing more often?
Thanks if you can help me.
thanks for this. it was quite helpful.
terryazthompson said:
JIT is being developed by google and IS or WILL BE open sourced?
Click to expand...
Click to collapse
I think JIT will be a part of the Froyo (Android 2.2) imminent(ish) release & is subject therefore to the same release policy, ie code developed behind closed doors with periodic releases of new versions in source code form under an open license, E&OE, aiui (posting as no one else has replied).
Hi all. Im looking to develop my first app. Its for Touch Pro 2 running WM 6.5.
I want the app to perform the following simple mathmatical calculations:
a=manually entered number between 2 and 20
1) a*200=b
2) b*40%=c
3) b*20%=d
4) b*15%=e
5) b*10%=f
6) b*8%=g
7) b*7%=h
The program would allow me to enter 'a' into a text box. It would then calculate and report calculations 'b'-'h'.
I understand that this can be very simply accomplished using Pocket Excel, however Im hoping to create a nice simple GUI for the program. Im not asking anyone to create the app for me, just to point me in the direction of some relevant tutorials.
Cheers all
It would help if you told us what Language you are aiming to use
Not a clue. Never programmed before. Was hoping this might be a nice simple starter app. Any recommendations on which is the best language to use for what I want the app to do?
I started with C# and it's pretty easy to learn. There's a ton of tutorials for C# programming at msdn.com both for desktop and mobile applications.
Beginner Development Series (intro, tutoirials, videos, etc): http://msdn.microsoft.com/en-us/beginner/dd435692.aspx
WinMo Rampup (helps to have programming basic knowledge): http://msdn.microsoft.com/en-us/rampup/dd807370.aspx
WinMo Developer Center (download SDKs, forums, etc.): http://msdn.microsoft.com/en-us/windowsmobile/default.aspx
Enjoy!!!
I agree that C# is a very easy to learn language for people enterring the developing 'world'.
I started by learning C#, however, as helpful as it was in terms of understanding coding, I do regret starting with it. I personally feel, learning from my 'mistake', that learning C++ would have been a greater thing to do FIRST. It is a large jump to go from little/no knowledge to C++ coding, but in the long run, C++ is faster on Mobile Phones because it doesn't have to load up the same dependencies that the .NET CF has to.
If you were to want to learn a language for both PC AND Windows Mobile/CE, then C# is MOST DEFINITELY the way to go, since it has DECENT speeds on Mobile devices, and speeds good enough for most tasks on PCs.
Thats just my 2 cents. And if you ever need any help with C#, feel free to contact me. Look at some of the apps I have made, and if any of them interest you, PM me about the source, I may be able to help you out!
Thanks for the advice guys. Im going to take a look into both of the suggestions and see if I can have a bit of fun.
@Cyclone.... I will certainly take a look at some of the apps you have created, and the point that you brought up about programming for both desktop and mobile has interest for me.
Thanks again for the responses guys.
Why would you program an app like that? don't you have an calculator?!
but it is really easy and you only need the very basic operations. use float datatypes and remember that 15% of X is (x/100)*15 and you are done
'If you use the MS Visual Studio Express 2008 you get a visual gui designer.
greetz
use Excel , its more simple for your job
Cyclonezephyrxz7 said:
I agree that C# is a very easy to learn language for people enterring the developing 'world'.
I started by learning C#, however, as helpful as it was in terms of understanding coding, I do regret starting with it. I personally feel, learning from my 'mistake', that learning C++ would have been a greater thing to do FIRST. It is a large jump to go from little/no knowledge to C++ coding, but in the long run, C++ is faster on Mobile Phones because it doesn't have to load up the same dependencies that the .NET CF has to.
If you were to want to learn a language for both PC AND Windows Mobile/CE, then C# is MOST DEFINITELY the way to go, since it has DECENT speeds on Mobile devices, and speeds good enough for most tasks on PCs.
Thats just my 2 cents. And if you ever need any help with C#, feel free to contact me. Look at some of the apps I have made, and if any of them interest you, PM me about the source, I may be able to help you out!
Click to expand...
Click to collapse
+1 on this. C# is very easy to learn, but now I'm having some areas that the .NETCF doesn't cover so I'm in the process of learning C++. And I can def say it would have been a big leap to start with C++, but it makes a great foundation to learn other languages, cuz you know what's going on "behind the scenes" so to speak.
Having that been said, if anyone is in the learning process of C++ and would like some assistance, you can contact me, and I will be glad to try ot help where I can (Maybe we can learn something from eachother haha).
But yeah, I am re-doing my Fake FingerPrint Lockscreen app in C++, and it runs SO MUCH MORE SMOOTHLY! Not even kidding, I made a build that goes on my SmartPhone (non-touch) and everything just looks better! So really, do consider C++...
brandi said:
Why would you program an app like that? don't you have an calculator?!
but it is really easy and you only need the very basic operations. use float datatypes and remember that 15% of X is (x/100)*15 and you are done
'If you use the MS Visual Studio Express 2008 you get a visual gui designer.
greetz
Click to expand...
Click to collapse
You can't develop for Windows Mobile 6.x using the free (Express) Visual Studio versions! (i.e. a commercial one or SharpDevelop)
And I recommend starting with C#.
(When you're at the point that you think C#.net is too slow then either you're still learning or you'll be experienced enough to change to C++ easily. )
Cyclonezephyrxz7 said:
Having that been said, if anyone is in the learning process of C++ and would like some assistance, you can contact me, and I will be glad to try ot help where I can (Maybe we can learn something from eachother haha).
But yeah, I am re-doing my Fake FingerPrint Lockscreen app in C++, and it runs SO MUCH MORE SMOOTHLY! Not even kidding, I made a build that goes on my SmartPhone (non-touch) and everything just looks better! So really, do consider C++...
Click to expand...
Click to collapse
Rock on! Yeah right noI'm jsut getting my feet wet in C++, but I'm sure that shortly down the road I'll be working on learning it more in-depth. It is def much faster at runtime than .NET.
Thanks!!!
Native code?? Why??
kliptik said:
Rock on! Yeah right noI'm jsut getting my feet wet in C++, but I'm sure that shortly down the road I'll be working on learning it more in-depth. It is def much faster at runtime than .NET.
Thanks!!!
Click to expand...
Click to collapse
Hey guys
I recommand clearly .net developement! On desktops .net code is optimized on the target pc - c++ is compiled on that pc where you coded it. So .net is not any more slower than a native app - in some cases the target-optimation causes more powerful code as the native one.
Even on winmo the code is not slow (you don't feel the difference beetwin managed and unmanaged). Clearly, the .net gdi is slow and has not very much caps... But there are simply ways to access Open GL ES and programming is damm more easy than c++.
And last but not least: WinMo 7 apps are written with the XNA Game Studio or Silverlight - that means you'll code in managed c#!!
So get started with C#!!!
Chabun
thanks for this link
chabun said:
Hey guys
I recommand clearly .net developement! On desktops .net code is optimized on the target pc - c++ is compiled on that pc where you coded it. So .net is not any more slower than a native app - in some cases the target-optimation causes more powerful code as the native one.
Even on winmo the code is not slow (you don't feel the difference beetwin managed and unmanaged). Clearly, the .net gdi is slow and has not very much caps... But there are simply ways to access Open GL ES and programming is damm more easy than c++.
And last but not least: WinMo 7 apps are written with the XNA Game Studio or Silverlight - that means you'll code in managed c#!!
So get started with C#!!!
Chabun
Click to expand...
Click to collapse
I entirely disagree.
By coding using the pre-made Managed Libraries in the .NET Framework, you are making an app that, when run each time, has to load up those "immense" DLL's and access them for practically every function it does. And if you want to go beyond the basic abilities of C#, you have to start importing DLLs to use. However, in C++, as I understand it, the code is being generated based on the Header files on the computer, and the libraries. I find that C++ apps can be larger in size because more of their functions are 'internally' coded.
Sure, a C# app can be just as fast as a C++ app if the developer has no idea how to write a C++ app (no optimization or memory management), but that is exactly the reason to start with C++, to get better! A skilled C++ developer can create programs that run distinctly faster than C# applications.
Cyclonezephyrxz7 said:
I entirely disagree.
By coding using the pre-made Managed Libraries in the .NET Framework, you are making an app that, when run each time, has to load up those "immense" DLL's and access them for practically every function it does. And if you want to go beyond the basic abilities of C#, you have to start importing DLLs to use. However, in C++, as I understand it, the code is being generated based on the Header files on the computer, and the libraries. I find that C++ apps can be larger in size because more of their functions are 'internally' coded.
Sure, a C# app can be just as fast as a C++ app if the developer has no idea how to write a C++ app (no optimization or memory management), but that is exactly the reason to start with C++, to get better! A skilled C++ developer can create programs that run distinctly faster than C# applications.
Click to expand...
Click to collapse
Hey
Calm down. I also know c++ and i coded some apps in it.
Of course you have to import some dll's managed or unmanaged, but where's the difference to import any header file?? I still use some c++, no c - for real low capable hardware (a robot) where no other compiler is avaible...
But ispartacus75 has asked for some tuts and help to get started and we won't start a fight c++ vs. c#, will we?
But I'm still recommending c#...
Chabun
I'm also learning C# and a little C++ (for Windows and Widows Mobile) with the MSDN resources and I'm only 12
tayler900 said:
I'm also learning C# and a little C++ (for Windows and Widows Mobile) with the MSDN resources and I'm only 12
Click to expand...
Click to collapse
Mad props!!!
If you want to make a nice GUI, use QT!
Say no to C#! Blah it is no good. Go with C++ all the way. You won't regret it.
Anyway, go to Qt.nokia.com and get into Qt. There is a lot to learn at first but it will pay off for any c++ developer. It is free and you can develop for winmo 5.x-6.5.x. Also using QtDesigner you can build the Gui without writing a single line of code. Let me know if you want an example I can whip this up in no time.
Hi all.
After a lot of searching around, and reading tutorials etc I decided to go with C++ to start off with.
Someone asked why I wanted to do this rather than just use a calculator or an Excel sheet. I wanted to do it simply to see if I could. I have a couple of little projects in mind and if I could sort this one out I might be able to have a go at the others.
So far I have downloaded Code::Blocks as the compiler, seems to do the job so far. I have also written the code for what I want:
/* This program is designed to calculate the number of points available in a poker
league game, and then divide the points up for the 6 players on final table. This
is based on the following percentages;
1st place = 40%
2nd place = 20%
3rd place = 15%
4th place = 10%
5th place = 8%
6th place = 7%
*/
#include <iostream>
using namespace std;
int main()
{
int players = 0; //number of players in the game
int x = 200; //number of points generated from each player
cout << "Number of players?" << endl; //requests total number of players
cin >> players; //user specifies number of players
int total = players * x; //calculation for number of points available in the game
cout << "Total Points = " << total << endl; //reports the total number of points
cout << endl; //line spacer
/* The next section calculates the points for each place 1-6 based on the above percentages
and then reports those points to the user */
int first = (total/100)*40;
cout << "First Place = " << first << " points" << endl;
int second = (total/100)*20;
cout << "Second Place = " << second << " points" << endl;
int third = (total/100)*15;
cout << "Third Place = " << third << " points" << endl;
int fourth = (total/100)*10;
cout << "Fourth Place = " << fourth << " points" << endl;
int fifth = (total/100)*8;
cout << "Fifth Place = " << fifth << " points" << endl;
int sixth = (total/100)*7;
cout << "Sixth Place = " << sixth << " points" << endl;
return 0;
}
Click to expand...
Click to collapse
At the moment this seems to be working. I press F9 and it will run the program exactly as expected.
I now have the .exe, but when I run it the window closes as soon as the calculations are complete. How can I sort this before continuing on with the project?
Next step is the GUI (I think, kinda gone head first into all of this), so want to get this problem sorted first.
Thanks for taking a look
[SINGULARITY] -
Singularity
Singularity (and the language of such Sing#) is a Microsoft operating system currently on codeplex as RDK 2.0 which is now core to this project - getting Sing# and Singularity to run on ARM (hd2) then can easily boot NT or anything and everything - essentially, NT will happen, but is irrelevant, as need to here first give MAGLDR an d HD2 ability to run Common Language Runtime AND Singularity (.ARM ver of .X86) -
GOAL= make ARM Singularity Kernel run on HD2 then run apps using this core as native apps or strap out onto whatever...
See update on last page of this thread.
ntonhd2 said:
Cotulla: repsonse to your question along with basic test build, just for compile practice run (check for errors), was succesfull; this is for ARM low level bootloader (ARMLDR ) which runs on ARM (hd2, ultimately here) and then grabs LDR (ntldr) then all other files (see my reply) then NTOSKRNL.EXE -> its attached for you to download on next page - thanks again for your input .
NT on ARM:
http://www.microsoft.com/presspass/press/2011/jan11/01-05SOCsupport.mspx
http://www.microsoft.com/Presspass/Features/2011/jan11/01-05SinofskySOC.mspx
http://www.bloomberg.com/news/2010-...ion-of-windows-for-arm-chips-at-ces-show.html
http://thecoffeedesk.com/news/index.php/2009/04/23/net-could-be-key-in-windows-on-arm-netbooks/
http://www.osnews.com/story/24165/Windows_NT_on_ARM_It_s_a_Server_Thing
Please also read my last post regarding Xbox running NT.
And understand I AM TALKING ABOUT NTOSKRNL with Native CLI and not running full WindowsXP or 7 or watever! .
hi xda, put this in hd2 general as could be relevant to linux or wp7 or hd2. Thinking of starting project here of pretty grand scale if people are interested. Now that a lot of work has already been done i think it will not be as hard as it may appear or sound at first.
I am thinking about using new wp7 bldr +- oal +- nk.exe to set up emulation of bios expected on pc then trying to jump to 2003 server equiv ntoskrnl.exe. (and then probably just a native command line interface like alex ionescu tinykrnl project back in the day, a ncli for nt with usb keyboard and not much more to start with: Further dev much later).
Nk will handle underlying lack of pci, bios, ints, and addresses, (+is firmware) but actual switching to nt kernel is for real after that: To build a strapping kernel with ce7/wp7 architecture and initial drivers that goes on to then launch full nt kernel.
Yeah - i have \nt\private\ntos\ source code and no it is not the normal nt4 or other w2k leak- it is a complete and buildable kernel; pm me and i will give proof, or the code if you can build and want to work on this. This is not x86/x64 work obviously so is not for those without ability: Need to do some heavy lifting to get recompile build happening for arm, qualcomm ' snapdragon nt :d. Otherwise is only emulation and not a good idea. This is 2be real. As non-x86/x64 support for nt (nt4 did ppc, mips, and now ia64) this kinda porting is not a foreign concept: There is sufficient info out there with reference to everything from softpc.new (inside ms code) to wow64cpu.dll and other x86/x64 specific init routines, spinlock and interrupt handling, asm code samps, bochs methods, qemu methods, et.al. Which can be used in one way or another or taken over if required: If all taken into account to paint big picture: Use of emulation technology methods for non-emulation project just opens up underlying logic. That is it. This is also why i suggest using wp7/ce7 base 4 init. Do not want emulation. Real deal here only. I refer to all these items above as observations which could be taken into account if need be: From tinykrnl, reactos, bochs, wine, efi, and other such things can make porting over kernel easier: At the end of the day, ce7/wp7 ' bldr, oal, nk.exe (or whatever derivatives thereof) will be 'firmware' in big picture. Another reason i am considering wp7 as base to strap is drivers are there to make a ce+bios or efi-type (?) pre-loader that takes all ce7 initialization further and passes on to nt (nk.exe runs including all setup as would be done by ntldr, a fake or psuedo-real ntdetect.com, system.hiv then passes data structs to our ntoskrnl.exe) and do all that needs be done. I can handle pc side completely but need bit of help with someone who gets nkglobal and other structures and use of platform builder with experience prefered in creation of new bsp. Maybe other ways - instead of ce, ie- grub, linux, openbios, openefi, but either way just want to prove it could be done is all.
Click to expand...
Click to collapse
anybody here capable?
to quote Da_G:
Yup, RustyGrom pretty much has it covered. First, it's called "CE" for Compact Edition, and this is not a misnomer in any way. The system is designed to be as compact as possible (There are build-time switches for everything, so you can toggle off nearly all the components to acheive a very "light" image) obviously, including drivers for components not present would be a waste of space, as they would never get used. So there are none included. On the PC side of things the BIOS provides a basic level of functionality using a standard interface so generic drivers are created to bring the platform up to that level, and from there vendor-specific drivers can be loaded.
If you want to put an embedded device in terms of a desktop computer and loading Windows 7 on it, you start out with a fully assembled computer (video card, motherboard, cpu, ram, etc.) - power it on. It loads up the BIOS which initializes the basic hardware and begins to load the rest from the hard drive. The embedded device loads up the NAND XLDR, which provides only flash read/write support. The XLDR then loads the "EBOOT" or "IPL" into ram on typical devices. HTC doesn't use the EBOOT/IPL model as such (here already we're breaking away from the "standard" even further) and instead has that split out into mARM AMSS (a custom designed RtOS that loads and runs the Modem ARM CPU) and SPL. Once the AMSS loads the SPL into ram and executes it, the SPL initializes the aARM (apps ARM CPU), does various checks (are we in update mode? do we need to expose a flash interface to update the rest of the OS? do we just boot up the os and move aside?)
Then finally you get past the highly device-specific code and on to the (slightly) more generic CE Kernel/drivers which get copied into ram by the SPL and executed (Native Kernel/XIP partition)
So, how different is CE7/WP7 from that model? (Which is the model we have now in CE5.x/WM6.x) - The mARM AMSS provides a different interface and initialization proceedure. That means any of the WP7 drivers from a donor device we might port from would not work at all with our current AMSS. Which in turn means no boot without re-writing the drivers/kernel or AMSS.
So to compare it to a desktop PC once again, we need to write a BIOS, a Hardware Abstraction Layer, and a set of drivers for each component on the system (likely a good deal of the drivers would be usable once the rest is done)
Do I sound jaded yet? Yes, yes I am It's probably a factor of 10 more complicated than I thought it would be initially.
Here's the JTAG pinouts that need to be connected, btw. There are pins on both sides of the motherboard which also is truely a pain in my ****, as i originally intended to mount an external port on the HD2 so I could easily keep a JTAG connection with it, but you basically have to remove the entire motherboard to maintain a reliable connection, which really precludes running it on a live device.
Click to expand...
Click to collapse
JTAG working now .
Ummm expect to hear from Microsoft lawyers in 5....4....3....
RustyGrom said:
Ummm expect to hear from Microsoft lawyers in 5....4....3....
Click to expand...
Click to collapse
Yeah i would be in breach of the non-disclosure-agreement i signed so removed.
But i am in inner city cbd wifi hotspot area and jump around unsecured cafe signals and other businesses and also use proxy servers and..... on top of that..... my own added tweaks for safe measure!
so, cafe+wifi+proxy, +other_anon, means there is absolutely no chance.
RustyGrom said:
Ummm expect to hear from Microsoft lawyers in 5....4....3....
Click to expand...
Click to collapse
reading your stuff on ce7. is this a bad idea you think? or not possible? no interest? i think it can be done.
ntonhd2 said:
reading your stuff on ce7. is this a bad idea you think? or not possible? no interest? i think it can be done.
Click to expand...
Click to collapse
I just don't think it's possible or worth it to bother trying to port NT to ARM while Microsoft is doing the same already. You're not going to be able to put together the team required meanwhile hiding from MS. It's just a stupid idea imo and really has no benefit. I mean what's your end goal here? To run Win7 on our devices?
Judging from this and other posts you have made, I suspect the most "source" you have is the "Windows Research Kernel", which is the source for a portion of ntoskrnl.exe from Server 2003 SP1, approximately. That would be no-where near enough, and it's not even enough to compile "just a kernel". It actually has a number of pre-compiled parts that it just pulls in.
Not to mention such a project is just asking to get shot down in a legal firefight. The WRK is given to academic institutions for studying the world's most popular desktop kernel, and is done so under a strict NDA.
ntoskrnl.exe by itself isn't enough to produce a workable OS anyway, especially one from the Server 2003 era.
hounsell said:
Judging from this and other posts you have made, I suspect the most "source" you have is the "Windows Research Kernel", which is the source for a portion of ntoskrnl.exe from Server 2003 SP1, approximately. That would be no-where near enough, and it's not even enough to compile "just a kernel". It actually has a number of pre-compiled parts that it just pulls in.
Not to mention such a project is just asking to get shot down in a legal firefight. The WRK is given to academic institutions for studying the world's most popular desktop kernel, and is done so under a strict NDA.
ntoskrnl.exe by itself isn't enough to produce a workable OS anyway, especially one from the Server 2003 era.
Click to expand...
Click to collapse
Sigh.. why don't people read before they make these ridiculous and thoughtless posts? Realize that there are people from Microsoft ON these threads. Also, RESEARCH IN DEPTH BEFORE POSTING SUCH A THREAD.
snickler said:
Sigh.. why don't people read before they make these ridiculous and thoughtless posts? Realize that there are people from Microsoft ON these threads. Also, RESEARCH IN DEPTH BEFORE POSTING SUCH A THREAD.
Click to expand...
Click to collapse
There are more microsoft people on xda than most realize .
RustyGrom said:
I just don't think it's possible or worth it to bother trying to port NT to ARM while Microsoft is doing the same already. You're not going to be able to put together the team required meanwhile hiding from MS. It's just a stupid idea imo and really has no benefit. I mean what's your end goal here? To run Win7 on our devices?
Click to expand...
Click to collapse
sure, sourcecode factor (nda) and secrecy/MS are complexities: but not as hard as people think here: it is TWO COMPLETELY DIFFERENT THINGS TO TRY AND GET WINDOWS7-ON-ARM to what I suggested (NT-CONCEPT-ON-ARM-WITH-Native-CLI) and no I would not use WRK sourcecode (lol) as part of my daywork i have access to (not ce) full sourcecode.
see my last post here,
can be done .
hounsell said:
Judging from this and other posts you have made, I suspect the most "source" you have is the "Windows Research Kernel", which is the source for a portion of ntoskrnl.exe from Server 2003 SP1, approximately. That would be no-where near enough, and it's not even enough to compile "just a kernel". It actually has a number of pre-compiled parts that it just pulls in.
Not to mention such a project is just asking to get shot down in a legal firefight. The WRK is given to academic institutions for studying the world's most popular desktop kernel, and is done so under a strict NDA.
ntoskrnl.exe by itself isn't enough to produce a workable OS anyway, especially one from the Server 2003 era.
Click to expand...
Click to collapse
What does this statement really mean?
might be a bad idea on hd2, fine, accepted, but your comment at the end doesn't make sense to me. so, ntoskrnl.exe for wp7 or nt4 (another era than 2003 .net) would make a difference? that is silly. besides, i made it clear that a psuedo-firmware setup would be required to setup the datastructures that NTLDR would prepare (along with NTDETECT.COM, and bios+pci_bus+ACPI interaction, (plus system or setupreg.hiv)), etc: so what are you saying exactly? my point was to not run any win32 or win64 gui or subsystem. never even mention win32k, gdi, etc. I was very clearly talking about native cli (ntdll.dll) and a prompt- maybe usb keyboard- as ARM NT Conceptual. Please, enlighten me . PS> yeah, I know the wrk and am fully aware of \prebuilt\ libraries and obj code: but, no, I was not intending on using this as base. I admit, hd2 nt prob bad idea: btw was ARM NT concept more than anything! and yeah, with the secrecy and legal issues it would be too complex and overwhelming to do so, accepted, but if I were truly to do this NO i would not use WRK lol .
And regarding Microsoft, yes, I accept that there are a LOT of employees on xda and it is crawled and watched for obvious reasons: covered that.
PPS> re WRK, no, would (if i were to try doing this that is) use what I already have access to as part of my work> under full NDA I have full source to a few different bases including all of 2003 and even HyperVServer and AzureOS trees. .
unfortunately I do not have windows phone 7 code access though! Thanks.
RustyGrom said:
I just don't think it's possible or worth it to bother trying to port NT to ARM while Microsoft is doing the same already. You're not going to be able to put together the team required meanwhile hiding from MS. It's just a stupid idea imo and really has no benefit. I mean what's your end goal here? To run Win7 on our devices?
Click to expand...
Click to collapse
Yep...... but there is a LOT of portability in the original nt4 and even w2k trees with alpha, mips, ppc, os2+posix, original softpc.new+ntvdm, and even newer, that would let this be done a lot easier than most realize: remember here that:
I AM NOT SAYING LETS RUN WIN32 ON OUR HD2: I AM SAYING LETS TRY RUN NTOSKRNL ON ARM.
big difference guys.
RustyGrom, I assume your talking about ARM-Cortex etc (msnt-2-arm)..... THIS is what i wanted to do but a much more lightweight and ms-testing-protocol-free-process; homebrew version in experimental state would ensure much speedier development: it is not that hard a concept to attempt to port over an earlier (nt4 or w2k) kernel FIRST then look at better (2003 & 7) memory management etc: the point here is PROOF OF CONCEPT NT ON ARM: that is it, like what you refer to. Read my first post: any remember tinykrnl.org? Alex Ionescu ? Reactos? it could be done a LOT easier than you all think!
only NT on ARM official stuff i am aware of is this (rumour/talk/concept/theory/design atm):
http://www.microsoft.com/Presspass/Features/2011/jan11/01-05SinofskySOC.mspx
http://thecoffeedesk.com/news/index.php/2009/04/23/net-could-be-key-in-windows-on-arm-netbooks/
http://www.osnews.com/story/24165/Windows_NT_on_ARM_It_s_a_Server_Thing
If you know NT like i do- then you would see it could readily be done but yes, I admit I do not know enoug about 'phones'/ce-platform. That's why I started THIS THREAD HERE: to get some thought on the subject is all .
what then would be major problems to overcome then and this is assuming concept of say:
0). hd2 power on
1). ipl/equiv
2). hspl.
3). magldr
4). dft leo70 rom
5). bsp/oal, bldr/uldr, OS.NB ->(NK.EXE).
6). remap, reinit, load and place (prep) data structures expected by ntoskrnl.exe (osloader, detect, pci, bios, etc).
7). jump to ntoskrnl.exe
?
For the record, a few years ago i did this exact thing: ported nt kernel over to another platform. myself and others re-wrote ntoskrnl.exe (+hal+drivers) and integrated osloader.exe(ntldr), and all data structures as would be passed to kernel from ntldr, registry system hiv, ntdetect, missing bios, missing interrupt+dma+pci-bus+acpi+power, etc into one (debug/xdk) single DEFAULT.XBE.
it only worked on XDK debug kit xbox consoles with serial+scsi+128mbRAM (and a custom lpc debug mod) but it worked. using code from intel and tianocore EFI/UEFI toolkits (and bits and pieces from here and there) and concepts such as PALcode as used by non-x86 osloader (.exe not ntldr) for simulacrum bios/firmware you can pass a predefined set of structures to ntoskrnl and ensure processor regs etc ARE ALL GOOD AND SYSTEM IS READY then call into KiSystemStartup, ExpInitializeExecutive, and begin modified phase0 of NTOSKRNL.EXE.
similar thing was done with CE.NET for Xbox - a default.xbe with linux code b4 NK.NB0
worked and works .
anyway, how u wanna solve the next problems?
1)missing CL compiler for ARM with same set of features like CL for X86.
(CL version for ARM for WCE doesn't have all features supported and usually outdated)
2)this ARM compiler store exception info in other format (not SEH frames, but universal table for functions ".pdata")
3)which files u exactly wanna build for ARM? is it "ntoskrnl.exe bootvid.dll hal.dll"?
4)which final results u gotta got?
5)why u need touch WP7? u can just look to example code in Android kernel and implement something. so replace PC standard timer realization inside HAL.dll with QSD8250 specific timer code. it's much better to start.
how many ppl u have in ur team?
Cotulla said:
anyway, how u wanna solve the next problems?
1)missing CL compiler for ARM with same set of features like CL for X86.
(CL version for ARM for WCE doesn't have all features supported and usually outdated)
2)this ARM compiler store exception info in other format (not SEH frames, but universal table for functions ".pdata")
3)which files u exactly wanna build for ARM? is it "ntoskrnl.exe bootvid.dll hal.dll"?
4)which final results u gotta got?
5)why u need touch WP7? u can just look to example code in Android kernel and implement something. so replace PC standard timer realization inside HAL.dll with QSD8250 specific timer code. it's much better to start.
how many ppl u have in ur team?
Click to expand...
Click to collapse
************************************************************
update: Attached is ARM low level bootloader just built; this could be used to load LDR and then ntoskrnl.exe .
************************************************************
Please let me know your thoughts and please try to get this to run with debug if you can and pass results & thoughts back to me - Cheers. Hopefully it built ok. What do you think of using this method then? but with FULL & PROPER NTOSKRNL.EXE!
************************************************************
Hi Cotulla, thanks for your reply: appreciate it here.
[also much thanks for hspl, magldr, dft android, leo70ROM. .]
ok, sorry if this is a bit all over the place, i have cut and pasted my answers around to try clean it up but it is late and i think my brain is a bit dead sorry, but answers are here anyway . hope makes sense. firstly please have a look at this video and let me know what you think .
http://www.youtube.com/watch?v=RFNuY2OFRjU
that is ARM..... i am going through build environment and sourcecode now..... thoughts?
http://www.youtube.com/watch?v=n3v4YC9RT-g&feature=related
can learn a lot from wine. i agree with you on linux. same for virtualization, emulation, etc, like bochs qemu everything . sandboxing and hypervisor unveils a LOT . another thing i wanted to ask you was what do you think of FPGA technology for reverse engineering unknown systems? for example, if i were to start almost any project, like say leo70DFTrelease, or NT on Xbox, or whatever, doesnt matter, i think it is worth spending the time or money (for private company to do it for you) and have an FPGA version of the target device being hacked (hd2 in leo70rom case) and then undo the software problems from a hardware logic perspective. just the way i have worked on things many times and it works for me anyway. but I digress.......... . if i were to have done wp7hd2 (leo70rom) and magldr, then i would have had to have had (for me, not as good a dev as you) a FPGA based HD2 made up that ran in every way same but with which i could get right in there and do whatever i needed to do to see response& debug. let me know what you reckon... ok... digress now :
1)missing CL compiler for ARM with same set of features like CL for X86.
(CL version for ARM for WCE doesn't have all features supported and usually outdated)
what features specifically we need here?
what about tweaking this:
http://reactos.colinfinck.de/files/RosBE-Windows/RosBE-ARM-1.0.exe
2)this ARM compiler store exception info in other format (not SEH frames, but universal table for functions ".pdata")
http://www.reactos.org/wiki/PSEH
http://www.reactos.org/forum/viewtopic.php?f=9&t=5716
reading up on _IMAGE_CE_RUNTIME_FUNCTION_ENTRY. just going over stacks and frames and overall exception handling on ARM. are there any issues with reverse execute, virtual unwind? for this type of execution- how would you handle?
more to the point- how would you do this project lol.
problems with prolog/epi? what about moving over x86 asm code? i am right now typing this to you whilst getting updated on specifics on registerslooking at emulators to see this in action. i am reading these here. let me know if on right path and please put up links to whatev will make this project concept a reality . Cheers .
see here
http://www.cl.cam.ac.uk/~mwd24/phd/swarm.html
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
http://www.codeproject.com/KB/threads/StackWalker.aspx?msg=2818356
can you recommend any compiler, emulator, os, setup, even equipment (JTAG etc etc) i should use, buy, try?
3)which files u exactly wanna build for ARM? is it "ntoskrnl.exe bootvid.dll hal.dll"?
depends on method: i agree (see below) that probably android or (htc-)linux is probably more likely to work but leo70_rom made me think maybe jump from (touch wp7) nk.exe? and are you saying use linux as in LinuxBios type setup?
would need emulated bios, pci bus fixed up (?), QSD timer HAL, ACPI (?), etc ,,, so probably would end up with the following:
a) BIOS (ce7 exe or linux ?): options here could be to make NT think it is running on PALcode, uEFI, or standard ACPI BIOS (your thoughts?). I think uEFI (tianocore/Intel) is best bet here perhaps. this would include MBR code (efi equiv or pal equiv depending) and any psuedo-real or "real" initialization i think.
b) mbr execution merged to and included in above, bootsect. in sim' 'firmware'.
c) $LDR$ @ OSLOADER.EXE (osloader.exe is non-x86 ntldr as im sure you know WITHOUT the code to run ntdetect.com and acts in PALcode architecture to pass on predefined data structues from firmware: tells NTOSKRNL.EXE where and what 2 execute).
d) HAL.DLL (timer, power/acpi, spinlocks, interrupts). another reason i leant towards WP7 as pre-NT launcher is because i assumed that something like BSP, OAL, etc, could be maybe used as base: if not for code, then logical base. what base(s) did you use to create WP7 if i may ask? ie: CE7? I have just installed Platform-Builder. but yeah, i here you regarding android/linux kernel example: ultimately are you saying better, easier, more logical, to go with android/linux you think Cotulla?
e) BOOTVID.DLL
f) KDCOM.DLL (if wp7 would make use of KITL?)
g) drivers as required including the following: ntbootdd.sys (?) might allow easier diversion from bios lack of INT13 and other support: remap to whatever can handle this properly. equivalents for ACPI.sys, filesystem drivers, other power, basics. how should i be looking at things from NT side of things, as in \ObjectTypes like \??, \Global?? etc .... and items like ROOT device in ARM (either CE or linux preloaded) context? any thoughts on how object manager would need to be brought up? for me, now, that is where it gets crucial and is core.
h)SMSS.EXE (NATIVE.EXE) but to begin with could just get drivers and all that working first and strap up into cmdcons (SPCMDCON.SYS). just blue-screen SMSS (windows setup) enough to prove kernel to run on ARM cpu. your thoughts?
i) SYSTEM reg key hive (setupreg.hiv etc?)
...
4)which final results u gotta got?
Tinykrnl type native CLI.
http://www.betaarchive.co.uk/imageupload/1193217573.or.99024.jpg
with USB keyboard support like htc-linux then go from there..... would love a prompt from which could just call any given call - be it CreateProcess or NtCreateProcess or ANYTHING: and it just does it (with debug/KITL) without question . but native NT command line is good for now. not going near win32.
5)why u need touch WP7? u can just look to example code in Android kernel and implement something. so replace PC standard timer realization inside HAL.dll with QSD8250 specific timer code. it's much better to start.
yeah....
I thought linux probably would end up being better: just liked symmetry of windowsCEx-strapping-windowsNTx: making a windowsCE-EFI/BIOS: but yeah, something like LinuxBios (android kernel etc) would be a lot easier in the end yeah? All this is overly simplified and very conceptual but there are basic answers. . once a solid idea has been formed then this could actually be done i think. and before Microsoft . Do you believe Reactos-ARM-build environment could be used? Am i missing anything? 9 people team+myself (+any help you can offer) would make 10 (+1). I think this is a good idea to at least try and i believe with your assistance, guidance, well, it would get done and then complete the HD2 line up fully. . In conclusion, right now, I need ARM emulator software, platform builder, and fully working Compact Edition 7 on HD2 to get some more thoughts and try few things out in platform builder debug then can get final decision, design, plan and start to get everything working. Even though will probably go with Linux/Android obviously as above, I still need 2see init on CE7 on HD2 and be able 2use this along with whatever else we can! have a look at all above links... thanks.
Cotulla, thanks again 4reply>please PM [email protected] something but not posting..... await your PM.
what about this ( http://research.microsoft.com/en-us/projects/singularity/ ) could be of use to NT port with respect to CLR ? haha, or just outright hd2 port Microsoft RDK OS ' singularity ' ? .
************************************************************
update: Attached is ARM low level bootloader just built; this could be used to load LDR and then ntoskrnl.exe .
************************************************************
Please let me know your thoughts and please try to get this to run with debug if you can and pass results & thoughts back to me - Cheers. Hopefully it built ok. What do you think of using this method then? but with FULL & PROPER NTOSKRNL.EXE!
************************************************************
I don't have big knowledge of Windows NT system, but I think it's must be enough to provide basic stuffs for kernel start up.
I guess NT using only int13 services for reading data from disk, int15 services used to detect memory configuration and int10 for initial boot mode.
Because it's embedded hardware, the devices in the system are fixed and limited. So it's enough to provide fixed values for kernel, like available ram memory range.
No need of using any complex systems with CE / Linux.
About CE, you can get almost full kernel sources in PB6.0, trial can be downloaded from MS site.
afaik it's enough to load kernel and dependent modules (drivers) to ram and then run them. after this action kernel drivers should able to run properly on hardware.
About Reactos, I appreciate work of involved people, but I doubt that it's stable
About this project, I don't know yet if I will contribute. I am looking how much it's interesting for me
I always have interesting different things in my hobby as well, so I have choose that to do As well, me is part of DFT team, I need discuss it with them
Now I am asking you to understand more details about your idea(s)
Cotulla said:
I don't have big knowledge of Windows NT system, but I think it's must be enough to provide basic stuffs for kernel start up.
I guess NT using only int13 services for reading data from disk, int15 services used to detect memory configuration and int10 for initial boot mode.
Because it's embedded hardware, the devices in the system are fixed and limited. So it's enough to provide fixed values for kernel, like available ram memory range.
No need of using any complex systems with CE / Linux.
About CE, you can get almost full kernel sources in PB6.0, trial can be downloaded from MS site.
afaik it's enough to load kernel and dependent modules (drivers) to ram and then run them. after this action kernel drivers should able to run properly on hardware.
About Reactos, I appreciate work of involved people, but I doubt that it's stable
About this project, I don't know yet if I will contribute. I am looking how much it's interesting for me
I always have interesting different things in my hobby as well, so I have choose that to do As well, me is part of DFT team, I need discuss it with them
Now I am asking you to understand more details about your idea(s)
Click to expand...
Click to collapse
sure....... . anything ReactOS -freeldr, any arm code, whatever, is just to get basic idea up- to see the actual jump whilst watching (be it by jtag, kitl, usb, or telepathy interface to QD) and go from there; although im sure you could use ReactOS arm code lowlevel bootloader to jump into EITHER "freeldr" or proper "ntldr" or "osloader.exe" (modified of course to have no pci bus scan and the rest.....) that is the dilemma: either jump COMPLETELY like winmo6-android with all structures setup DIRECTLY INTO KERNEL and avoid the whole LDR side of things in that sense anyway; or, well, totally from scratch rebuild loader and subsequently deal with 'firmware' issues... i really do not care in the end if its a jump from one kernel to another (one os to another) because project here is to RUN NT ON ARM/HD2 and not to necessarily have it homogenous down to LDR.
as long as thread, memory, native api, other calls, all that, is truly ntoskrnl = you are running nt on your arm hd2! .
LDR does not matter.... total new rebuild or jump.... whatever comes first .
Thanks Cotulla, yes, we understand where your coming from re do not need linux, ce, and complexities there and i agree: just want to use these for initial testing and deployment of early code with some kitl, debug.... on other notes, trying to put all into organized groups, slowly but surely yes, with bit of faith we will get there in the end .
if totally up to me i would probably take intel/tianocore EFI specification as the base if this could somehow be easily made to run on ARM in this particular context. ie EFI on a HD2!
look at this raw control power!>>> http://www.ami.com/support/doc/AMI_Debug_UEFI_Dsheet_PUB_2008-06-10.pdf
also along these lines, just briefly (is helpful in concept design):
http://x86asm.net/articles/uefi-hypervisors-winning-the-race-to-bare-metal/index.html
http://sourceforge.net/projects/gnu...orig.tar.gz/gnu-efi_3.0h.orig.tar.gz/download
http://x86asm.net/articles/introduction-to-uefi/
http://sourceforge.net/projects/efidevkit/
http://www.logic.nl/Products/Technology/BIOS-and-EFI.aspx
ok, summing up thoughts here>>>
0) object manager and objects; going over arm & ce7, as well as winmo6 and other ce, and comparing with nt and win32/64; just looking at how on final arm release, the \ObjectTypes will be different in the end. very interesting stuff.
1) LACK-OF. no pci bus which is highly expected by ldr/detect so make kernel prob see system in 'PALcode' or EFI mode. pass ldr data structs to kernel in that type of form. otherwise gets very messy and we are not going to hack around because you will end up with an emulator !. this will work but key is determing what 'firmware' passes this data to nt kernel - not from our perspective- but as NT.
2) BIOS. INT services are not used by kernel in that way after it becomes supervisor so will redo drivers unless preload remap somehow. INT only there during ntldr (or can load in ntbootdd.sys to supply these) and this is all pre-phase0 and is very early on.
3) HAL and clk
4) INT services are not used by kernel in that way after it becomes supervisor so will redo drivers unless preload remap somehow. INT only there during ntldr (or can load in ntbootdd.sys to supply these) and this is all pre-phase0 and is very early on.
5) kitl and kdcom
6) registry to pass on (setupreg).
8) filesystem, screen, other drivers
9) final native cli (ntdll.dll) or maybe initially just spcmdcon.sys.
above not in order ..... sorting it all out though .....
ok, looks daunting but like i said before you could get up an nt kernel in setup mode with setup ldr and drivers and old blue screen "dos" mode native subsystem which uses the SMSS.EXE and NTDLL.DLL that are seperately contained in \i386\system32\ or \cmdcons\system32\ - very limited subsystem but is full nt os at kernel . so........ if not ce and not linux preloading, WOW . it is quite an amazing project but doable; so basically just need to see how this armldr (low level strap - be it Reactos or my own clean job- will do both) code runs on the device itself and step by step add the rest in as required! but i still believe actual dev be better jumping from preexisting environment having kitl or some sort of serial or usb debug already there and then working way down to lowest possible level; so, basically, working backwards down to processor.
Doing it all from scratch and CLEAN . (in the end!). .
my brain just straight up exploded.
thanks a lot.
http://www.youtube.com/watch?v=xKc_XGuvNIk .
for the record:
so far without any errors have successfully been able to build the ntdll.dll, hal.dll, smss.exe, bootvid.dll, fastfat.sys, for ARM with no modifications at all, but not yet done a build on the LDR or NTOSKRNL.
just testing compiler here is all and not writing new: this is very early on and i have changed absolutely nothing.
once fill in gaps will give it a go on hd2.
attached.
Hello everybody,
I got a WP7 Samsung Focus and I want to port my old application to this device and join native forces for WP7
My plan is simple: I'll convert my app into a dll, rewrite new gui in C# (or whatever the way to do it on WP7). I saw multiple posts about calling native code (original from Cris Walsh: http://goo.gl/2Tjks). Then I saw a few posts mentioning that it's impossible etc etc.
So, a few questions:
0) can I do it for my app (I don't need marketplace exams etc, I don't care for that)? I know that some WinAPI could be unavailable/broken, all I ask at this point if it's possible to load and run native dll without changing or re-flashing ROM.
1) ms wants 100$ out of my pocket to be able to deploy to my own device (WTF?!). What can I do to deploy to my phone without paying the crooks? (VS2010 tell me to register there and registration askes for 100$).
2) Is there a sample project I could D/L and run, I have zero experience in C# and I have no idea how to load and call native DLL from managed code in WP7? All these half broken samples are totally useless to me, I simply wanted to working HelloWorld app that loads and runs simple dll.
thanks
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
1) Aside from the official marketplace account ($100), there are a few options:
a) if you've got an LG phone, they come with a built-in registry editor that can be used to dev-unlock your phone. I forget the exact key you need, though.
b) if you've got a student email address (ends in .edu) you can try registering through DreamSpark. This is free.
c) if you don't mind rolling back to pre-NoDo (7004 or 7008) you can use ChevronWP7 Unlock (instructions available on this forum). If you don't have a restore point that far back you can flash an official ROM for that version.
d) if you don't mind waiting, ChevronWP7 Labs will be available at some point (no ETA that I've seen, but it's been talked about for months) and will provide dev-unlock (but not marketplace account) for a nominal fee.
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Hope that helps! I look forward to seeing your app. Also, don't hesitate to ask for help with the actual development; I suck at GUIs and Silverlight but am fairly proficient at C# if you need somebody who knows that language, for example.
There is an ETA for the new ChevronWP7 unlocker:only a few weeks away from launch!
Hi GoodDayToDie
GoodDayToDie said:
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
Click to expand...
Click to collapse
At this point I want to make a DLL from my simple app and call a few functions that interact with filesystem and network. FS is needed only for simple stuff (loading config file etc) from installation folder and creating some temporary files for local storage. Network is tcp/udp, I guess network should be available.
GoodDayToDie said:
1) Aside from the official marketplace account ($100), there are a few options:
...
Click to expand...
Click to collapse
I did some search, it seem that I've done that part. Chevron dev unlock was pulled out from their site, but the old version remains scattered all over the board. There is a good thread a good thread on how to do it. It happens that my phone is 7004. Where can I get old ROM in case if something goes bad and I need to re-flash? Is it easy, am I risking to brick and loose my phone?
I just tried to run sample phone app and it runs on the phone. Initially it said that it was revoked by MS, I run dev-unlock one more time and now it works.
GoodDayToDie said:
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Click to expand...
Click to collapse
I'll try to search, hope I'll be up and running soon. Too bad WP7 is DOA. They always had much better tools than all these ghetto Symbian/Android/Xcode crapware tools... WTF is wrong with these guys, at the point when they were surpassed at speed of light by newbies iPhone and Android they made some backward steps to cut off most of the devs (but they added all these 500K Silverlight newbie devs...). I'm so disappointed with Android, seems like they hired all these retards who were fired at symbian: same **** tools
I downloaded a few samples and it seems that all of them contain prebuild dll's and all of them are COM dlls or something like that.
What I'd like to find is simple sample that contains src code to native WinMo dll and C# project that it uses.
As far as I know native dll cannot be build with latest tools (am I right?), but I can use cegcc or VS2008 to build native DLL's.
stuff like:
Code:
if (ComBridge.RegisterComDll("ComFileRw.dll", new Guid("EEA7F43B-A32D-4767-9AE7-9E53DA197455")) != 0)
is totally unknown to me. I would really like to avoid to even elarning anything about COM related stuff. I prefer not to mess up with code that isn't portable.
HI mtlgui,
unless Heathcliff finishes his WP7 Root Tools SDK, you don't have any other way to access native c++ code besides using COM. DFT (The DarkForcesTeam) released a firmware loader, that allows you to flash customized unsigned firmware. They were also able to do some native c++ coding with the WM API. However the used firmware for that is not public and it is limited to HTC devices.
Did you already consider to write your application in c#? Mango has now TCP/UDP socket support for outgoing connections. Incoming connections or services running on the phone aren't possible without using native code, at least for the moment.
Hi rudelm,
if the only way to use native is to build COM dll, then I'm OK with that. My app code is old and I'd rather throw my WP7 device to trash can than trying to rewrite my app in C#.
Eventually, down the road while hacking maybe I'll learn c# well enough to do anything with it other than GUI and calling native/COM dlls.
So, just to confirm my understanding. I need to write COM dlls that access native API (socket, filesystem, wavein/waveout etc) and then load these COM dlls and call their functions from C# (or whatever is the closest lang to c/c++ in the WP7 world).
@mtlgui:
You've pretty much got it. A few thoughts, though:
There is a webserver project available on this site. It includes source for its C++ native component (the library is called NativeIO; I can probably send you the source if you can't find it). It exposes registry, filesystem, and TCP server and client sockets to COM. Note that because this library was built for pre-Mango phones, just compiling it and shipping it may not work on Mango phones as many deprecated libraries were removed in Mango and if the DLL contains any references to them, it won't load.
Generally speaking, what you're asking for with TCP/UDP is possible, though you may have to code against the winsock API directly. It sounds like you're doing as little as possible with C#, so even if the Socket API that is available with Mango were sufficient for your app's needs, you wouldn't be using it.
Filesystem access... even if you have read access to your app's install folder (I haven't checked, though you should), you almost certainly won't have write access. Each app does have a writable "isolated storage" though, under \Applications\Data\{GUID}\Data\IsolatedStore\. I've only ever tried writing to it using C# though, so I don't know for sure if it's writable using the native APIs directly (should be, though).
It's probably perfectly OK to write your app as one big native DLL (hell, it *might* work to just change the build type from Application to Library, then rename main() or something like that). You will need to expose the library to COM, but that's easy. You can then write a very simple C#/Silverlight app (see Heathcliff's instructions, or just post the COM interface and soembody could write it for you). All the C# app needs to do is use ComBridge to access the native DLL, and call a "run()" function or something similarly simple.
For what it's worth, C# is very close to a superset of C++, at least on the desktop. The phone version is crippled a little by not allowing the use of pointers - everything has to be done with strongly-typed references instead, which can make network code a little annoying but is otherwise rarely a problem - but with a little experimentation you may find your disdain for C# to be misguided. It's a useful language to know it today's job market, if nothing else.
Why is your phone still on 7004? That's the launch retail build, something like eight months out of date. On the plus side, this means that things like ChevronWP7 Unlocker still work for you, as you found. On the minu side, it means you're putting up with bugs and missing features that you needn't be. Have you tried updating at all? If/when you do update, make sure to back up the restore points that the Zune software generates (they got in %localappdata%\Microsoft\Windows Phone Update\). That way, if you ever need to roll back to 7004, you can do it. Normally, only the most recent restore point is kept.
Flashing ROMs is safe so long as you don't try something like flashing the wrong one for your device. Unless your bootloader is unlocked (only possible on HTC), you can only flash official ROMs anyhow, which saves you from most of the risks. On the other hand, you're already on as old a ROM as you will find, and so long as you keep your restore points, you can return to it any time you want to, easily.
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
mtlgui said:
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
Click to expand...
Click to collapse
Basic introduction to native code and COM, including references to more background info: http://forum.xda-developers.com/showthread.php?t=1299134.
Callback from C++ -> COM -> C# can be done. Decompile the WP7 Acrobat Reader app. You'll see how it works.
Ciao,
Heathcliff74
Hey there,
I thought it was time to release something new
A bit of background storyline:
My last projects were all VB/.Net programs, and they were somewhat great, sure. But I was missing the Linux portability and the programs aren't available on all Windows version - Which bugged me a lot. So I finally started coding in Java again! I'm also porting Universal Android Toolkit to Java, so I can easily create a Linux version of that as well.
(If you want to make that happen faster, please donate to me. I managed to fix my laptop, but I've only got a 60GB HDD and I need that much space alone for Windows and I have no income, I'm only 16 )
Anyways, now that you know where I'm coming from, as I'm porting Universal Android Toolkit to Java, I need access to the registry to save the application's settings and easily access them. But unlike .Net languages, Java doesn't have built-in support for this kind of operation, so I looked around and grabbed bits and pieces of code and stuck them together into a Java Class Library.
Thus, RegIOLib was born.
It's licensed under the GPL 3.0 (License info included in the source).
Downloads
Sourceforge
Source Code
http://github.com/Beatsleigher/RegIOLib
EDIT:
I forgot to mention the following: To get access to the Windows registry, the application needs to be started with administrative rights!
You can either achieve this by starting the app via a launcher (Which is what I tempt to do) or by right-clicking the file and allowing it to run as admin.
Beatsleigher said:
It's licensed under the GPL 3.0 (License info included in the source).
Click to expand...
Click to collapse
So closed source applications may not use it?
nikwen said:
So closed source applications may not use it?
Click to expand...
Click to collapse
Of course they can use it
Just add a link to this thread and my website, done.
But if you're coming from some major company or something, then I would like something more
Beatsleigher said:
Of course they can use it
Just add a link to this thread and my website, done.
But if you're coming from some major company or something, then I would like something more
Click to expand...
Click to collapse
According to the GPL they can't because it requires the source code of derivative work to be published. That's the "problem" with that license if you use it for libraries.
Due to that the LGPL exists.
http://www.tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)
Limited commercial use. Must include source code. So no, GPL libraries and closed source applications do not mix.
An inelegant solution (which is the one I have always used actually) is to save settings in a file in %APPDATA%, no admin rights are required to edit files in there, or roll your own registry library for the application. Or Beatsleigher could LGPL it, but its his project, his license, I think he has full right to stick it under GPL if he wants to.
Although I dont think saving into a registry key is really cross platform Neither is %APPDATA% but using the %APPDATA% method is simple file read/write so on a cross platform application you can simply change the filepath dependent on the current execution environment.
System.getenv("APPDATA") will return the filepath for the current users APPDATA folder on windows. System.getProperty("user.home") works on linux and I think OSX to get the home directory. I dont think user.home works properly on windows. But it should be easy to switch between the 2 methods, add on an extra bit for where your settings file is and detect which to use at runtime.
Disadvantage (and to some advantage, depends on what the application is doing and whether the author likes it or not) is that saving configuration files as actual files means the user can play around with them. APPDATA is by default a hidden folder. But chances are most users dont even know what the registry is so in a way your settings might be more secure left in there.
Even possible to have an application load settings from the registry on windows and files on everything else.
SixSixSevenSeven said:
Or Beatsleigher could LGPL it, but its his project, his license, I think he has full right to stick it under GPL if he wants to.
Click to expand...
Click to collapse
Of course, he has that right. It's his code. The GNU even collected some reasons for sticking with the GPL.
Just wanted to point out that the GPL says that all derivative work (which includes programs that use libraries licenced under the GPL) must be GPL'ed (and therefore open source'd), too.
SixSixSevenSeven said:
http://www.tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)
Limited commercial use. Must include source code. So no, GPL libraries and closed source applications do not mix.
An inelegant solution (which is the one I have always used actually) is to save settings in a file in %APPDATA%, no admin rights are required to edit files in there, or roll your own registry library for the application. Or Beatsleigher could LGPL it, but its his project, his license, I think he has full right to stick it under GPL if he wants to.
Although I dont think saving into a registry key is really cross platform Neither is %APPDATA% but using the %APPDATA% method is simple file read/write so on a cross platform application you can simply change the filepath dependent on the current execution environment.
System.getenv("APPDATA") will return the filepath for the current users APPDATA folder on windows. System.getProperty("user.home") works on linux and I think OSX to get the home directory. I dont think user.home works properly on windows. But it should be easy to switch between the 2 methods, add on an extra bit for where your settings file is and detect which to use at runtime.
Disadvantage (and to some advantage, depends on what the application is doing and whether the author likes it or not) is that saving configuration files as actual files means the user can play around with them. APPDATA is by default a hidden folder. But chances are most users dont even know what the registry is so in a way your settings might be more secure left in there.
Even possible to have an application load settings from the registry on windows and files on everything else.
Click to expand...
Click to collapse
No, as far as I'm aware, only Windows has a registry. I could be wrong though. In the past 5-6 years that I've been developing, I was only developing in VB.Net - A decision that I highly regret nowadays
But I'm so used to being able to save my settings in the registry where no 'normal' user can modify them and cause the program to misbehave, that I'd like my java programs to do so as well.
And seeming as Universal Android Toolkit is a big, big project (I've been developing it for over a year now and I'm constantly adding new features and now I'm porting it to Java making it really hard to release, but I'll get there eventually.
As soon as I've got the major stuff sorted out, I think I'm ready to release a Pre-Release candidate for testing and bug-fixing, but like I said, I'm still having some trouble and then I need to figure out a way to get those settings saved on Mac OS and Linux machines, for which I've already written some classes, but only to install ADB and stuff... And I'm getting side-tracked again, aren't I?
Anywhosers, I think I'm going to leave it under the GPL, even though you're right and that that means that closed-source programs can't use it, but I'll think of something. Even if it's a commercial license, say someone pays 2$ per program. I don't know.
But for the thing you said with %AppData%, what you can do on Linux machines, is (in Java)
Code:
private final String userProf = System.getenv("user.home");
final File tempDir = new File(userProf + "/Temp/(.)<Program>/temp.file");
private void setupTempDir() {
Path tmp = tempDir.getParentFile().getPath();
if (!tmp.exists()) {
tempDir.createNewFile();
}
}
That should solve that problem, then you COULD create some sort of settings file, but then it's just a pain to get and save the settings when you're using multiple GUIs, like me.
And then there's another way of doing that in Android apps, which I haven't figured out yet, mainly because I haven't even started with Android apps and I don't have the hard drive space to do so :/
Beatsleigher said:
Anywhosers, I think I'm going to leave it under the GPL, even though you're right and that that means that closed-source programs can't use it, but I'll think of something. Even if it's a commercial license, say someone pays 2$ per program. I don't know.
Click to expand...
Click to collapse
OK, no problem. The GPL, however, says that you may not relicense it. :/
(All of my comments I've posted yet sound as if the GPL is a bad license. To clarify that: I don't think so. I prefer it for applications, but use the LGPL or Apache v2 license for libraries.)
Beatsleigher said:
(If you want to make that happen faster, please donate to me. I managed to fix my laptop, but I've only got a 60GB HDD and I need that much space alone for Windows and I have no income, I'm only 16 )
Click to expand...
Click to collapse
I'm 17 and I have a 64GB SSD. C#, C++ works great.
Anyway 700 lines of license make no sense. The same about the portable registry library for linux. Could you tell the purpose of it?
Useless guy said:
I'm 17 and I have a 64GB SSD. C#, C++ works great.
Anyway 700 lines of license make no sense. The same about the portable registry library for linux. Could you tell the purpose of it?
Click to expand...
Click to collapse
GPL isn't 700 lines last time I checked, also I left a link to a simple description of it above (I do love tldrlegal).
There is no registry for linux, no one mentioned a portable registry for linux.
SixSixSevenSeven said:
GPL isn't 700 lines last time I checked, also I left a link to a simple description of it above (I do love tldrlegal).
There is no registry for linux, no one mentioned a portable registry for linux.
Click to expand...
Click to collapse
I did
Anyways, now that you know where I'm coming from, as I'm porting Universal Android Toolkit to Java, I need access to the registry to save the application's settings and easily access them.
Click to expand...
Click to collapse
nikwen said:
OK, no problem. The GPL, however, says that you may not relicense it. :/
(All of my comments I've posted yet sound as if the GPL is a bad license. To clarify that: I don't think so. I prefer it for applications, but use the LGPL or Apache v2 license for libraries.)
Click to expand...
Click to collapse
I'm working on a license for it and any other such things. So I'll release it again for commercial and closed-source programs when it's done.
And yes, it does sound like you think it's a bad license. But meh. Everyone has their own opinion, I guess.
Useless guy said:
I'm 17 and I have a 64GB SSD. C#, C++ works great.
Anyway 700 lines of license make no sense. The same about the portable registry library for linux. Could you tell the purpose of it?
Click to expand...
Click to collapse
GPL isn' 700 lines.
That's cool for you, that you've got that stuff. I don't. Anyways, I'm getting away from .Net languages, and C# is easy for anyone to learn. Especially if they're coming from VB, like me.
C++ isn#'t my kinda thing, as you can't natively create GUIs in it. You always need some kind of library for that sort of stuff.
And I didn't intend this for use with Linux. Everyone that has basic knowledge of these operating systems knows that Linux, BSD, Mac OS etc. don't have registries. And I never even noted that I'm attempting to use registry stuff in Linux. I said I'm porting Universal Android Toolkit to JAVA, and that I need access to the WINDOWS registry to save the application's settings in the reg, so that users can actively change the settings if the program starts misbehaving.
Useless guy said:
I did
Click to expand...
Click to collapse
I said JAVA, not Linux. What I probably did say, however, is that I'm porting my program to Java so that it can easily be ported to said OSs. But never that I'm attempting to save my settings in the registry in all OSs.
Beatsleigher said:
C++ isn#'t my kinda thing, as you can't natively create GUIs in it. You always need some kind of library for that sort of stuff.
Click to expand...
Click to collapse
Lolwhat?
Beatsleigher said:
C++ isn#'t my kinda thing, as you can't natively create GUIs in it. You always need some kind of library for that sort of stuff..
Click to expand...
Click to collapse
Errm, those libraries are written in C or C++... native code such as C and C++ are the only languages which can create GUI's. VB.net/C#/anything else .NET use libraries too which in the case of WinForms and WPF are just wrappers around win32 functionality implemented in C.
Beatsleigher said:
And yes, it does sound like you think it's a bad license. But meh. Everyone has their own opinion, I guess.
Click to expand...
Click to collapse
I love the GPL. I use it for everything (except libraries).
But I'll stop the off-topic now.