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)
you can use java codes with the IE browser (also with Favorites)
maybe window break could get advanced
examples
javscript:history.forward
javascript:alert(document.cookie)
javascript:alert("xda")
IE10 mobile with windows phone 8 (tested on Lumia 920)
IE9 mobile with Windows Phone 7 doesn't work (tested on Mozart)
saywa said:
you can use java codes with the IE browser (also with Favorites)
maybe window break could get advanced
examples
javscript:history.forward
javascript:alert(document.cookie)
javascript:alert("xda")
IE10 mobile with windows phone 8 (tested on Lumia 920)
IE9 mobile with Windows Phone 7 doesn't work (tested on Mozart)
Click to expand...
Click to collapse
I'm not sure how this would ever help us, though. That's pretty much the same as just running javascript within the browser. And either way, the browser runs under low privileges anyway.
Good thought, though!
First of all, Java has nothing to do with JavaScript except for some idiot marketing scheme by Netscape long ago. Don't confuse them.
Second, if it were possible to use JS to jailbreak a phone, then it would also be possible for an attacker to take over your phone just because you visited a website. This would be bad.
Third, WP7/IE9 actually does support "scriptlets" or "bookmarklets" (javascript:<code> favorites); see my signature for a link to a few of them for WP7, including a "Find on page" tool.
Fourth, while Jaxbot is absolutely correct that the browser has low privileges (even if we could cause it to execute anything we want, we *probably* couldn't manage to unlock the phone), it is nonetheless probably a good idea to keep an eye out for any exploits released against IE10 on the desktop. Much of the code in the Windows Phone version is the same, and it might be possible to use a known exploit (at least, until it gets patched) to have another way to learn more about how the OS works, which might allow us to find a vulnerability that can be used for an unlock. It's not a sure thing, but it *might* help.
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.
Hi! I am constantly in need to use my laptop but I cannot carry it anywhere. So I thought what if it is possible to install and run Win 8/Win10 on my android phone (without of course removing or tampering too much with the stock OS, so that I can do some work on an external monitor?
1st of all lets see if the hardware can support this:
1) Does the Nokia 7 plus support HDMI through its USB port?
2) Does the Nokia 7 plus support HDMI over WiFi? If not can we use 3rd party app to send display through WiFi?
3) The Nokia 7 plus supports up to 256 GB of microSD storage capacity, so we have plenty of space to run Windows.
4)The CPU: What do you think, can this CPU run Win 8/10 and make simple tasks like text editing? PDF work? Spreadsheet work? Etc etc?
Thanx to all willing to answer these questions!
Lol
Why do you SPAM if you don;t have anything to say???
Some Ubuntu/Linux made an HYBRID OS that could turn your Smartphone into a DESKTOP PC by simply connecting an external monitor and mouse/keyboard
Then Nokia phones running Windows OS for phones had the same ability!
I have a vanilla clean Android device and I want to install/run Windows OS somehow parallel to it so I can take my phone out of my pocket and access my windows programs when in need (spreadsheets for examples and do work).
I know that there are some EMULATORS but I prefer something better than that.
Thank you!
contractubex said:
Why do you SPAM if you don;t have anything to say???
Some Ubuntu/Linux made an HYBRID OS that could turn your Smartphone into a DESKTOP PC by simply connecting an external monitor and mouse/keyboard
Then Nokia phones running Windows OS for phones had the same ability!
I have a vanilla clean Android device and I want to install/run Windows OS somehow parallel to it so I can take my phone out of my pocket and access my windows programs when in need (spreadsheets for examples and do work).
I know that there are some EMULATORS but I prefer something better than that.
Thank you!
Click to expand...
Click to collapse
It's impossible even unlock the bootloader (in a simple and free way) or install a custom rom...
Once again, lol. It's x86 architecture vs arm. Windows doesn't have full arm support. Also, thermally your phone will die trying to run windows. It's a really badly optimized os. I would have figured that lol would have been a precise enough answer to tell you that it's not possible.
Nobody ever attempted to do what you want to achieve.
Samsung Dex also runs in the Android System.
Linux can be compiled to run on Arm, Windows is still pending.
If you are in need for a small windows machine, buy GPD Pocket or migrate your workflow in Google docs and use the apps to edit your documents.
contractubex said:
Some Ubuntu/Linux made an HYBRID OS that could turn your Smartphone into a DESKTOP PC by simply connecting an external monitor and mouse/keyboard
Click to expand...
Click to collapse
But is "simple" difference, both Android and GNU/Linux use Linux as kernel, then if you run GNU/Linux on top of Android, then use same/running kernel.
contractubex said:
Then Nokia phones running Windows OS for phones had the same ability!
Click to expand...
Click to collapse
This is too something else, Windows 10 Mobile OS has/had similar NT kernel/libraries as Windows 10, anyway this not run x86 application and too not arm native applications, but ONLY modern/metro apps, and need adapting app for running on big screen...
contractubex said:
I have a vanilla clean Android device and I want to install/run Windows OS somehow parallel to it so I can take my phone out of my pocket and access my windows programs when in need (spreadsheets for examples and do work).
Click to expand...
Click to collapse
you want to run two DIFFERENT OS with DIFFERENT KERNEL and DIFFERENT LIBRARY and both native, without emulation, this is impossible, until some (Microsoft, or some reverse engineerings, or WINE developers or.. ) make (wtih BIG work and MANTIME) some kernel/library translation layer...
Guys, why do you reject stuff that I have seen working years ago?
youtube.com/watch?v=wzc0uMXGFBY
ok I found the video, check for yourself! ^^^
OK thanx for the info, I wil lwait some time until someone releases this for later version of Android....
and btw they ran this OS in 2012..now its 2019....
contractubex said:
youtube.com/watch?v=wzc0uMXGFBY
ok I found the video, check for yourself! ^^^
OK thanx for the info, I wil lwait some time until someone releases this for later version of Android....
and btw they ran this OS in 2012..now its 2019....
Click to expand...
Click to collapse
on video is NOT Android, but UbuntuPhone, this is GNU/Linux OS with multiUI=for_small&for_big screen, and with some "libraries" same as on reguler GNU/Linux desktop, then is possible run native GNU/Linux (for ARM) applications...
again, Windows is different OS, with different kernel and different libraries, then is imposible run it without emulation on top of any Android (=with Linux kernel)...
if you need full desktop on external monitor connected to phone with Android, with "full" speed without emulation, then only way is run Linux distro in chroot...
windows is closed software, runs on x86/64 cpu architecture, even if someone really wanted to do this, it's not possible.
ubuntu unity worked because a) open source and b) based on linux, just like android.
no, nokia 7 plus doesnt support hdmi at all. yes, you clearly have no idea what you are talking about.
Is it possible this is a wind up / trolling.