evening gents and lady
i have a query for chefs mainly but anyone with OS knowledge can help.
basically i work for a company that recycles computer equipment, we receive a lot of certain models mostly the dell optiplex gx range. and rebuilding them entails we have to install the OS from the oem discs and then preceed to either download drivers from dell, install from out in house servers or usb pen drives.
i had a thought that maybe the drivers could be installed as packages onto the disc a bit like windows mobile.
ideal situation
One master disc with the operating system on AND all the drivers for the range os systems we build. in this case xp w/ sp2 then after the normal os installation i want a program maybe to detect the model and install the drivers that are on the disc automatically. a bit like the app that installs opera and google maps on coked rom (UC?) also if that goes well i can then include all the apps that we install like ms security essentials. open office etc
is there anyway to do this
have you got a dell oem disc?
I have and it installed the driver auto
flyboy
we have a standard oem disc that does all of our models but thedriver needed differ from machine to machine for instance sometimes the ethernet adapter gets installed by default other times we have to install it after the main os insta;ll
There is a way to do it. Few questions:
1) What Windows O/S
2) Do you have an OEM product key
3) Are you familiar with slipstreaming
* EDIT *
Guess we posted at the same time. You need to slipstream the drivers into the O/S media. It's not usually best practice to included applications but can be done. Depending on the version of Windows, a final post config exists to trigger silent installs of extra applications. It's all part of a SYSPREP deployment process.
we use dell oem disc xp with sp 2, the keys do not have to be written in on the setup and no i dont have a clue what slipstreaming is
-PiLoT- said:
we use dell oem disc xp with sp 2, the keys do not have to be written in on the setup and no i dont have a clue what slipstreaming is
Click to expand...
Click to collapse
In slipstreaming you can place your drivers into the OS so on install everything is done. "including stripping system components integrating service packs"
XP nlite
I just have a library of about 9000 drivers on a CD that always lives in me bag. "and stored as ISO image on computer" These compilations can be found online.
The choice you choose will depend on if you have a quantity the same then you can use nlite as you know the install the same or just bung all drivers onto a disk
The process you're after is a sub-process of imaging.
Here's an abridged version, very abridged, but should give you a sense of what's involved ... having done this a few (aka many many) times.
Media
Generally, the media to use for this type of activity is obtained directly through Microsoft as using another OEM's media is generally problematic as it has been altered for their requirements. Since you're using the DELL OEM CD on DELL OEM systems, you can "get away" using it.
One of the steps you may want to do is slipstream WinXP SP3 to the media. Here's a good site to get you on your way, there are many more out there:
http://www.winsupersite.com/showcase/xpsp3_slipstream.asp
Product Key
The product key embedded in the OEM CD ensures that it is only useable on DELL branded equipment. This permits end-users to rebuild their system and skip the product activation phase - the caveat being that OEM media is used on the OEM system; you can't interchange OEM media/systems as this will trigger activation.
Enterprises usually obtain a Volume License Key (VLK) which allows them to use imaging methodologies to deploy the O/S to workstations.
Note
Before others chime in ... yes, there are "work arounds" but since we're sticking to legitimate usage - we'll avoid that topic.
Pre-Delivery Process
There are two approaches to this process.
The first, traditionally used by OEM's (ex: DELL, HP, etc.) is to inject their drivers into the O/S media and modify some of the setup information files so as to ensure that the drivers are detected during the TEXT & GUI setup portions of Windows.
The second, traditionally used by Enterprises (ex: 20+ workstations) is to build a base image which is: install windows, install drivers, run SYSPREP, capture (seal) image. Knowledgeable IT builders will usually inject the drivers they require and adjust the setup information files prior to running SYSPREP and "sealing" the image.
Note
Large OEM's will also use the second process so that they may build many similar systems at once for shipment purposes. In a nutshell, the customer gets the media but the actual system HDD has been imaged.
Additionally, some OEM's will ship their systems with a hidden partition that is accessible by pressing a combination of keys at boot. The hidden partition contains a copy of the system image which can be restored to the visible partition.
Post-Delivery Process
The are two approaches to this process.
The first, traditionally used by OEM's (ex: DELL, HP, etc.) is to provide the O/S media along with the system. At the factory, an image is copied to the system HDD (see note above) and the system is shipped to the customer. When the customer unpacks and starts the system, the mini-SYSPREP is initiated and the system goes through a mini-GUI setup procedure.
The second, traditionally used by Enterprises (ex: 20+ workstations) is to take the pre-delivery process "sealed" image and upload it to a distribution system such as SMS, Altiris, OnCCM, Symantec GHOST, etc. The BIOS of the workstations are usually configured so that the Network Adapter (NIC) is set for Pre-eXecution (PXE) boot. A Wake-On-LAN is sent to the MAC address of the workstation (which has been recorded during asset receipt/delivery), the workstation turns on, sends a PXE-Boot request, the DHCP server responds to the request and forwards the request to the distribution server, the workstation receives a boot image from the distribution server, which in turn initiates imaging of the workstation HDD. Once completed, the workstation reboots and goes through an automated mini-GUI setup which performs all of the necessary detection and driver installation.
Some Final Points
You can inject drivers to the physical media (ex: Windows XP) and perform individual installs of Windows on a system-by-system basis. This is often referred to as slipstreaming drivers or injecting drivers. This is often required for AHCI controllers on new systems.
Imaging can be "tricky" if you have to deal with multiple variations of hardware abstraction layers (HAL) such as in the case with single/multi processor architecture.
Ensure that customers receive a copy of the media with their systems so as to remain compliant and not violate license agreement terms.
Avoid using NLITE unless your company is planning on providing continuous ongoing support with each system sold. NLITE is an extremely fast method of preparing systems for mass image distribution. Unfortunately, it is not officially endorsed/supported by Microsoft and/or OEM's. Enterprises or individuals can usually "get away" with using NLITE as they typically self-support their systems.
Recommendation
In your situation, it may be easiest to read up on the following methodologies:
Slipstream service pack to cd-rom (media)
Slipstream (inject) drivers to cd-rom (media)
HTH,
wow thx H
very concise. i think even though were technically classed as an enterprise. i think id still prefer to use the oem solution. looks like im going to have to have a disc per model instead of one master disc but cant win em all.
using nlite wont do as we only provide 3 months official warranty on the product
so i think my best bet is to copy the contents of the cd to a computer. then insert my drivers onto it the make a iso out of it then make a bootable cd. the customer wont get a copy of the edited cd. think they might have something to say having the recovery disc on a tdk cd/r
using the oem disc you have got. research on the internet and find out where the drivers are kept on the disc, then copy the disc to your pc and insert the drivers then burn to disc. this way the drivers would be on the disc.
read this as well. i think its a noob sort of guide to slipstreaming:
(cached google page)
http://209.85.229.132/search?q=cachedCEft9ToWQJ:tech.yahoo.com/blog/null/99108+where+are+drivers+on+xp+disc&cd=7&hl=en&ct=clnk&gl=uk
flyboy
( sorry just reaslised i have posted what you said, pilot)
Related
PLEASE READ POST #2 FOR UPDATES. POST #1 IS STRICTLY INSTRUCTIONS ONLY. UPDATES ARE IN POST 2. THANKS!
Okay! Time to breathe some new life into the Shift. That's right folks. OS X now runs flawlessly on the HTC Shift and graphics are running without a hitch thanks to modified GMA 950 kexts. It's nice to play around with other devices. TBH the HD2 is too plain for me atm and I'm waiting for a Desire HD build of Android for it. In the mean time, here is some darwin goodness for the worlds favourite UMPC. First of all, to answer a few questions I encountered in the other threads, OS X will run perfectly fine on the Shift. Some people are blindly saying that the 950 has issues with OS X. Guys please do some research before posting misleading information. The 950's were the original on-boards for the MacBooks. It's impossible for it not to be supported. Better, with HW Acceleration! Okay so what works and what doesn't?
Working
- GMA 950 w HW Acc.
- Camera
-Trackpad
- Keyboard
- Speakers
- 3.5mm
- Internal drive
- Ethernet/USB Expansion Hub
- Battery/Charging recognition
- Display (although I tried forcing 1024x600 it will only create a scaled view and it's not useable)
- SD Card slot
Not Working
- WiFi
- Bluetooth
- Fingerprint Scanner (I'm not surprise, OS X doesn't have support for it anyway)
So almost everything works! Which is good news. I'm not sure if WiFi and bluetooth will work. Theoretically WiFi should work because the iPhone 2G and 3G use the exact same card that the Shift uses. However I need to find a way to extract the kexts from a firmware file which is proving to be difficult as Apple is now ridiculously locking down access to the images. Once I find this kext, WiFi should be a go. Bluetooth, I'm not sure about. I don't even know what stack it is so I can't look for a driver. Fingerprint scanner I'm not worried about as it proves useless most of the time anyway.
Okay so how do you get this working. Well I went through the trouble (and a majority of my download quota) to find which builds work best so you don't have to. Now don't come asking me for download links to these builds because I will NOT give them to you. Try google. Below is a rundown of the tested builds.
iAtkos 5i - Boots into verbose mode and kernel panics.
iPC - Does not boot at all. Installed netkas PCEFI - no change
XXX_10.5.6 - Boots into installer, won't run after installation
Leo4Allv3 - Boots into verbose mode and kernel panics.
Leopard 10.5.6 Pendrive - Boots perfectly to blue screen, loginwindows.app hangs
So the above builds were pretty helpless. The only ones that worked to some degree were iAtkos, XXX, and Pendrive, pendrive having the most success. Loginwindow.app was the only thing stopping boot. So I tried a number of things. First thing that comes to mind is replacing the app file. This didn't work and continued to crash. Then something else got my attention. the blue screen after the Apple logo turns black and then back to blue again. The only explanation to this would do this is that the graphics drivers were trying to load but failing. So this was a problem with the 950 kexts. The iAtkos disk came with excellent modified 950 drivers. Installing these onto the pendrive bulid solved this and it booted to the desktop. Below is the complete set of instructions to getting everything working including dual boot.
If you want dual boot working properly, I strongly recommend installing Windows first. That is, if you want to avoid a lot of hassle. Now as you may know, OS X is an HFS OS and Windows is an MBR. If you go about installing Windows on a drive with no other system on it, it is going to convert the entire partition table. This can be solved by creating two partitions under GPT. If OS X is on one partition, Windows will create a hybrid partition table. (MBR/GPT)
1) First you are going to need to find a copy of the leopard pendrive build and restore it to an external drive or usb. You are going to need access to a working hackintosh or Mac to be able to do this.
2) Once the restore is complete you need to go ahead and install the GMA950a.pkg and the GMA950b.pkg from inside the iAtkos disk. If you aren't able to find these I will attach these below.
3) Once these are installed, we are going to need a bootloader for the machine to see the drives. There is a great bootloader credits to netkas here.
http://www.mediafire.com/?zybzmmm5uyz
4) Plug in the external drive that you restored and installed these to and fire up your shift. Boot into the external drive bask in the glory of OS X. But we're not done yet.
5) Go and download IOATAFamily_ICH10 that's attached below and install it onto the boot drive. Reboot.
6) You need to head over to /Applications/Utilities/Disk Utility.app. Now we are going to partition the internal drive and it WILL ERASE THE WINDOWS INSTALLATION. It should come up on the top left as a grey hard disk. Now you need to select the one at the very top. i.e. the parent directory. You should now have a tab labeled "Partition." Click on that an you will get a box that has your hard drive name in it. Select "Volume Scheme" -> 2 Partitions and click on the first box. On the right, name this to whatever you like. I had Macintosh HD and select the size. Make sure the Format is set to Mac OS Extended (Journaled).
7) Now select the second partition and name it to something. I had Windows. Adjust the size and set it to MS-DOS (FAT). Now click options. and there will be three partition tables to choose from. Select GUID Partition Table (GPT). Click apply and this will erase the internal disk and replace it with two partitions.
8) Close disk utility and boot into your Windows disk. Install Windows onto THE WINDOWS PARTITION YOU CREATED. Not the Mac one.
9) After the install is complete, reboot into the external drive that you originally booted OS X off and open Disk Utility.
10) Now click on the Mac partition that you created in step 6 and click the restore tab. There will be two entry fields here, one called source, the other destination. Now depending on what the external drive is, it will either be an orange disk or a white disk. What you are going to do is drag the orange/white disk that you booted off into the source, and the Mac partition you created into destination. Tick the erase destination box and click restore. This will take roughly about 20 minutes.
11) When restore is complete, we have two more things left to do. We need to install the bootloader and set the partition as active. Now remember the bootloader we installed onto the external drive? All you need to do is install the same thing, but to the internal this time.
12) Almost there! Just need to mark the partition as active. I will post a screenshot incase this step is confusing. You need to go to /Applications/Utilities/Terminal.app. If you are familiar with Linux, this is a piece of cake. Just type the commands below.
diskutil list
Now there should be all the attached drives listed. Take not of your internal drives now. You should see on the left, /dev/diskX (where X is a positive integer) and under that will be a hash followed by a series of sequential numbers. select the appropriate number for your internal Mac partition. Mine was disk0s2. In most circumstances, it should be disk0 that you are after as it is the main drive. Next type the command below.
sudo frisk -e /dev/rdisk0 (or whatever the 0 is meant to be in your circumstance)
Ignore the error "fdisk: could not open MBR file ..."
next type:
f X (where X is the number that was next to the partition. In my case 2, in disk0s'2'. "
then:
write (hit enter key)
y (hit enter)
exit (to quit)
I FORGOT TO ADD THIS STEP! Before rebooting, run the bootloader from http://www.mediafire.com/?zybzmmm5uyz on the newly imaged internal drive. If you do not do this, the machine will boot up to a flashing underscore. You need to do this as the boot files are not copied from the first time you do it.
Now restart the machine, pull out the external drive and boot into the internal drive. There should now be a countdown timer. Press any key to interrupt this and you will get a list of your partitions. Mac OS X and Windows. if you want to go into Windows, just select it and hit enter. Similarly for Mac.
Hope this wasn't too confusing. Running OS X on alien hardware is not an easy task and if you succeeded, consider it a great accomplishment! Any questions, just ask below. I am on school holiday at the moment so I'll have a lot more time to answer! I will post up developments on WiFi so stay tuned!
Update 21/09/10
- Bluetooth operational with generic bluetooth kext
- 1024x600 mode. I've posted again after the server overload
- Ethernet works on the external hub. Only just tried it.
- For those who are experiencing problems with apps such as iTunes not syncing with iPhones or the store, there is a fix. Open the SystemVersion.plist in /System/Library/Core Services/ and change the system version 10.5.6 to 10.5.8. This will not update the system to 10.5.8 but it will trick software update into thinking you have it so you can update the software without dramas. There isn't much difference between the two except for a few bug fixes and core frameworks. Just remember not to do the security updates or the combo update.
Great work!
Seems like a great guide. I'll surely try this as soon as I get my hands on a crapple device.
Thanks
thaihugo said:
Seems like a great guide. I'll surely try this as soon as I get my hands on a crapple device.
Thanks
Click to expand...
Click to collapse
Haha! yeah i got tired of waiting around for a os x tablet. the shift is a beast.
I'm curious, why didn't you try Snow Leopard? Also, with something as non-generic as the Shift, I would have used Chameleon and went with a vanilla install so I can load each individual kext
EGOvoruhk said:
I'm curious, why didn't you try Snow Leopard? Also, with something as non-generic as the Shift, I would have used Chameleon and went with a vanilla install so I can load each individual kext
Click to expand...
Click to collapse
Good questions and thankfully I have answers for you. First of all note that 10.6 is a very lean version of 10.5. The install goes down from roughly 8GB to 5.5GB. How did they do this? They removed a truckload of obsolete drivers, most of which are needed to run the shift's older hardware. Snow Leopard also requires SSE3 to boot, which the A110 doesn't support. Also, the only practical and surefire way to patch 10.6 is using NBI (netbook installer). Don't get me wrong I did try but if NBI doesn't make SL bootable, nothing will. Anyway, Snow Leopard has a 1GHz cap which is quite hard to bypass without causing stability problems. Even running Leopard on my 667 Powerbook lagged like a b**ch (excuse the language). As for chameleon. The bootloader is a pcefi/chameleon hybrid. The reason for this is that GUI chameleon caused incredible graphics issues. The drive images on boot would be multi-colored and stretched. So GUI was a no go. Vanilla worked but it didn't WORK. The whole point of vanilla is for system updates and stability increases. Unmodified kexts did nothing of the sort for the shift. For example unmodified 950 drivers caused severe disproportionality and VGA out didn't work. In fact, the modified system kexts increased stability and boot time on an ssd is roughly 25 seconds to desktop.
Did you get touch screen working ?
I have also installed 10.5.8 version I used version fromn ASUS eee 701
as you sad there is no bluetooth wifi touchscreen working...
About wifi 8686 iPhone use ARM version the driver must be rewriten to be used on our devices...
-=xXx=- said:
Did you get touch screen working ?
I have also installed 10.5.8 version I used version fromn ASUS eee 701
as you sad there is no bluetooth wifi touchscreen working...
About wifi 8686 iPhone use ARM version the driver must be rewriten to be used on our devices...
Click to expand...
Click to collapse
Bluetooth DOES work. Touchscreen as you said doesn't work. ARM/Intel won't matter as the kexts for peripherals are OS level not architecture level. Hence the reason a PPC kext will work on an Intel based Mac.
Do you know what kind of touch screen is used in shift ?
There are some drivers from usb touck screen maybe we can use them but I didn't find any information about shift touch screen need to see linux drivers...
-=xXx=- said:
Do you know what kind of touch screen is used in shift ?
There are some drivers from usb touck screen maybe we can use them but I didn't find any information about shift touch screen need to see linux drivers...
Click to expand...
Click to collapse
I'm begging to have the same question answered. I've exhausted all resistive touch drivers for OS X and none of them are working. I'm beginning to think its a prop. touch display instead. Anyway, Linux drivers wouldn't work. Darwin has almost nothing in common. The closest thing is bsd as far as OS X applications are concerned, but again, this is just a bsd flavouring and no drivers designed for bsd will work. Sure they can be ported, but it's a much quicker route if it was to be rewritten from scratch.
Do you know what interface is used for touck screen comunication ?
Maybe it can be used for tracing output data and accomodation existing driver to our needs...
And about wifi did you get any progress ?
-=xXx=- said:
Do you know what interface is used for touck screen comunication ?
Maybe it can be used for tracing output data and accomodation existing driver to our needs...
And about wifi did you get any progress ?
Click to expand...
Click to collapse
Touch is definitely USB based (device manager->usb hid device). WiFi is looking slim at the moment. I've gone through a few iPhone firmware files to find a suitable kext with no luck. So it is looking to be a complete rewrite of the driver which will be quite difficult as there is no support for Marvell as far as WiFi goes. Apple only ethernet by Marvell/Yukon, thus ruling out the possibility of common driver properties between other kexts.
Just in reply to a post before the server crashed. None of the touchscreen drivers worked and the panel didn't get recognised. Also the download for the resolution enabler is back up in post 2 again. And it looks like we made it on engadget. AGAIN.
Featured article on egadget congrats.
Sent from my htc hd2 using XDA App
roflcoptrbbq said:
Featured article on egadget congrats.
Sent from my htc hd2 using XDA App
Click to expand...
Click to collapse
Hahaha thanks. Its actually on a lot more now. Its almost a virus! hahaha
could you get the drivers from 10.5 and shove them into 10.6, also see if you can use the axitotron modbook drivers
http://www.axiotron.com/index.php?id=home
i will try all of this next week, as i was about to sell my shift....
it's on marketplace here.
ayilm1 you are awesome.
shad0wfire said:
could you get the drivers from 10.5 and shove them into 10.6, also see if you can use the axitotron modbook drivers
http://www.axiotron.com/index.php?id=home
Click to expand...
Click to collapse
Yeah mate. that did cross my mind until i realised axiotron hasn't done anything to do with Synergy touch yet, meaning no finger touch at all. It's all wacom based. Synergy will incorporate resistive with this, or maybe even capacitive, but no guarantees on it working with the shift. I have started to build a kext for it but it's really difficult when you don't even know the manufacturer of the panel you are writing the driver for! Thanks Seb, just trying to help out the xda community!
Wifi
If it uses the same wifi card as the iPhone 3G, the firmware is decryptable. Head onto the idroidproject.org forums. I spent time on there putting android onto my 3G and the wifi binary files were needed as they were copyrighted material.
If you like get back to me and I can get the binaries for you? If not it's pretty simple just requires some simple linux command line skills, which I'm
Sure you have since you undertook this project.
Anyway good luck, hope this helps with getting wifi to work!!
I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
"Stealing contacts" is not that hard to do, since your app can read the contacts (you don't need any hacking to do that).
But reading + sending them to your server will make the marketplace instantly reject the app. So i doubt there's a problem.
I also don't see how you can infect a windows phone, given that .Net and Secure Boot make it almost invulnerable to everything.
rob243 said:
I was just reading an article concerning malware on Windows Phone 8
Google News Search "Windows Phone 8 Malware"
From the article
"A 16-year-old security researcher from India plans to present a malware application for Windows Phone 8 at the upcoming MalCon security conference in New Delhi, India, on Nov. 24.
According to a brief description of the presentation on the MalCon website, it will show approaches and techniques for infecting Windows Phone 8 devices and will demonstrate how the prototype malware can steal contacts, upload pictures, access text messages and more."
Will this affect WP8 sales...it certainly doesn;t look good for this to happen so close to the launch...will we need to install AV software on our phones now too?
Click to expand...
Click to collapse
Unless you unlock the device and install that software by yourself, i don't believe it ever gonna pass marketplace check before it get online.
Well I am interested to see how its done, apparently the guy will present the proof of concept on the 24th
There are ways to get past checks run in the Marketplace ingestion. This has been previously demonstrated with PoC malware on iOS, which has similar protections. Don't assume it's impossible, especially if native code use is permitted.
Please note that there is a difference between native and unmanaged code, don't mix them up.
Native code has always run on Windows Phone. Both C++ and C# produce native code. The first is un-managed, whereas the second is managed.
Visual C++, the one we use in Windows Phone is, just like C#, a managed native language. It achieves almost the same performance as the standard C++,due to the more optimized compiler. It is possible to run standard C++ on Windows Phone, but it is very difficult to do so because the marketplace knows which compiler you used to make your app (if visual studio is not there, no no). The marketplace also knows which API you use (no Windows Phone API for C++, again a big NO for the submission).
Now, the difference between native and non-native code...
Native code always ends up as 1 and 0. The very code you write in C# will, at some point, end up as 1s and 0s. Same goes for C++(managed or not). The difference between C# and C++ is that the compiler inserts some failsafes into the code (lots of ifs) to check for exceptions. This does not happen in C++.
So the path for C# is like this:
C# code -> MSIL->Native code which is run on your devices (compilation is either done at install time, or in the clouds).
the C++ code we use in Windows Phone has basically the same path! However, the more mature compiler and the "no-failsafe policy unless instructed to" that all C++ variations enforce make the code faster while less safer.
A non-native language will never, ever get the code a developer writes compiled to 1s and 0s.
Such an example are web programming languages, and Java.
For Java, the process is like this
Java code -> various stages of compilation>byte code -> JVM interprets bytecode and then sends 1s and 0s to the CPU to execute-> CPU sends 1s and 0s results back to JVM which displays the results.
As such, Java is somewhat safer than C#, but also a lot slower.
The advantage of using an interpreted language is that you know the hardware capabilities of the device beforehand, and optimizations can be made on the spot.
Microsoft, however, took the middle road with C#. They gave it all the advantages of an intepreted language (due to the MSIL step, the .Net always knows how hardware it runs on, so the MSIL will always target all the hardware capabilities for your CPU, GPU and RAM), while also running on native code, which makes it very fast. They also decided to push in the same failsafe checks Java inserts in its code. This resulted in a slightly slower code when compared to C++.
As a developer, I think the reason for dropping XNA development by Microsoft wasn't its speed. C# could easily run games, and the thousand XNA games we have on the marketplace bear testimony to that. They brought C++ on board because porting apps from one platform to another would be easier this way, especially for apps coming from android or iOS).
Anyway, having said that, the C++ we use on phones does not have the capabilities to access the hardware or the system the same way it has on desktop. It doesn't have more power than C# already did. It is just used there for other reasons. I don't think it will pose any threat to security. Desktop evolved in a different way. Microsoft learned the lesson of system protection a long time ago. They won't repeat the same mistakes now. It wouldn't surprise me if they actually had some sort of AV software built in, just to be sure.
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
GoodDayToDie said:
There are so many factual errors in the above post I don't even know where to begin...
"Native" in this sense refers to apps written in a language which gets built ("compiled" although that technically involves compiling, assembling, and linking) directly into machine code ("0s and 1s" is a silly way to describe it, since *everything* on a computer, from programs to plain text files to MSIL or Java bytecode are all binary). Machine code means a binary sequence that the processor can directly execute. This is also referred to as native code, i.e. code which executes on the processor without needing an intermediary layer.
Although technically "native" and "unmanaged" mean different things, the difference is not what you think it is, and it's not very relevant to this discussion. It's entirely possible to have a native managed language ("D" was supposed to be such a thing; I'm not sure to what degree managed C++ qualifies) and to have intermediate-compiled unmanaged languages (you could, for example, distribute unmanaged programs compiled to LLVM bytecode; some systems might actually be doing so). However, MS themselves typically use "native" to mean "not managed", as evidenced by things like debugger modes.
These days, almost everything gets JIT (Just In Time) compiled to machine code even if the build tool didn't produce native machine code itself. This applies to .NET code (gets built as MSIL), Java (gets built to Java bytecode or Dalvik bytecode if on Android), JavaScript (doesn't go through a build process at all, but modern browsers JIT compile it to native before execution nonetheless), and many other languages. Interpreting is slow and requires a lot of memory overhead as well (you have to run the interpreter in parallel with the program actually being executed).
Although it is possible to invoke managed code from native code (only a little messy) and vice-versa (very common, see P/Invoke or COM interop for .NET, or JNI for Java), this should not be confused with them being the same thing. Yes, by the time they reach the CPU instruction decoder they're the same, but the process of loading the program, and the "runtime" environment that it interacts with, are very different indeed. Managed code uses a memory manager (hence the name), which takes care of things like defragmenting and freeing memory (via the garbage collector). This fundamentally violates a number of assumptions common to unmanaged code, such as that the address of data in memory will never change on its own, and that once allocated, a block of memory on the heap remains reserved until manually freed.
Another important difference is that managed languages must use abstractions of function pointers (for example, .NET delegates). In native languages it is possible (though generally unwise) to specify an absolute address (0x040C7F06 or some such) as a function pointer, and call that "function" (which results in the processor attempting to execute instructions starting from that memory address). In practice, this kind of thing is almost never done in PC software; it's bug-prone, completely un-portable, incompatible with security features like ASLR, very difficult to debug (this is the kind of thing that malware might use to make reverse engineering it harder), and there's typically no reason at all to do so.
However, the fact that it's *possible* is a Big Freaking Deal for somebody looking to work around a runtime security check. Consider this: Sliverlight on WP7 doesn't allow arbitrary LoadLibrary (or Assembly.Load, or similar) calls. The APIs available to your app are the ones included in its DLLs, and the ones in the Silverlight for WP7 runtime libraries. Even though the desired functions exist on the OS, and are even linked into program memory, you can't call them because there's no way to get a delegate for them. Now, compare this to native code, where you can literally just scan the code section of your app's memory until you find the entry point for the function you want, then treat that address as a function pointer and jump right into it.
Now, to be fair, I haven't actually written any official WP8 C++ yet. However, I can tell you that the trick mentioned above works just fine in Windows Runtime C++ on both Win8 and Windows RT, which are also supposed to lack APIs like LoadLibrary, and I therefore suspect it will work fine on WP8. Some experimentation is due, in any case.
Click to expand...
Click to collapse
Well, I was just trying to get a "basic picture" of the thing, but thanks for going into much more details.
As I said, the C++ we use in Windows Phone, just like C# on Windows Phone, functions in a different way compared to Desktop or Tablet version(hell, with C# on desktop you can easily do the memory scan thing and find stuff in the OS, not only in your app, but that is generally not needed, since C# on desktop has a much boarder and less limited API) . Unlike the former two, you can't interact outside your application, because your application is sandboxed. Even if you did find the pointer to a system protected function, you wouldn't be able to do squat with it(the system protects itself). Which is why I said C++ can't do things C# already couldn't. In theory, yes you can do what you said, in fact, i expect it to be possible on rooted rooms, but for the average joe...well...it very unlikely to happen, unless he does something stupid.
As for the JIT story, well, yes, Java does use JIT. However, it does so because it doesn't know before hand on what hardware it will run. The same happens with C# and .Net on desktop, and this is due to hardware variations. Right now, for windows phone, the "JIT" occurs directly in the clouds, or at install time, as all Windows Phones (8) use snapdragon chips.
I didn't say there were no differences between the code C# and C++ create at run time. The abstraction layers inserted by the compiler fall under the "failsafes inserted in code that slow things down", which C++ doesn't have. Also the more mature compiler (C++has like 40 years of xp, C# barely made 10, and only 3 on Windows Phone), the "true native" (happy now?) code it generates (which is very close to assembler language) makes C++ faster than C#, but not fast enough nor safe enough to phase out C# entirely.
In fact, if we still have this board 10 years from now, we might C# eventually take down C++.
We should avoid getting into a technical talk in this thread. As you can see, there are non-developers coming by, and an answer such as yours will completely and utterly confuse them. What I attempted to provide was a very basic image they could understand, like JVM sending 1s and 0s to CPU is the same as JIT.
Let's wait and see what we will be presented with. Currently the only thing a WP8 Managed App can't do that was mentioned was reading the SMS-Storage. Everything else is part of the official APIs. It might be that similarily to several WP7 hacks OEM drivers are being used to gain access.
The only thing that would really worry me was if he was able to provide a way to install his Malware bypassing the Marketplace. It might be interesting though for the Jailbreak community, given that any jailbreak bascially means exploiting a security vulnerability to elevate the rights of the current process to allow for those unlocks.
Hey Guys,
Below is a list of the things that my HTC 8x does when it checks for Windows Updates. I am waiting for Microsoft's server to decide to give me a new firmware, so I decided to sniff out the TCP stream. Of note, I found the following:
1. Phone contacts http://fe1.update.microsoft.com/WP8/MicrosoftUpdate/Selfupdate/5_UssDetection.dll
The Phone goes out and fetches this dll onto the system. It references the following certificates (which you can download):
root cert http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
production cert http://www.microsoft.com/pkiops/certs/Microsoft Windows Phone Production PCA 2012.crt
time stamp PCA? http://www.microsoft.com/pki/certs/MicTimStaPCA_2010-07-01.crt
2. After that, it goes and fetches the following cab file: http://sds.download.windowsupdate.com/wp8/MicrosoftUpdate/Redir/duredir.cab. This cab file contains a single xml file called wuredir.xml. It has two values: the clientServerURL and the ReportingServer URL.
3. After this, some https traffic occurs to the clientserver URL. I am guessing this is it checking for updates.
4. Then it posts to http://statsfe1.update.microsoft.com/ReportingWebService/ReportingWebService.asmx with a SOAP action of http://www.microsoft.com/SoftwareDistribution/ReportEventBatch with a whole bunch of info on the phone.
The User Agent being used for all of these communications is as follows: Windows-Mobile-Device-Update-Agent
If this dll it is fetching is unsigned, I wonder if we could have some fun....I am also wondering what happens if we develop and sign an xap with Microsoft's certificate if it will allow us to do more things within the OS.
Sign with Microsoft's private key? If you have access this then your about to become very popular
Sent from my Arc using xda app-developers app
Hmm, the 5_UssDetection seems to be a normal PE32 .dll. Not .NET compiled. I don't see any COM Imports/Exports for it so finding this out may be a little difficult. I haven't used any tools like IDA though, just a normal PE explorer program.
This is good information though. I wonder if GoodDayToDie may have some further input?
Nice find. I've been monitoring phone traffic myself but hadn't caught this exchange yet.
The fact that it checks external cert files is very interesting. Typically, I would expect this to be using "certificate pinning" where the public key of the signing cert is stored internally in the software, and no other signature is trusted (even if it chains to a CA that is installed on the phone and would normally be trusted). MS does use pinning in a number of places; for example, this is how the original ChevronWP7 Unlocker was broken, and is used when adding a Microsoft account to the phone or when that account is updating. However, I figure there's an excellent chance that pinning is *not* being used in at least one place where it really should be (this can be tested using tools like Fiddler or Burp, which have the ability to intercept SSL traffic using a cert that chains to a cert installed in the phone's trusted authorities store).
If pinning isn't being used, it may be possible to modify/create our own detection DLL, then create our own CA cert, install the public key on the phone, use the private key to sign an intermediate cert (that we also create, and have the private key for), and use the intermediate cert to sign our customized DLL. If necessary, we could even intercept the lookups that the phone performs and control what is returned (assuming the lookups are actually over HTTP, or at least unpinned HTTPS).
The probability that the file is unsigned isn't even worth considering; it's quite likely that Microsoft is using a mandatory signing level on WP8 for all executable code. Unfortunately, if they are doing that, it's also likely that it's set to require a cert which chains to the MS root cert (this is how Windows RT is by default), which is effectively a form of system-wide cert pinning. However, if you want to check, signtool in the Visual Studio Command Prompt can dump authenticode certs on a file.
Reverse engineering the detection DLL is quite possibly worthwhile even if we can't modify it, too; it'll provide insight into the update process, which is one of the best places to mess with a system. It runs with high privileges and explicitly is capable of modifying system code.
That sounds quite enticing! I wish I knew x86/ARM assembly :/. I'll see what the sign tool outputs in VS
It feels great to see that you're here GoodDayToDie You helped out a lot on WinPho 7 for HD2 (a device I'll soon repurchase).
Hopefully there'll be some advancements on the "jailbreaking" of Windows Phone 8
I would be surprised if WP8 wasn't using the same code signing requirements as Windows RT.
As far as hijacking that dll goes, unless we can find an immediate privileged code execution exploit in it all it's most likely to do would be to give us write abilities to the FS, and there's a huge 'if' attached to that. That would be a big step if possible, though.
Something that would be interesting to check is if an EXE compiled for Windows RT (cdb, for example) would be capable of running on WP8. If MS used the same signing certificates it may be possible to put enough of Windows RT's dependencies on WP8 to allow it to run a simple console application. Obviously we wouldn't have any console windows or the sort, but it should be possible to capture output if it worked.
We have a decrypted OS dump around somewhere, right? It should be simple to check if they use the same signatures.
Good call on checking the signatures. I'd also like to take a look at reverse engineering the OEM apps again; even if they don't give us a device-agnostic hack directly, they may reveal interesting things about the WP8 app model internals and also may give device-specific breaks which can be used to gain the knowledge we need for crafting device-agnostic ones.
Slightly off-topic:
The zipview exploit still (sort of) works. Hard to believe, but I bet MS just recompiled the program for NT's Win32 and didn't bother with it beyond that. Decent chance that the same holds for the XAP installer, though I haven't tried yet. However, A) the filesystem layout has changed, so write-only access is even more poking blind than it used to be, and B) zipview may be running with lower privileges than it used to. On a simple test ZIP (attached for your testing pleasure), I can open files and create directories up to three levels above the zip root, but no further. Trying to open a file in a folder directly higher than that gives a "cannot extract to a read-only location" error, and trying to open a file inside a subfolder above the third level up gives a generic error message (probably due to failing to create the folder).
Also, I got wired tethering working on my Ativ S today. I'll create a post about doing that if nobody else has done so yet (it was almost identical to the WP7 Samsung devices, the only hard part being finding the right 64-bit drivers). WindowBreak didn't work, though (the folder that it extracts at is above the permissions cutoff, which makes me suspect zipview can't write to the drive root) and I don't think the subcomponent of the Diagnostics app works the same, either (a lot of the diagnostics codes have changed; we should learn the new ones).I don't even know if WP8 understands provxml (it's historically a CE feature, not an NT one), although I found references in the Diag app to provxml being "ready".
Here's what I came up with for a file list from some rudimentary (and possibly inaccurate) parsing of a .ffu: http://pastebin.com/hX6qJQeA
Got that from RM820_1232.2109.1242.1001_RETAIL_nam_usa_100_01_95122.ffu.
Great, thanks for that! Looks like provxml is definitely still here, and that's probably good. I'll bet they changed some things though, to make it more NT-ish (support for proper ACLs, for example). I should review those included provxml files for a look at how the phone is currently configured. Lots of potentially interesting .REG files too. I'll have to try some more things here!
No problem. All I did was pull out all text inside '<DevicePath>' tags inside one of the FFUs for the AT&T Lumia 920.
From looking at the FFU it appears to be a collection of CAB archives (or packages) encapsulated in some proprietary format. WP7.x tools don't work on them, sadly.
Edit: I'm blind sometimes, there is a tool to mount them and it does work.
More edit: Different signatures.
More more edit: Windows RT refuses to run the WP8 binaries without a jailbreak.
Hmm... but with jailbreak, do the binaries run? I mean, they're NT Win32-based PE binaries compiled for THUMB2 architecture, so I'm sure they can at least be executed, but do they actually run or do this simply error out or crash immediately?
It would be interesting to compare the certificate chains of RT and WP8 binaries. As far as I know, the default restriction level on RT should allow anything that chains to the Microsoft root Authenticode cert to run, which means either that we misunderstand that restriction or that the WP8 signatures chain to a completely different cert. I'm guessing it's the latter, but that does surprise me. I could understand if RT used the "Windows" signing level and WP8 binaries wouldn't work; despite having Windows in the name, using the Win32 API, and running on the NT kernel, the Windows Phone team is separate from the Windows team and quite likely has its own signing keys. I would think that an OS which accepts Office and DevDiv/Tools signatures (unless Office and the debuggers were re-signed by the Windows team? I haven't checked) would accept Windows Phone signatures too.
GoodDayToDie said:
Hmm... but with jailbreak, do the binaries run? I mean, they're NT Win32-based PE binaries compiled for THUMB2 architecture, so I'm sure they can at least be executed, but do they actually run or do this simply error out or crash immediately?
It would be interesting to compare the certificate chains of RT and WP8 binaries. As far as I know, the default restriction level on RT should allow anything that chains to the Microsoft root Authenticode cert to run, which means either that we misunderstand that restriction or that the WP8 signatures chain to a completely different cert. I'm guessing it's the latter, but that does surprise me. I could understand if RT used the "Windows" signing level and WP8 binaries wouldn't work; despite having Windows in the name, using the Win32 API, and running on the NT kernel, the Windows Phone team is separate from the Windows team and quite likely has its own signing keys. I would think that an OS which accepts Office and DevDiv/Tools signatures (unless Office and the debuggers were re-signed by the Windows team? I haven't checked) would accept Windows Phone signatures too.
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
As far as running, some have given me console output, but I haven't gotten a single GUI one to start. I've been considering on looking to see how complex the UI is to see if I can write some sort of WP8->Win32 translation layer. There are just so few WP8 xaps floating around that it's not really worth looking into, though.
I don't expect the GUI to work; the whole model (with the Back history and all that) is going to rely on stuff not found on Windows Client. Cool that you're able to get some CLI apps to work (which is funny in and of itself; WP8 doesn't support a terminal interface). This is only post-jailbreak though? That still seems weird, since the signatures chain to the MS root CA. Very weird. I'll poke around myself once I download a ROM to explore (busy with work at present).
I haven't really found any to work, per se, I've just gotten console output, generally in the form of an error message or a help prompt. I can't recall which files exactly I had tried with, though. I mostly just poked through system32.
GoodDayToDie said:
I don't expect the GUI to work; the whole model (with the Back history and all that) is going to rely on stuff not found on Windows Client. Cool that you're able to get some CLI apps to work (which is funny in and of itself; WP8 doesn't support a terminal interface). This is only post-jailbreak though? That still seems weird, since the signatures chain to the MS root CA. Very weird. I'll poke around myself once I download a ROM to explore (busy with work at present).
Click to expand...
Click to collapse
the GUI classes of windows phone are not compatible with the standard .Net library or windows RT. The only way to get them running is through some sort of virtual machine. Some MSFT guys confirmed this a few months back at a training course about W8 RT.
Basically, it is kinda difficult to have WP8 apps show any GUI at all outside of their WP8 runtime.
netham45 said:
Here's what I came up with for a file list from some rudimentary (and possibly inaccurate) parsing of a .ffu: http://pastebin.com/hX6qJQeA
Got that from RM820_1232.2109.1242.1001_RETAIL_nam_usa_100_01_95122.ffu.
Click to expand...
Click to collapse
In regards to the file "MMOS.wim", has anyone managed to extract it/analyze it?
I couldn't find anything about it online. I am able to mount the file to a virtual disk and view its contents, but I am not able to view/read/extract any of these files from the drive. Trying to copy any file from the drive gives a system error/exception message that I have never seen before.
Are the files inside of "MMOS.wim" even useful?
---------- Post added at 12:13 PM ---------- Previous post was at 11:22 AM ----------
mcosmin222 said:
the GUI classes of windows phone are not compatible with the standard .Net library or windows RT. The only way to get them running is through some sort of virtual machine. Some MSFT guys confirmed this a few months back at a training course about W8 RT.
Basically, it is kinda difficult to have WP8 apps show any GUI at all outside of their WP8 runtime.
Click to expand...
Click to collapse
Not difficult, more like impossible lol.
The entire native UI is very independent. It is best described as one single app that has multiple pages. The start menu is a page, settings app is a page, office 365 is a page, etc.
These different pages all cross-reference resources from each other and can modify each other. However, they are all compiled separately. Each "page" contains it's own resources and GUI markup in a dll, along with native code to interact with the markup. This native code can also call functions and access resources from other "page" dll's. There are no compiler dependencies between the "pages" when being created, only during actual runtime.
Things are very "coupled" by this model on purpose. Changing code/functionality in the startmenu.dll could potentially break everything. It is designed so that you cannot target and modify a specific element or feature without updating code in other areas of the system.
Basically, you need full access and understanding of the gui layouts/code to modify it.
The only reasonable possibility is the ability to modify the markup code (think XAML) to change layouts and visuals. But even that possibility is made difficult since the markup is compiled. However, no information is lost during the compilation, meaning that the markup can be decompiled back to its original form.
Windows 8/RT uses DUI (DirectUI), a similar framework, for all of it's native GUI elements.
Windows Phone 7/8 uses UIX/Splash.
Asking a former Microsoft employee about UIX/Splash is like asking a former U.S. government agent about Area 51. They seriously fear for their lives.
I would avoid using the word impossible as of yet. With a layer of emulation above RT the thing should "run".
It might be possible to have an app compliant with the app store requirements (as in not require jailbreak) on RT to emulate the WP8 GUI model, but that would imply interpreting the XAML code and emulate it JVM style, but it would be a lot of work.
I wonder if the WP8 emulators would prove to be of any use...
mcosmin222 said:
I would avoid using the word impossible as of yet. With a layer of emulation above RT the thing should "run".
It might be possible to have an app compliant with the app store requirements (as in not require jailbreak) on RT to emulate the WP8 GUI model, but that would imply interpreting the XAML code and emulate it JVM style, but it would be a lot of work.
I wonder if the WP8 emulators would prove to be of any use...
Click to expand...
Click to collapse
My GUI post was in regards to the native GUI. I didn't realize that you were talking about WP8 apps running on Windows RT. I thought you meant the other way around lol.
Couldn't this potentially be pointless? Microsoft Job posting was looking for developers interested on deploying .appx on Windows Phone I believe. So that means they are going to make .appx the universal model for all platforms and not .xap in the future. With that said, they might be stopping .xap development completely in the future.
Who would develop an .xap for Windows Phone when you can develop .appx and have it work on Windows Phone + Windows RT + Windows 8 + Xbox?
Just some thoughts. I think trying to get .XAP running on Windows RT is pointless to pursue right now, since the time researching would be better spent in other areas of development.
Im not sure how they are going to make appx run on WP8. The WinRT model is obviously tuned towards bigger screens. How would you use a charms bar on WP8? In fact, how would you use any of the W8 stuff on WP8?
I think a lot of people would like to run emulated WP8 apps on their tablets, since some apps have not been ported yet.
While I do agree this is kinda pointless, it's a nice way of learning new stuff.
Is the windows phone 8 emulator an application for PC or it's not?
if it's an application can you give me a link to download it for windows 8 pro?
or if it's a virtual machine can you give me a link to download it for VMware or for VirtualBox?
Bit of A, bit of B. It's an application (XDE.exe) which displays, and mimics the hardware of, a WP8 device. The actual WP8 code runs in Hyper-V (this is why it requires Win8 and a modern CPU), executing an x86-compiled build of the WP8 operating system.
I don't know of any way to load virtual hard drive in another virtualization environment and have it be useful / visible to XDE (although you could try), but XDE.exe by itself won't be of any use to you either.
Of course, it's a free download from Microsoft as part of the WP8 SDK. It's kind of big, but that's largely due to the VHD files (it has several of them, for different phone configurations).
GoodDayToDie said:
Bit of A, bit of B. It's an application (XDE.exe) which displays, and mimics the hardware of, a WP8 device. The actual WP8 code runs in Hyper-V (this is why it requires Win8 and a modern CPU), executing an x86-compiled build of the WP8 operating system.
I don't know of any way to load virtual hard drive in another virtualization environment and have it be useful / visible to XDE (although you could try), but XDE.exe by itself won't be of any use to you either.
Of course, it's a free download from Microsoft as part of the WP8 SDK. It's kind of big, but that's largely due to the VHD files (it has several of them, for different phone configurations).
Click to expand...
Click to collapse
Thanks for help...
Can you give me a direct link to download it, because I cannot find a link to download it.
and can you give me a method to install it.
NH Kom said:
Thanks for help...
Can you give me a direct link to download it, because I cannot find a link to download it.
and can you give me a method to install it.
Click to expand...
Click to collapse
Install the windows phone 8 SDK (it really isnt hard to find).
But i am warning you, the WP8 emulator is really not useful at all...
It can not perform basic tasks like emulating an SD card or any hardware thing that is new to the WP8 system. Its sole use i found so far is to see how the UI looks on various resolutions, nothing more.
I am trying to figure out how I can light an LED with my NodeMCU V2 via the use of WiFi and a phone application I create via Android Studio but I don't know where to start nor can I find any information on how I can do it, I've seen tutorials where they make me use their 3rd party tools to achieve this and I've seen it done on a web server but I'd like it to be on a phone application. Is there any way this can be done? Bluetooth is not an option because I want it to be accessed from anywhere as I plan to port-forward the IP in the future.
This is a very interesting idea. I do not have a specific answer. I did some programming of 68HC11 about 20 years ago. The chip was mounted on a system board and connected to my desktop computer using a serial cable. I would develop the program on the desktop then download to the `11 over the serial cable. There was a small program in the `11 that would receive the program and load it into the `11 memory.
Structurally you need similar components: a software development system that run in your phone [a small Android Studio], an electronic communication link [Bluetooth, http, whatever], a system board, and software in the system board to receive commands and a data stream from the phone and load the stream of machine language into the 68HC11.
I still have the system board: CME11E9-EVBU AXM-0199 REV.C Axiom Manufacturing. For more info do a Google search for that ID, or just click here...
https://canada.newark.com/axiom/cme-11e9-evbu-ed/spi-sci-rs232-lcd-dev-board/dp/13C2791
I am not familiar with what is going on in that section of technology these days, but much of what you need should be available and findable. If such a system does not yet exist then it is a business opportunity waiting for someone like yourself.
All the best to you