Microsoft's CEO Says He Wants to Unify Windows 322
Deathspawner writes A lot of people have never been able to understand the logic behind Microsoft's Windows RT, with many urging the company to kill it off so that it can focus on more important products, like the mainline Windows. Well, this is probably not going to come as a huge surprise, especially in light of mass layoffs announced last week, but Microsoft CEO Satya Nadella has said that his company will be working to combine all Windows versions into a unified release by next year.
Better Information Here (Score:3, Informative)
Re:Death bell tolling for thee.... (Score:2, Informative)
I haven't logged in in ages but anyway...
I don't really think this is all that stupid. I heard elsewhere that the OS will detect (will this need a new API and drivers?) what input methods are available and adjust the UI accordingly. In which case the UI will be different on different devices for intents and purposes. On the other hand all this is doing is making the products all use the same kernel and support the exact same run times. Linux has been doing something similar-ish for quite a while. After you can find Linux on the biggest HPC setups down to a smartphone and cheap ARM uCs. And along with Linux you will find the same OS API and sometimes even the same managed environment like java. So if done right I don't really think it's all that stupid but then again...
Re:Best Wishes ! (Score:5, Informative)
Yes... and no. In theory, if you did a virgin installation of Windows 95 onto a pristine new computer whose peripherals ALL had genuine Win32 drivers capable of running in 386Enh protected mode, and you ONLY ran "true" Winapps that bent over backwards to have no dependencies on realmode, DOS was basically a Grub-like stage 2 bootloader invoked by the BIOS that loaded Windows, kicked the PC into 386enh Protected mode, and handed it over to Windows. And you probably had a pet unicorn living in the back yard ;-)
From what I remember, the compelling feature of Windows 3.11 that distinguished it from Windows 3.1 was native Win32 code for reading & writing (V)FAT filesystems on IDE hard drives (which gave it a HUGE performance boost compared to 3.1).
I believe that one of Win95's launch-time features was that Microsoft re-implemented the VESA BIOS extensions (and original VGA BIOS) as proper win32 drivers, so that manufacturers like Tseng and S3 only had to provide them with "miniport" drivers that did the grunt work that would have otherwise required them to fall back to realmode. I'm pretty sure the 386enh hooks for video BIOS emulation existed in 3.11, but the actual Microsoft-written code was given to vendors to distribute on their own disks & wasn't directly used by any video cards the day Win3.11 went to manufacturing. In a sense, Windows 3.11 existed to give videocard manufacturers a prototype platform so they could develop and test their protected-mode drivers on a released operating system.
Re:Server 2012 already looks like Windows 8. (Score:5, Informative)
I'm sorry, PowerShell is a trainwreck of a language. Extremely unintuitive, inconsistent, cryptic.
Using a function? Call it as function($arg1, $arg2). Oh, did you write the function? Sorry, you'll have to call it as function $arg1 $arg2.
Want to pass a path to something? It's easy: -Path $path. Oh wait, $path is actually a real path and not a glob? You'll have to use -literalPath...if it's supported. Yep, we kept the same failed idea of CMD and decided argument expansion should be done by each command/function/program/cmdlet independently so that we can make damn sure nothing at all is ever consistent. There's a reason why every Unix shell, bash much included, handles argument expansion in the shell.
Sane variable scoping? Not from PS.
Want to use something from .Net? It's built in, a major selling point! Oh...sorry if the syntax is so incredibly buggered that it makes real world PowerShell/.Net code look like a bid for the Obfuscated Perl Contest. And once you get it "right", PowerShell can't grok anything beyond trivial. God help me, I had to craft and populate an IEnumerable of Tuple of String, String in PowerShell to pass to a .Net method (from DacServices). Finally crafted (looked like a spell incantation), it couldn't get through PowerShell to the method call in one piece. Flat out broken. Finally had to give up and just code a real C# console app to handle the 10 lines of code.
Want output/trace to display in the order you actually write it? When it actually happens? Better | Out-Default all of it or strange things happen.
Most sane languages, especially so-called "OOP" languages, actually stop when an exception is thrown by default. Typically with a default global catch that offers you a nice stack trace, or something. PowerShell? By default it keeps on trucking, not even a peep (bad old habits of CMD are hard to break I guess).
Misspell a variable somewhere? Or a method name? Not even a warning until runtime when it fails (but then keeps on trucking right along, happy to double down on the fail). Even Perl isn't that bad (at least with "use strict;").
PowerShell is better than CMD/Batch. But then, so is a swift kick to the head. It's a horrid language and a bad shell. Bash via Cygwin is a hell of a saner and more powerful way to use a shell on Windows. And if you ever need .Net something, do yourself a huge favor and do it from C# as a console app and call that...1,000,000,000 times better than trying to use the fugly hack of a .Net interface that PowerShell provides.