Last weekend, I wrote about my experiences trying to install Windows 10 S on a desktop PC. That effort failed, but it’s been bugging me ever since. And in mulling it over this week, I came up with two possible ways to solve the problem.
Curiously, both work.
So let me explain. In my original attempt to install Windows 10 S on my Intel NUC, I encountered several hardware devices that were not provided with drivers. And because many driver packages are delivered as EXEs—desktop applications—that means they cannot be installed in Windows 10 S.
But you can get around this, for the most part.
First, not all drivers are delivered as EXEs. When I visit the driver downloads page for my NUC, I can find some drivers packages that are folders of files plus an EXE, and I can find some that are just the EXE.
The driver folders can be used in Windows 10 S just like in any other version of Windows: Open Device Manager, right-click a driver-less device, choose “Update driver,” browse to the driver folder location, and then have the wizard find the right files.
This worked for me with some of the devices that were missing drivers.
But some key drivers were still not installing, among them the SM Bus Controller, which is the Driver Manager name for the Intel Chipset Utility. And that driver is delivered as an EXE, so you can’t install it in Windows 10 S.
That particular installer, however, can be extracted from the command line. And when you do that, you get—wait for it—a folder full of files that includes the drivers that will work in Windows 10 S.
Using these methods, I was able to get almost all of the drivers installed correctly in Windows 10 S. The only holdout was “Unknown device.” But looking at the Hardware ID in its properties, I discovered (via Google) that that device is the Bluetooth controller. Whose installer is a single EXE that can’t (to my ability) be extracted. But no matter: Bluetooth is not critical to what I want to do.
So that’s one way of solving my problem. One very ponderous way.
But I had a theory about a better way. And prompted by a Twitter user who had done what I had wondered about, I tried it myself.
Which is this: Clean install Windows 10 Pro on the PC in question. And then run the Windows 10 S installer I wrote about back in early August. That installer basically converts Windows 10 Pro to Windows 10 S. But I’d never actually run it. And I was curious if it worked the way I thought it did, since it wasn’t delivered as a normal ISO.
That is, after clean installing Windows 10 Pro, getting it up-to-date in Windows Update, and then converting it to Windows 10 S, the NUC was exactly where I wanted it: Fully working, with all drivers present and accounted for. That’s the kind of success I am always looking for.
Now. Let’s see if I can actually live with this thing, at least part of the time. Again.
<blockquote><a href="#171404"><em>In reply to PeteB:</em></a></blockquote><p>He's just trying to install it for evaluation purposes so he can report on it. He's not recommending average users to go through the process. BTW, "spaghetti code" has a specific meaning and one can't claim it applies to code one has never even read.</p>
<blockquote><a href="#171457"><em>In reply to MikeGalos:</em></a></blockquote><p>I don't think it was his intent to "understand" the OS, but rather to evaluate its usefulness. Obviously its basic functions have to work before that evaluation can take place. Yes, it would be better to run in on official HW but getting it to run "unofficially" can still provide insight into its utility IMO.</p>
<blockquote><a href="#171681"><em>In reply to MikeGalos:</em></a></blockquote><p>I don't see it in such black and white terms. If for example one were reviewing the first version of MS Office that used the "ribbon" and found it was more efficient than the menus Office used to use, the fact that you were missing a printer driver and couldn't print wouldn't make the observations on the UI invalid. Obviously if you tried to print and couldn't that wouldn't be a valid criticism under the circumstances.</p><p><br></p><p>But it is true that the best approach, as you say, is to get the right configuration. </p>
<blockquote><a href="#171459"><em>In reply to pecosbob04:</em></a></blockquote><p>You made two good points: 1) You explained spaghetti code's specific meaning and 2) you illustrated why there is, in general, no such thing as software "best practices". Context always matters.</p>
<blockquote><a href="#171660"><em>In reply to hrlngrv:</em></a></blockquote><p>If at the time of delivery the software operates correctly and it's sufficiently fast, the order in which those goals were achieved isn't relevant unless the choice negatively impacted the schedule. I would tend to approach it like you suggest, but that doesn't mean other developers can't work efficiently the other way round.</p>
<blockquote><a href="#171671"><em>In reply to hrlngrv:</em></a></blockquote><p>Perhaps I misunderstood your point. You said "get it correct before …". The opposite approach isn't "make it fast instead of correct". The intention to achieve full "Correctness" is axiomatic (<span style="background-color: rgb(255, 255, 255);">although rarely achieved in non-trivial software) </span> If you want to claim that a universal best practice is "produce code that fully implements requirements and has no bugs" I could see that although it doesn't really offer any specific strategy to achieve the goal so doesn't really have any practical value.</p>
<blockquote><a href="#171667"><em>In reply to navarac:</em></a></blockquote><p>I wish I had learned COBOL back in the day. I think it has more economic value today for a developer than the assembly languages I was using in my early years of software development.</p>
<blockquote><a href="#171670"><em>In reply to hrlngrv:</em></a></blockquote><p>100% and they knew the would make another $49 after the free upgrade offer ran out at the end of this year.</p>
<blockquote><a href="#171720"><em>In reply to Angusmatheson:</em></a></blockquote><p>I guess you can't post links here any more?</p><p><br></p><p><span style="background-color: rgb(249, 249, 249); color: rgb(62, 67, 62);">Acer, Asus, Dell, Fujitsu, HP, Samsung and Toshiba all announced Windows 10 S laptops starting at $189 at the Windows 10 S EDUCATION EVENT. </span></p>
<p>Windows 10 S launched at a EDUCATION event. </p><p><br></p><p>Aimed at schools that already run Microsoft products as their core products. Aimed at those schools on the fence about possibly using Google products/Chromebooks. Aimed as those schools that currently run a mix of Chromebooks for most because of cost but Windows PC as well because they will run everything and these schools don't like the mix from a support perspective and a cheaper, easier to maintain version that only needs a few apps would replace those chromebooks.</p><p><br></p><p>At the same time bundled with better management tools AIMED at schools (Intune for schools/teams for schools etc).</p><p><br></p><p>At the same time <span style="background-color: rgb(249, 249, 249); color: rgb(62, 67, 62);">Acer, Asus, Dell, Fujitsu, HP, Samsung and Toshiba all announce Windows 10 S devices starting at $189 for the EDUCATION market.</span></p><p><br></p><p><span style="background-color: rgb(249, 249, 249); color: rgb(62, 67, 62);">I don't know for sure but I would bet that none of these cheaper Windows 10 S laptops from the vendors above will be sold to consumers. They will be sold through education channels directly to schools.</span></p><p><br></p><p>All this coverage by Paul about an OS that most people will never even encounter and if they wanted to it would not be easy to get for the average person. In NONE of his coverage does he really cover why 10 S came about nor does he cover how it works for what it was designed for (schools in a school environment). </p>