Related
Hi folks
Recenty I got the Windows XP Embedded kit, and I was really satisfied and surprised with the performance of the directly built system on an old machine like a P1 @ 200 MHz with 64 MB of RAM, without a hard disk.
The main goal would be to run truly win32 apps on mobile devices, to give better functionality and compatibility.
Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
What might be difficult are these things:
-Getting win32 drivers for built-in devices (ex. integrated SDIO/USB WLAN, BT adapter, touchscreen, and sound devices, and apps for them!)
-Saving user data on turning off (Ebmedded systems are designed for a workstation, like a cash register: prebuilt apps, and nothing more comfort ) like WM200x
If anybody has any suggestion are to get a warm welcome
bye
Yet the builder supports x86 architecture only, but cannot be a big problem to port it to ARM pocessors.
Click to expand...
Click to collapse
Are you kidding me?
This would mean reverse engineering and recompiling every binary in the OS.
Do you have any idea how many hours something like that would take?
yup, you're right, but in theory it's possibe. I've seen a running DOS on a Microchip micro-controller, or for example the Atmel STK 1000 is Linux based, also seen an mPlayer app operational on the demo board at the college.
as you see, i'm not an experienced programmer, but i'm not afraid to ask
Yeah, the basic low-level binaries must be recompiled, and once it's ok, it might be usable with regular win32 apps, until you run an old DOS app, wich directly access the hardware.
A few years ago i was able to port Z80 software to 8086, and it wasn't easy.
I don't really know these things, just want to see opinions, possibilities, and suggestions.
exe files are binarys which are instructions directly for the cpu
it's not parsed by the operating system
so compiling the os is not enough every application needs to be recompiled too
The programs you mentioned have source available in one way or another (since DOS is very old there are clones, like freeDOS).
If you have the full source for an app and the right compiler, porting it to another CPU is feasible.
But, this is not the case with embedded XP. Getting the full source is impossible which means most of the system will have to be rewritten from scratch.
Just look at the Wine project to see what it takes, and they "have it easy" - they are just trying to simulate the APIs not change processor architecture. (Lets make it clear - ARM instruction set is very different from x86).
And as Rudegar said it will not let you run any program that has not been specially compiled for ARM CPU.
I know it sounds like we are trying to kill you idea here but its nothing personal, unfortunately it just isn't feasible. We would all like to be able to run desktop apps on our devices, but simply having embedded XP on them would not accomplish that. Also while many old DOS apps can be run using various emulators like pocketDOS, almost all Win32 apps take more resources than our little gadgets can offer.
I am fairly sure though that in 5 -10 years that problem will be fixed.
<_< man hours or not, reveng'ing this will have a bigger impact than just winDOS Mobile devices. Desktops have a use for this, definitely (because the Vista-Only crap is starting to hit the market). Too bad they don't provide assembly in programming classes anymore, obviously because they don't want anyone else to reverse engineer anything and spoil their foisting fun. <_<
In any case, IIRC XP Embedded is missing the install/uninstall engine, so you can't customize it after it's flashed onto the board. This isn't quite a good start - XPLite or 98Lite are better for reverse engineering from scratch (but they're too powerful for mobile devices).
The other alternative is porting ReactOS, which is a reimplementation of W2K. Those guys are "having a lot of fun" getting things to work, tho. <_<
Maybye Windows CE6 yes, but Windows XP Embedded no, because they must run at 686-AT/X platform IMB. Sorry of my English
linux would be a path
with most linux programs you can compile them yourself
using good old
./configure
make
make install
of cause gui programs could have issues displaying correct
on such a small screen
You MIGHT be able to pull it off by installing a minimal (very!) WinMo firmware and then have it autorun Bochs, which is known to be able to run the PC version of XP.. A customised, thinned-down XPe image should run fine under Bochs.
--W5i2
I found source code for USB camera driver from Microsoft (usbcam.dll) it is for Windows CE and it is compatible with Windows Mobile. It need to be compiled for IntelXscale and/or ARM (depending on device)... Maybe someone here can try. It support around 30 usb web camera models with USB 1 and 2. It include also filter:
; Register JPEG -> RGB filter
; This filter is intended for use with the usbcam.dll, which
; produces output in the JPEG/MJPEG formats
Click to expand...
Click to collapse
There are 4 files:
usbcam.dll (Driver)
jpeg2rgb.dll (Support file - Filter)
usbcam.reg
jpeg2rgb.reg
Developer of this code confirm that it can be compiled for WM 5/6
Microsoft has released a webcam driver (with source) that does support a Direct Show interface. It is written for CE 6, but could be recompiled for Win Mobile 5/6 since they support Direct Show capture drivers.
Click to expand...
Click to collapse
Please help, im sure that it will work, there is many devices with USB Host and web cameras are so cheap... That would be great if someone will help !
so this means that with a usb-host capable device,
it is possible to use an external camera?
xeirwn said:
so this means that with a usb-host capable device,
it is possible to use an external camera?
Click to expand...
Click to collapse
If someone will compile it... yes
Here is quote from description:
"The driver supports both USB 1.x and 2.0 (high-speed) cameras. The driver will
expose both uncompressed and MJPEG modes, if supported by the camera."
anyone ? This should be simple...
This would be very cool
to connect a webcam to the phone
(right, that's what it's for?)
NisseDILLIGAF said:
This would be very cool
to connect a webcam to the phone
(right, that's what it's for?)
Click to expand...
Click to collapse
Yes, but USB host is requried...
Ehh it look like I must compile it myself... So many programmers here but noone can do it...
my device Xda Flame has USB OTG version 1.2 compliant. (USB On-The-Go)
and can connect to HD, flash memory, keyboard, mouse etc.
I have posted on our forum http://xdaflameusers.com/viewtopic.php?id=1447
Still no reply..
Really hope someone makes use of this
If you check the developer's link, you can download webcam.dll file (from WebCam_100.zip )
also checked the discussions, a CamTest app is mentioned but where is it??
webcamWhitePaper.doc is also interesting..
EDIT: found the Camtest but no exe file! dl from http://devpi.free.fr/wince/camtest2_cpp.zip
sorry for double posting, but I think I found the answer from the developer himself
As for your initial question, I'm not sure this driver will do what you want. You to want to use the webcam with a Windows Mobile system. If however, you want to display the image through media player, this driver won't help. It doesn't support a proper Direct Show interface.
Microsoft has released a webcam driver (with source) that does support a Direct Show interface. It is written for CE 6, but could be recompiled for Win Mobile 5/6 since they support Direct Show capture drivers. The link for that driver is
http://www.microsoft.com/downloads/...c0-a4ae-42cc-abd0-c466787c11f2&DisplayLang=en
Click to expand...
Click to collapse
copied from here:
http://www.codeplex.com/cewebcam/Thread/View.aspx?ThreadId=17584
I was very close to run it... I used webcam.dll from codeplex (version for arm) but it was compiled for win ce... I used registry key whiich was included to regiister hardware type. Wheen I connected camera it as usualy ask for drivver... but surprise here - it doesn't do this again as usualy, instead of this it show "error installing driver". Camera test is not exe becouse it like driver need to be compiled for windows mobile like driver. I am 100% sure that if driver, filter and cam test app will be compiled for windows mobile it will work fine.... but we need someone who will do it....
Shame that noone here can help us... developers...
What Happend
Wutsup ppl it seems no one is interested anymore in this, if anybody got progress or someone got compiled wm6,wm5 drivers plz share with us
I think nobody's interested because all our HTC devices have cameras in them already (and most new ones have 2). Why plug in another camera?
I need the same thing...
Industrial application with a USB camera hanging off a windows mobile device. Has anybody compiled this driver into windows mobile?
Thanks,
Linda
The project sounds interesting, but I don't think the ExtUSB in HTC devices support host mode. Plus, having a camera dangling from the only data/ power port on the device sounds like a waste.
What would be more interesting is to find a way to connect a web cam to a bluetooth device. My phone has a back camera, but I'd still love to buy a bluetooth camera to attach to the phone.
Hello all,
I'm now the proud owner of an android phone (htc desire) and as a hobbiest programmer i'm of course intrested in making (free) apps for it. I come from a linux based devices background (like gp2x, wiz, dingoo a320) etc. So i'm used to the gcc toolchains and libs and I read a bit around about android programming. Am i correct in saying that is not possible to just use a gcc toolchain for programming android apps since android uses some sort of java virtual machine ?
Or is this possible after all, just like one woud make apps for linux based devices. I think the Answer will be NO but i still ask since i wasn't certain and did not find that much information about it.
Suppose it is not possible, my only option for porting linux based games / apps would be to use the NDK and split up the main functions of a game and make a shared lib out of it, which could be called using JNI from java right ?
But i have a question if this is the case...
I can't really imagine that all phone manufactures use the same hardware in their phone or even the same architecture, so suppose i would use the NDK to create a shared lib with basic functions of a game i wish to port, wouldn't this lib need to be build for the specific architecture of a certain phone and thus could only work on that phone ? or are all android phones arm based ?
So you could say my question basically comes down to this :
Will Using the ndk and apps created with it, be less compatible then a java only app for all the droid phones out there ?
thanks
hmm seems i can answer my own questions now, i hadn't looked at the official ndk site itselve yet and did not know it would have all the info i needed.
So using gcc toolchains only does not work,
android uses a (modified ?)java virtual machine called dalvik
de libraries do have to be build for a specific architecture, and all droid's (phones) do seem to run on arm, but in the future the x86 architecture will be supported as well.
HOWEVER,
one can target ARMv5TE or ARMv7-A (and in the future x86) and include the needed libs (per architecture) in the apk file, the droid system will do the rest by checking if a lib for the specific architecture is availible or not.
also it's worth to note that ARMv5TE libs should work on any arm based droid phone, BUT without hardware fpu support. Since all the (linux based) devices i programmed for had no hardware fpu either and weren't as near as powerfull as my desire is, i don't think using software floating point would be a problem for my needs and if it i do need it i can always use fixed point math.
Just thought i should write a small excerpt of that page here, since there might be other people looking for it eventually
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
- No native support for x86 apps on ARM, nor ARM apps on x86. Only .NET apps would work in both worlds.
But it is possible to create an emulator similar to DosBox that would run native x86 programs on WoA and, for example, I'm currently working in this direction.
- Though existing C++ apps can be recompiled for ARM from sources, it is not a 100% working solution. Current VS11 contains a rather limited set of ARM libraries - no DirectX libs earlier than 11, no import libraries for NtDll.Dll and similar DLLs.
I don't have access to any WoA builds, so I can't check whether these features are completely removed from ARM, or those LIBs are just not present in current VS11 build. But at least now we can compile test apps for ARM and analyze the code (though we don't have where to execute them yet).
- Native WoA programs use THUMB2 instruction set (ARMv7 and above). Though ARM instruction set would be supported too.
- According to "Microsoft Portable Executable and Common Object File Format Specification v8.2" WoA machine type in PE files would be 0x1c4, and some new relocations types are added (for example IMAGE_REL_BASED_ARM_MOV32T = 7). IDA understands such EXE files, though complains on relocs.
- SEH is implemented in a different way than on x86 (similar to x64, google for RtlAddFunctionTable to get the idea).
- WoA is more secure by default. For example TPM can be rarely found on x86, but it would be required on ARM.
- Most of existing drivers are source-code compatible with ARM (of cause if not using x86-specific stuff). But ARM would never allow to load unsigned drivers (unlike x86 Win7/8).
- As platform is completely new - all ARM drivers would be added to windows update site to simplify our life. Some obsolete hardware like 1394 is not implemented at all, so there would not be so many drivers for ARM llike for x86.
- All binaries would be the same for all SoC providers.
- No "native" ARM VisualStudio - developer tools are x86 only.
WoA requirements from different sources:
- 10.1” display with 1366x768 min resolution (though smaller screens may be supported with reduced functionality)
- Volume Control, Windows, Rotation, Lock power buttons
- Dual core CPU with hardware accelerated GPU
- at least 1 Gb RAM
- min 16 Gb fixed storage
- 100mW idle power in standby
- there are rumors that there would be standart "Phone call API" ("Apollo" UI)
Does anyone have access to ARM WDK? It would definitely contain a complete set of import libraries and would provide lots of info on WoA internals in headers/documentation. Seems that Windows 8 WDK on MSDN does not have ARM tools
so your bottom line says: no w8 on arm (ever)?
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
The UEFI requirement is expected, and I doubt will be that much of a hurdle. UEFI is all open, and it should be pretty trivial to chainload a UEFI-compatible environment on top of the existing firmwares, provided that nvidia doesn't provide us with an implementation to start with, which I suspect they'll do.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two. A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Everything I could find relating to the TPM says that it's optional, but will be automatically utilized if available.
The rest is pretty inconsequental, at least to what I think most people here are interested in.
nvidia started a windows 8 development program for ARM (Clickey here), but I haven't seen anything else from it, has anyone else gotten anything?
mamaich said:
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
Click to expand...
Click to collapse
Actually they said it would continue to support BIOS for older devices.
See: Current machines dual-booting Windows 7 and Linux should be able to upgrade to Windows 8 without wiping out the Linux install. As Microsoft notes in the Building Windows 8 blog, “We will continue to support the legacy BIOS interface.” However, machines using UEFI instead of BIOS “will have significantly richer capabilities” including faster boot times and greater security. (from Arstechnica)
That's for x86. ARM was said to require UEFI. Besides, there is no real bios on Android tablets, at least not a common platform.
netham45 said:
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
Click to expand...
Click to collapse
I've got it in one of the "windows-on-arm" non-public documents dated the first half of this year. While UEFI,ACPI,TPM are an option for x86, they are required for ARM hosts.
So no custom WM8 bootloaders, drivers, patched kernel on ARM hosts (like "windows activators" do) until sign keys would be leaked or some backdoors would be found. Of cause this is good as this would make rootkit creation more difficult, and require device drivers signed by MS (so we'd get more stable OS) but I really don't think that this "protection" would last more than 1-2 months after WoA would be released.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two.
Click to expand...
Click to collapse
I'm already working on such tool. It emulates x86 instruction set with dosbox or bochs CPU emulation library (I'm using both of them for debugging purposes, while working on my own one that would be much more simple->faster), translates x86 WinAPI to "native" host WinAPI + emulates API that is not present or differently implemented on WoA. It is designed to be truly cross-platform, so just a recompilation + creating several thunks/stubs would be necessary when I'll get my hands to an ARM host running windows8.
Of cause programs that use heavy anti-debugging, self-modifying code, undocumented features and SEH tricks would not work. Currently it is rather far from being finished (I have to implement&debug WinAPI and COM thunks that cannot be automatically generated) but old games like "heroes of might and magic" are already working fine in a test environment.
A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Click to expand...
Click to collapse
Of cause I'm talking about "ultimate" VS11, as express is designed to target mostly .NET (though ARM compiler is present there too).
And WDK that it published on MSDN does not allow creation of ARM drivers. I'm currently in a process of renewing my company's MSDN subscription, so I can't prove that myself, but I've read that on OSR forums.
I am waiting to hack my iPad and put win8 on it
I would hope touchpad would be the next viable option. Hp could still make more and just dump W8 on it. Thanks all of you for working this thread. I will be reading your progress as it unfolds. Good Luck devs and if I can find anything you will be the first to know.
Sent from my mwp6985 / Trophy using XDA Windows Phone 7 App
Some information on Win8 "Apollo" is available. Apollo - is a name for a new "windows phone" OS from MS.
- Apollo is based on the same "desktop" code as Windows 8. No Windows CE at last!
- Apollo would provide the same user experience as old Windows Phone 7.x - Metro UI, People hub, builtin office apps, etc. Seems that software compatibility with WinPhone 7.x apps would be preserved, but this is just my own guess.
- All applications on Apollo are required to be signed, similar to Windows Phone 7.
- Device drivers can be written only by IHVs, MS and OEMs, not by ISVs. This would be a problem for antivirus vendors or tools like daemon-tools.
- There would be a "built-in" eMMC card with OS and vendor partitions, and maximum one SD card. eMMC supports NTFS, SD-card supports only FAT/exFAT.
Build-in eMMC would have C:\ drive letter, SD-card would be D:\ if present.
eMMC contains several partitions. Some of them would be made readonly during boot.
- Near Field Communication is built in.
- The same list of sensors as in WP7 Mango is supported.
- There would be BSOD like in a desktop OS
- Unproven, but it seems that only .NET ("Splash UI framework" and "Silverlight") APIs would be available to independent developers. So no native code again.
- Seems that x86 architecture is supported for Apollo too.
Raspberry Pi 2 spec:
A 900MHz quad-core ARM Cortex-A7 BCM2836 CPU (up from a single-core 700Mhz part)
1GB LPDDR2 SDRAM (up from 512MB)
Complete compatibility with Raspberry Pi 1 (software will need to be recompiled to take advantage of the new multi-core processor)
Identical form factor to the existing Raspberry Pi, which means it can fit into existing enclosures
10/100 Ethernet port
40-pin extended GPIO
4 x USB 2.0 ports
4 pole Stereo output and Composite video port
Full size HDMI
CSI camera port for connecting the Raspberry Pi camera
DSI display port for connecting the Raspberry Pi touch screen display
Micro SD slot
Micro USB power source
Its not going to be a full Win 10 like on a PC, its Win 10 IoT.
Well yeah it can not be full version still there is a windows support, I'm still waiting for Android support
Wonder if they will have proper display drivers with Win 10... Those are the reason Android hasn't been 100% successful in being ported over
Nypan sr said:
Its not going to be a full Win 10 like on a PC, its Win 10 IoT.
Click to expand...
Click to collapse
But hopefully it will be more like more like the x86 Windows version without any dumb restrictions, as opposed to the Windows on ARM SKUs we've seen so far (Windows RT and phone) that have too many restrictions. I believe the current IoT version is prrety stripped down and runs win32 executables, but I guess it remains to be seen exactly what the Windows 10 IoT SKUs (x86 or ARM) will be like.
Either way this is good news, and especially as it's the first Windows on ARM release (that I'm aware of) that isn't pre-installed on a device, and can be installed and removed at will (again, unlike Windows RT/Phone device with a locked bootloader). So that at least is encouraging.
I know it is a silly question, apart from the company news, has anyone independently managed to get a developer copy to work? I scoured all over the web and have not been able to see any info with regards to that.
vulcanize said:
I know it is a silly question, apart from the company news, has anyone independently managed to get a developer copy to work? I scoured all over the web and have not been able to see any info with regards to that.
Click to expand...
Click to collapse
There is no copy anywhere. At least, I managed Windows RT to boot with hardware-accelerated Qemu(and a basic Tegra3 emulation) if I disable the graphics driver. Still no input but that should just be some boring code to write.
black_blob said:
There is no copy anywhere. At least, I managed Windows RT to boot with hardware-accelerated Qemu(and a basic Tegra3 emulation) if I disable the graphics driver. Still no input but that should just be some boring code to write.
Click to expand...
Click to collapse
That's sounds very interesting (maybe should have posted that on the Windows RT section)
as a couple of us would be interested in learning how you did that
xsoliman3 said:
That's sounds very interesting (maybe should have posted that on the Windows RT section)
as a couple of us would be interested in learning how you did that
Click to expand...
Click to collapse
I should clean the UEFI implementation and adapt the HalExtTegra3 to something cleaner without a hacked VersatilePB target. How to disassemble that lib?
A bluescreen is the result with the RTSM emulator. Does anyone have Windows RT BSP documentation or a disassembler?
Just noticed someone else who has done amazing things with Windows RT on generic ARM hardware
http://winocm.moe/projects/bringup/osports/2015/01/12/giving-windows-on-arm-a-hand/
I think Linux is much more important than windows support.