Related
[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.
Rumors are flying that bluestacks will bring their newly touch-optimized app to RT, giving us access to Android Apps. Anyone else heard something similar?
Also, is there any equivalent we could get our hands on right now, like an open-source equivalent that could be ported? It seems ridiculous that to run native ARM apps on an ARM platform we need to port an ARM environment from x86 back to ARM again... there should be a simpler way. All pure speculation of course, but it seems like it should be possible. So, outside of a bluestacks port, how could Android apps be run on an RT device?
Install a Linux kernel and a Dalvik runtime... Seriously, do you realize how silly what you're asking for sounds?
"Why can't we run Linux apps on Windows? It's an x86 processor too..." (Note: Android is not all ARM.)
Stuff like Bluestacks is a huge, complicated project.
GoodDayToDie said:
Install a Linux kernel and a Dalvik runtime... Seriously, do you realize how silly what you're asking for sounds?
"Why can't we run Linux apps on Windows? It's an x86 processor too..." (Note: Android is not all ARM.)
Stuff like Bluestacks is a huge, complicated project.
Click to expand...
Click to collapse
Seriously your a bore
rw6497 said:
Seriously your a bore
Click to expand...
Click to collapse
He's not a bore, he's realistic. It's not his fault that people make outrageous requests all the time and expect them to be fulfilled. I find it quite irritating too, especially when people PM me and ask me again because it's been posted in a thread that it's not possible without an unreasonable amount of work (that we're not going to do on our spare time) and they don't like that answer.
You guys have to remember, we're doing this for free. We're not obligated to port every single program you guys throw at us. If you don't like that, learn how to port them yourselves.
I don't want to spawn an argument...
I'm not asking anything from anyone, I'm just curious about some rumors and inquisitive about possibilities. I'm not all "OMG! netham45! Can u plz make this run android!? And then iOS! And PlayStation games!" I respect netham45 a ton and think his work is amazing.
I'm just opening discussion here.
For comparison, consider the Wine project: well over a decade of development (much longer than Android has even existed) to have an open-source tool that can run many x86 Windows apps on x86 Linux. Or consider Cygwin, which can't even run x86 Linux apps on x86 Windows; they must be recompiled for Cygwin first. Expecting that some equivalent program to run ARM Dalvik/Linux apps on ARM Windows would have just popped out of the woodwork in a usable state - even as usable as Wine, which is nowhere near 100% app compatibility yet - is quite unrealistic.
jtg007 said:
It seems ridiculous that to run native ARM apps on an ARM platform we need to port an ARM environment from x86 back to ARM again...
Click to expand...
Click to collapse
Bluestacks involves ZERO emulation of ARM. Android apps are run inside the dalvik virtual machine (itself a register based version of the java virtual machine). To run an android app just needs a DVM and its class library: bluestacks pretty much does this. Android native code apps do then get complicated yes but then the android NDK has a rather convenient feature that bluestacks can exploit.
NDK compiles native binaries for both x86 and ARMv7 by default (note default, you can over-ride which platforms it compiles for, I believe ARMv6, ARMv6hf, ARMv7, MIPS and x86_32 are available options although I am not 100% sure on the exact arm versions so might be wrong). Bluestacks is only running on x86 and x86_64 machines. x86_64 machines can safely run x86_32 code. So really bluestacks when it encounters a native app "just" has to run the x86 binary the NDK produces on windows/mac with a compatibility layer. Still a complex job of course.
Bluestacks on windows RT could actually take the same shortcut bluestacks on windows and OSX takes in regards to native code, just with the ARM binaries running in a compatibility layer instead of the x86 binaries.
Bluestacks still has to mess about a bit exposing hardware to "android" correctly and handling a few extra bits and pieces but generally it works rather well and in theory could work on windows RT. However in practise it might have some speed sacrifices which will become much more apparent seeming as the guts of most windows RT devices are also the guts of android devices, now you've introduced slowdowns and the RT device will be slower than if it just ran android in the first place, might not be an issue on some less intensive apps but something like shadowgun would probably have noticeable slowdowns. Also I doubt a company like that behind bluestacks wants to develop for jailbroken devices, microsoft certainly wouldnt give permission for something along the same lines to be included on the windows store. The other major issue is OpenGL ES. Non existant on windows RT, bluestacks I believe converts OpenGL ES calls to full OpenGL. We dont have that either. We have directX or software. In theory you could convert the OpenGL ES calls to directX, certainly not impossible, but would certainly be alot of work.
TL;DR. Its theoretically possible to have android apps running on windows RT. There are too many issues to make it viable at this moment in time.
Future updates to what microsoft does and doesn't allow on RT (OpenGLES I'm looking at you) and knowledge/hacks (GLES>DX?) gained as more people take a poke at it might help nudge a dalvik VM on RT in the right direction in future though.
I wonder how relevant this is
http://www.pcworld.com/article/2018...tility-to-run-android-apps-on-windows-rt.html
Interesting, but too early to call "relevant", I think. That article is over two months old; has anybody heard anything since? It's possible that the project is being worked on internally already and will be available soon, but don't count on it.
That said, we now have three ways to get software onto RT:
1. The Windows Store. Official, easy, and can be monetized, but requires Microsoft approval, must run in Metro, and restricts available APIs.
2. Sideloaded Metro app. Semi-official (no hacks needed) but requires going through the (fairly simple and free) process of equipping your device with a developer license. Still runs in Metro and the AppContainer sandbox, but you can somewhat ignore Microsoft's approval process and use any API that is reachable.
3. ARM-compiled desktop app. Requires a jailbroken device, which MS could later try to block, but for now it's easy. No API or sandbox restrictions, aside from the lack of certain features (like OpenGL) on RT.
I wonder which one Bluestacks would choose? #1 is the most beneficial to them, if they can do it, and if MS rejects it they could always go with #2 as a fallback. #3 is the easiest for them, most likely, but carries the most risk. There's also, of course, item #4: forget RT, and keep going with x86 Windows and OS X, where all the customers are.
I dont think they would actually have to go as far as option 3. ModernUI would probably be more than enough for bluestacks.
I wonder if microsoft would try and prevent bluestacks from the marketplace. I guess as far as they are concerned it might improve the image of their devices if they can run android apps too (minimizing costs of migration to RT from android for enterprise customers too, although it seems ipad's took off mostly in enterprise).
I'm simply inquiring about how to make a x86 application into an ARM compatible application. I've acquired the source code of an old game, Lugaru, just to practice this. What would I need to start off with doing? I'm having trouble uploading, so you can download the source here: "https://code.google.com/p/lugaru/downloads/list". I have no experience in C or C++, only Java.
Just compiling for ARM doesn't mean it will run in the WinRT environment. Theoretically, getting it to compile on ARM and run in desktop mode on a jailbroken RT device would be trivial. On mobile here so I can't view the source easily, bit depending on how it's written, it will likely require porting from Java to C++ or C# and rewriting the graphics in DirectX. You're better off taking a few Windows 8 Dev tutorials first, honestly.
OK. First of all: there's already a thread about this. In fact, I think there's a couple. They've been inactive for a while, so you'll need to find them with search, but check the RT Dev&Hacking sub-forum for "porting apps" and you should get multiple hits.
Second: I think Lugaru was looked at before. It's possible, but it won't be easy. The build system it uses (CMake) does not, so far as I know, target Win32/ARM yet, so that will either require some manual building or some tweaking of the configuration. It *should* compile under MSVC, though; in fact, I think CMake can produce Visual Studio project files. Using one of those project files, just change the target platform from x86 (Win32) to ARM (you'll probably have to add it).
Lugaru has a lot of dependencies. We've already ported some of them, like the SDL and OGG/Vorbis. Others may need to be ported.
One problem often encountered with porting games is that Windows RT lacks an OpenGL driver. Games written against DirectX will probably work, although the compatibility layer code for older DX versions is missing. There is an OGL->DX conversion/wrapper library which can support many OGL programs (at some performance cost) but I don't know how practical it is to compile against it; never tried. Links to ported libraries are in the "ported apps" thread in my signature.
GoodDayToDie said:
I think Lugaru was looked at before. It's possible, but it won't be easy. The build system it uses (CMake) does not, so far as I know, target Win32/ARM yet, so that will either require some manual building or some tweaking of the configuration. It *should* compile under MSVC, though; in fact, I think CMake can produce Visual Studio project files. Using one of those project files, just change the target platform from x86 (Win32) to ARM (you'll probably have to add it).
Lugaru has a lot of dependencies. We've already ported some of them, like the SDL and OGG/Vorbis. Others may need to be ported.
One problem often encountered with porting games is that Windows RT lacks an OpenGL driver. Games written against DirectX will probably work, although the compatibility layer code for older DX versions is missing. There is an OGL->DX conversion/wrapper library which can support many OGL programs (at some performance cost) but I don't know how practical it is to compile against it; never tried. Links to ported libraries are in the "ported apps" thread in my signature.
Click to expand...
Click to collapse
I wasn't thinking it would be easy, I was wondering if it was possible. Thank you for the information, it was very helpful. I was not aware that CMake could produce Visual Studio project files. That may make this a little easier. CMake does not target Win32/ARM at all like you thought, so I may ask another couple of questions while playing around with the config. Will I have to port it to DX11?
I think anything DX9 or later actually works. If the code already target OGL (instead of just targeting SDL and using whatever SDL's preferred back-end on that platform is) then you could try re-writing it in D3D/D2D, or using the OGL-to-DX wrapper I mentioned.
GoodDayToDie said:
OK. First of all: there's already a thread about this. In fact, I think there's a couple. They've been inactive for a while, so you'll need to find them with search, but check the RT Dev&Hacking sub-forum for "porting apps" and you should get multiple hits.
Second: I think Lugaru was looked at before. It's possible, but it won't be easy. The build system it uses (CMake) does not, so far as I know, target Win32/ARM yet, so that will either require some manual building or some tweaking of the configuration. It *should* compile under MSVC, though; in fact, I think CMake can produce Visual Studio project files. Using one of those project files, just change the target platform from x86 (Win32) to ARM (you'll probably have to add it).
Lugaru has a lot of dependencies. We've already ported some of them, like the SDL and OGG/Vorbis. Others may need to be ported.
One problem often encountered with porting games is that Windows RT lacks an OpenGL driver. Games written against DirectX will probably work, although the compatibility layer code for older DX versions is missing. There is an OGL->DX conversion/wrapper library which can support many OGL programs (at some performance cost) but I don't know how practical it is to compile against it; never tried. Links to ported libraries are in the "ported apps" thread in my signature.
Click to expand...
Click to collapse
Actually CMake can target MSVC/ARM. Please check ReactOS's source code. I tried to build an ARM version before so I know that will work.
Can it now? Well, that's handy. Thanks for the tip! Can't test this for a while, but if anybody wants to give it a shot before I have time let us all know how it goes!
Hello.
I was came across a charming little game and I was wondering if anyone would be able to port it to RT?
The game is, of course called Ending. I would have posted this in the RT Development thread but I haven't done enough posts for me to be able to do that so... sorry? Anyway, if anyone can port this then, well, thanks!
The source code, windows version, OSX version and Ubuntu version are all available here:
Oh, hang on, I don't seem to be able to post links either. just search 'robotacid ending' on google and it should be the first result. It'll be a page with the flash game and links to source code and the other stuff I said.
As it is flash there is little we can do for a native port. RT does include flashplayer in internet explorer so if there is a way to run Ending in browser then that should be an option, I'm not a flash dev so I'll let someone with more experience than I report on that one.
I'm a newbie to all of this and I've got to say, I'm pretty annoyed how little we can actually port. Is that due to the RT system or is it just how much Microsoft Visual Studio supports? Also does anyone know how to run flash games on RT if that's what I have to do.
Ruffa-Duffa said:
I'm a newbie to all of this and I've got to say, I'm pretty annoyed how little we can actually port. Is that due to the RT system or is it just how much Microsoft Visual Studio supports? Also does anyone know how to run flash games on RT if that's what I have to do.
Click to expand...
Click to collapse
You can't port a flash game to any os without its source anyways, thats not an RT limitation. To run flash just open the link or swf in the desktop version of internet explorer, I believe you need to modify some registry values to open them in the metro one.
I can play it in both desktop and metro IE 11. For a fullscreen experience just go to the URL + game.swf. I'm not sure what you want in a port. If you want me to put a that swf in a webpage and wrap it in a windows app and submit it to the store, I could do that, I have a dev license. If you want it ported to DirectX or JavaScript, sure it's doable, but a bit more work. Might be fun for a beginning project.
drearyworlds said:
I can play it in both desktop and metro IE 11. For a fullscreen experience just go to the URL + game.swf. I'm not sure what you want in a port. If you want me to put a that swf in a webpage and wrap it in a windows app and submit it to the store, I could do that, I have a dev license. If you want it ported to DirectX or JavaScript, sure it's doable, but a bit more work. Might be fun for a beginning project.
Click to expand...
Click to collapse
Erm... I'm not really fussy. I actually have this game on my iPod anyway so I don't really need or want it that much on my RT. I just figured it was a neat little game that had the source code available and it looked pretty simple so I assumed it might be able to ported which would hopefully benefit someone. But if you want to take a crack at it feel free.
Ruffa-Duffa said:
I'm a newbie to all of this and I've got to say, I'm pretty annoyed how little we can actually port. Is that due to the RT system or is it just how much Microsoft Visual Studio supports?(...)
Click to expand...
Click to collapse
Current porting desktop applications to run natively in Windows RT basically requires the following:
1. It has to be open-source.
2. It has to be compilable in Visual Studio. (No GCC or other fancy compilers)
1 is absolutely mandatory and this requirement will go nowhere (interestingly, this is what most people ignore when they come asking for a port)
2 can possibly be circumvented in the near future if the porting work goes more advanced. The VLC team has been working on a GCC port for Windows RT (ARM) as far as I remember, and you can also run Python & Perl code directly in Windows RT without going through Visual Studio.
While some applications are compilable in VS, they might require other components that might not compile there and bummer. But the main limitations are the two lines above.
I know this question will come with some confused comments and answers... so Ill ask the question and qualify my question with some examples why I am asking and of what I am not asking.
Question: What is the likelihood of getting/shoehorning Full x86 Windows 10 (or 8.1 until 10 releases) onto this phone?
Qualifying statements:
1. I am not asking about Windows Phone OS at all. Everyone knows Microsoft screwed the pooch during their shift from Windows Mobile 6.5 to Windows Phone 7 then again from Windows Phone 7 to Windows Phone 8. That is why so many of us jumped ship from Microsoft's Phone offerings over to Android in 2010. This is 5 years later and Microsoft might be able to get some market share back, but only if they pull their head out of their a$$....
2. (Example of irrelevant answer... Why do you want full Windows when there is Win RT or WinPho???lol!!!!LMFAO!!!! TrolllFACE!!!)
There are plenty of usage cases to justify full x86 Windows on a mobile device. Microsoft and Intel are pushing on the tablet market but for some reason they have not begun to crack the phone market with Full WinTel.... Simply put, If someone is willing to pick up a Windows 8.1 x86 tablet with 1GB or 2GB of RAM for $200 or $300 bucks then they should be ok picking up a similar device with 4GB of RAM and the ability to make calls.
3. (Another example of irrelevant answer...But Android!!!! It rulz!!!)
First off I am an avid android user. We started with My wife and I getting the EVO 4G in 2010, then EVO 3D in 2011 (I know...), then Note 2 in 2012, and My wife switching out the Note 2 for the Huawei Ascend Mate 2 last year. Im holding on to my Note 2 for the final stretch with its 9300 mAh Zero Lemon battery. All phones we've gotten have been rooted and customized by me. I use Bluestacks and/or Andy OS on all of my Windows PCs and have owned several Android Tablets. In short I prefer Android over Windows phone and iOS and whatever else is out there... Now in saying that, I feel a full Windows device in a phone with sufficient processor and RAM would be able to run Windows as its main OS and Android as an emulator to satisfy my Android needs.
Very well put, I'm also interested in this.
Sent from my MT2L03 using Tapatalk
Also interested in this!
I think this needs Microsoft's direct support. IMHO these are some blockades the community will be met with:
1. Since Android uses a boot.img as stage2, some work have to be done for the boot image to be able to chainload Windows. Vanilla installation goes out of the equation.
2. Figuring out how to chainload a proprietary OS properly is, well, hard.
3. It seems like the device uses some special Intel modem and wireless chipset. Porting won't be easy (Look at Intel PRO...)
4. Although 5.5in is GIGANTIC for a phone, maybe explorer or metro won't be able to fit in it?
5. Onboard storage is lackluster to host a full desktop Windows.
6. Windows doesn't even have a dialer.
But generally, this is a great idea! Being able to run x86 apps on a phone, oh the feels!
I'd be very interested if it would run full x86 or x64 Windows! However as stated, I doubt that will happen.
Even then it would be a bit limited and the main issue I would imagine to be space. The screen is quite small for a 1080p window to display on. I'd want to probably run a 720p res for larger buttons and such, might fit a bit better.
Perhaps if you could have it all run off a memory card, but then it would be rather slow to boot and cache stuff?
Here check out this small presentation. Something could be possible with the virtualization extensions that intel processor has.
This totally depends on :
- how well Asus releases the source code.
- Bootloader unlockable or not, i.e. ways to work around the secure boot.
I tried similar things on Lenovo K900 which is running Z2580. Lenovo's open source release was just horrible since even building the kernel was difficult due to lack of info.
I was able to eventually built the kernel with KVM enabled, but was having trouble signing the kernel for the bootloader.
Just force loading the kvm.ko was not successful either since the stock kernel had some feature missing required by KVM.
I would be interested to work on this phone again if we can form a group.
kazuken said:
Here check out this small presentation. Something could be possible with the virtualization extensions that intel processor has.
Click to expand...
Click to collapse
chinabull said:
This totally depends on :
- how well Asus releases the source code.
- Bootloader unlockable or not, i.e. ways to work around the secure boot.
I tried similar things on Lenovo K900 which is running Z2580. Lenovo's open source release was just horrible since even building the kernel was difficult due to lack of info.
I was able to eventually built the kernel with KVM enabled, but was having trouble signing the kernel for the bootloader.
Just force loading the kvm.ko was not successful either since the stock kernel had some feature missing required by KVM.
I would be interested to work on this phone again if we can form a group.
Click to expand...
Click to collapse
sure we can start a group on slack.com
some other things that also come to my mind:
wine for x86
docker for x86
debian chroot
wine already has some ARM support
This would likely be much easier... Notice the 'high end' system reqs?
http://www.ubuntu.com/tablet/operators-and-oems
I think the biggest problem for Windows would be wrestling with the PowerVR-based gpu.. Those stupid things are usually a roadblock in just about every interesting project..
kazuken said:
sure we can start a group on slack.com
some other things that also come to my mind:
wine for x86
docker for x86
debian chroot
wine already has some ARM support
Click to expand...
Click to collapse
Sorry for ressurecting this old thread but you would definitely be able to run Linux X86 on chroot. Then through wine you'd be able to run a lot of windows apps. Only issue is that performance would be low *unless* you'd output the GUI to android's framebuffer (FB0) which would require a kernel supporting this (outputting to framebuffer) which in turn would need Asus releasing the kernel sources so that to bake FB support.
So yeah it's all doable even with relatively good performance and by outputting the image (through MHL or chromecast) into the big screen would give us a X86 PC on the go. In fact I'd prefer it from running windows X86 natively because then you'd be losing calls and notifications... Imagine your *phone* running all your PC's software (well almost all as wine often has issues). You can buy one of those 128gb micro sds and your "phone" would have plenty of space for your (PC) data...
Stevethegreat said:
Sorry for ressurecting this old thread but you would definitely be able to run Linux X86 on chroot. Then through wine you'd be able to run a lot of windows apps. Only issue is that performance would be low *unless* you'd output the GUI to android's framebuffer (FB0) which would require a kernel supporting this (outputting to framebuffer) which in turn would need Asus releasing the kernel sources so that to bake FB support.
So yeah it's all doable even with relatively good performance and by outputting the image (through MHL or chromecast) into the big screen would give us a X86 PC on the go. In fact I'd prefer it from running windows X86 natively because then you'd be losing calls and notifications... Imagine your *phone* running all your PC's software (well almost all as wine often has issues). You can buy one of those 128gb micro sds and your "phone" would have plenty of space for your (PC) data...
Click to expand...
Click to collapse
I tried it out. you can get GNUroot and GNUroot wheezy x86 on play store. I was able to get fluxbox with tightvncserver running (though no apps, but was able to get an image in vnc) i am now going to try lxde and then see if nomachine 4.0 will work. wine should be able to run photoshop cs2.
kazuken said:
I tried it out. you can get GNUroot and GNUroot wheezy x86 on play store. I was able to get fluxbox with tightvncserver running (though no apps, but was able to get an image in vnc) i am now going to try lxde and then see if nomachine 4.0 will work. wine should be able to run photoshop cs2.
Click to expand...
Click to collapse
Problem with running your gui on a VNC server is that it is slow. It's (far) easier to setup though.
On my android machines I prefer to (basically) output an X Server window on the (machine's) frame buffer. You get real time performance (almost the same as if you had installed the OS natively), plus you get sound which is useful if one wants to run sound and video editing software (or plainly listen to music ). It's (quite) harder to setup but it has all been streamlined lately by a play store app named linuxdeploy (IIRC it has added X86 distros support lately).
Yeah... Don't use vnc, use xserver-xsdl . It's in the app store. Best Android X server. In your chroot, export DISPLAY=:0 after starting it up.
Sent from my ASUS_Z00AD using XDA Free mobile app
ycavan said:
Yeah... Don't use vnc, use xserver-xsdl . It's in the app store. Best Android X server. In your chroot, export DISPLAY=:0 after starting it up.
Sent from my ASUS_Z00AD using XDA Free mobile app
Click to expand...
Click to collapse
That's a great solution too! Hadn't thought to recommend it. It's easy to setup too.
Still outputting directly to framebuffer instead of an xserver app is quite faster (even than that!). But I'd expect the Xserver-XSDL performance to be quite good too.
OMG, this is SO interesting. I have been looking forward to put windows desktop in my phone since ages. Virtualization never let you go any further than Winxp. But now, this is another story. I am thinking of getting one of my own to help with the testing
Keep it up guys!
I ran photoshop cs2, via xserver xsdl, takes a while to load but eventually does, but its very hard to drag windows via xserver xsdl. i tried with vnc and was able to open a picture taken from the zenfone's camera and adjust levels. its alot easier to use a physical mouse and keyboard. but here are some screenshots of it running all on the android. it took brute force to create the x with the paintbrush and to drag a window. I ran it at 720p, also at 1080p. photoshop loads a lot quicker using xserver xsdl vs vnc.
You can change mouse settings when you start up xserver-xsdl. By default it's set up like the screen is a laptop touch pad.
The other thing you might want to try is a different Windows manager. I prefer fvwm2 since it's very light.
Sent from my ASUS_Z00AD using XDA Free mobile app
*irrelevant reply alert*
This takes me back to running Linux on the Windows-based XDA Exec. Those were the days.
Anyway, this is a great idea and you're finding some interesting workarounds, but I think you should be looking to get Windows to run natively. Sure, it doesn't have a dialler, but I'm sure someone can hook something up - especially if the interface is anything like the old Voice Modems from when we could only get our internets at 56kbps. (You kids don't know you're born! In my day, etc)
Meanwhile, in the Enterprise world where we try to reduce the costs of people having a whole processor each that they carry around with them, we're looking at using PCoIP to deliver a PC experience on a tablet. Sure, it's a little laggy (we're talking milliseconds on WiFi, though) but you get a lot of processing power, and if you're using Amazon you'll get NVidia rendering too. That's more for workstation graphics - CAD etc, rather than gaming. But then, if you're looking at installing Windows on a Phone, you're probably not going to be trying to play GTA5 on it.
Again, this reply is irrelevant because I realise you probably don't want to shell out $20-$40 per month on a virtual machine with a full Office suite. Plus, it's less fun to play with and not quite as much of an achievement to have set up something that works out of the box.
Native Linux 64 bit maybe, you get a much better OS, customizable, better resources management, open source, faster and waste less battery plus you can create your own mobile friendly interface just like Ubuntu Touch. Someone said it might be possible to port dialer, modem and other driver's concept since android is linux based. Microsoft is a handicapped development private code and as linux creator affirmed, its therefore a crappy OS lol There is steam on linux and it can run OpenGL games faster with the same hw due to uncluttered OS.
The hardest part will be GPU acceleration.
aziz07 said:
Native Linux 64 bit maybe, you get a much better OS, customizable, better resources management, open source, faster and waste less battery plus you can create your own mobile friendly interface just like Ubuntu Touch. Someone said it might be possible to port dialer, modem and other driver's concept since android is linux based. Microsoft is a handicapped development private code and as linux creator affirmed, its therefore a crappy OS lol There is steam on linux and it can run OpenGL games faster with the same hw due to uncluttered OS.
The hardest part will be GPU acceleration.
Click to expand...
Click to collapse
The .Net Framework is already Open Source. It's likely Windows 10 will go Open Source at some point. It's said to be the "last version of Windows" - probably similarly to the way MacOS X hasn't been replaced with MacOS XI. (There will still be a market for desktops when we have 128bit CPUs, and they won't just stick with the same 64bit kernel.)