OSDev.org

Okay, maybe it's not as bad as the title, but it could still turn out really bad. Firstly, I should point out that Win8 isn't the actual problem, it's only computers with the "designed for Win8" logo on them.

MS is making all computer manufacturers that want the Win8 logo on their computer use secure boot UEFI. This is a problem, because it requires all OSes to have a signed UEFI bootloader. That's a problem if you want to install any obscure OS, or even Linux, unless it has a signed bootloader.

Here's an article: http://arstechnica.com/business/news/20 ... stalls.ars

It seems like the major problems will not be with laptops and desktops, but with tablets and more stripped-down devices, since the hardware manufacturers can easily add a way to turn of signing. In the cases where you need a signed bootloader, there are non-GPL bootloaders for Linux (like LILO) that could be modified for the task AFAIK.

But will they? It seems to be the trend to leave most BIOS options out of laptops and cheaper desktops. That's the best case scenario, but it could easily go the other way, since more than 99% of computer users couldn't care less about installing Linux or some other OS. I'm afraid computer manufacturers will leave the option out just because it's such a small minority that even cares. I'm sure top- and mid-level computers will have the option. The problem is that I, and some others, can't afford those computers.

This seems sort of unlikely to me, since the mechanism for managing the keys is already quite complex (and needs to be accessible to the user if they want to install a different version of Windows, or even update certain drivers) so it would be trivial in comparison to include an off switch for it.

There's this eerie feeling that we had a discussion like that before...

TylerH wrote:Okay, maybe it's not as bad as the title, but it could still turn out really bad. Firstly, I should point out that Win8 isn't the actual problem, it's only computers with the "designed for Win8" logo on them.

MS is making all computer manufacturers that want the Win8 logo on their computer use secure boot UEFI. This is a problem, because it requires all OSes to have a signed UEFI bootloader. That's a problem if you want to install any obscure OS, or even Linux, unless it has a signed bootloader.

Here's an article: http://arstechnica.com/business/news/20 ... stalls.ars

Thats why i have stopped x86 OSDev http://forum.osdev.org/viewtopic.php?f=11&t=24183

guyfawkes wrote:Thats why i have stopped x86 OSDev viewtopic.php?f=11&t=24183

Dont make that decision just yet. Stick to your guns because they have lots of ideas. And we all remember Microsofts their latest bad one.

There seems to be a trend in Microsoft operating systems, every second one is actually good. (This also seems to apply to Star Trek movies, take from that what you will).

It seems that this will be just like Windows Vista, when it's "completed" people will still hate it, and it'll be whisked away and replaced with something better</wishful_thinking>

That said, from what I have seen, this is definitely a step backwards. Desktops are not tablets, no matter how hard Microsoft tries to say they are. (I plugged a USB graphics tablet into my PC once, and it got locked to the primary display, and I couldn't move it to the 4:3 secondary display)

From what I have heard (granted, I haven't seen the new API defs, so this is mostly an interpretation of hearsay) the new API deprecates almost all of Win32. This could be a good thing, as every API needs an overhaul eventually, and Win32 is still holds remnants of Win16. And from reading The Old New Thing, it is littered with old techniques that people still use, just because they're there.

(Just my 2c, and was written in a hurry)

thepowersgang wrote:From what I have heard (granted, I haven't seen the new API defs, so this is mostly an interpretation of hearsay) the new API deprecates almost all of Win32. This could be a good thing, as every API needs an overhaul eventually, and Win32 is still holds remnants of Win16. And from reading The Old New Thing, it is littered with old techniques that people still use, just because they're there.

I must admit that I don't go out of my way to find hearsay, so haven't really read any yet, or dug into any documentation of what has or has not been deprecated.

All I can say is that the few bits of code I have compiled on win8, to ensure that they work, have all compiled and run just fine, and they are raw win32 API based code. That said, I have only 'tested' a tiny subset of the available API.

All I can say is that the few bits of code I have compiled on win8, to ensure that they work, have all compiled and run just fine, and they are raw win32 API based code. That said, I have only 'tested' a tiny subset of the available API.

... depreciate does not mean no longer works -- it means that it exists only for backward compatibility (if it didnt exist, all older programs would stop working) what depreciate means is, they are no longer supporting continued development or extension of it, and that they encourage developers to stop using it in favor of newer, and better, things -- note that the GDI portions of winAPI have actually been depreciated since windows vista (when MS replaced it with direct2d)

of course win8 still supports winAPI... however (and i have read the MS information on the MS website) use of winAPI, directX, x86-native code, and .NET are all depreciated... all programs designed for win8 and beyond are expected to use the new 'metro' system

in fact, MS is specifically penalizing developers who insist on continuing to use winAPI/x86/directx/.NET by disallowing them from participating in the new 'windows marketplace' that MS expects all software running under future windows versions to come from (and is (officially at least) the only way to get software onto windows-based tablets and smartphones)

truth is, i would not be the least bit surprised if win9 didnt even support any of these 'legacy' interfaces anymore (nor would i be surprised if it didnt support running on traditional computers (desktops/laptops) at all) -- but then, perhaps im just being a little overly pessimistic

JAAman wrote:of course win8 still supports winAPI... however (and i have read the MS information on the MS website) use of winAPI, directX, x86-native code, and .NET are all depreciated... all programs designed for win8 and beyond are expected to use the new 'metro' system

It is quite possible to create Metro apps using .NET or C++ compiling to native code (watch this presentation for more details, especially the diagram around 8 minutes in: http://channel9.msdn.com/events/BUILD/B ... 1/BPS-1005).

The existing APIs are not deprecated, because desktop apps are not being deprecated. Metro is not a complete replacement since there are some high-precision tasks it just isn't designed to handle (e.g.: photo and video editing, software development, etc.).

JAAman wrote:

All I can say is that the few bits of code I have compiled on win8, to ensure that they work, have all compiled and run just fine, and they are raw win32 API based code. That said, I have only 'tested' a tiny subset of the available API.

... depreciate does not mean no longer works -- it means that it exists only for backward compatibility (if it didnt exist, all older programs would stop working) what depreciate means is, they are no longer supporting continued development or extension of it, and that they encourage developers to stop using it in favor of newer, and better, things -- note that the GDI portions of winAPI have actually been depreciated since windows vista (when MS replaced it with direct2d)

of course win8 still supports winAPI... however (and i have read the MS information on the MS website) use of winAPI, directX, x86-native code, and .NET are all depreciated... all programs designed for win8 and beyond are expected to use the new 'metro' system

in fact, MS is specifically penalizing developers who insist on continuing to use winAPI/x86/directx/.NET by disallowing them from participating in the new 'windows marketplace' that MS expects all software running under future windows versions to come from (and is (officially at least) the only way to get software onto windows-based tablets and smartphones)

truth is, i would not be the least bit surprised if win9 didnt even support any of these 'legacy' interfaces anymore (nor would i be surprised if it didnt support running on traditional computers (desktops/laptops) at all) -- but then, perhaps im just being a little overly pessimistic

Well, legacy is the reason we all use Windows. If not all those programs will work anymore other operating systems look much more interesting. They could solve by running old virtualized Windows though.

When it comes to locking the BIOS to the Microsoft, I'm not sure PC manufacturers will not allow this. Let's say I'm running a large company with hundreds of PCs. Some of them must Linux and disallowing large customers this would be a serious dent in customer satisfaction. This will be like the region less DVD players, in the end all of them are region less or can easily be made region less. Microsoft locked PCs would simply not sell.

Hmm, so my next PC might have (U)EFI, sounds like a mac, might as well buy a real one, at least they have UNIX by default and are generally better made

That's why I'm buying sparc64 machines. OpenBOOT is so much greater than BIOS, and RISC architecture is so much greater than Intel-based processors...

JAAman wrote: truth is, i would not be the least bit surprised if win9 didnt even support any of these 'legacy' interfaces anymore (nor would i be surprised if it didnt support running on traditional computers (desktops/laptops) at all) -- but then, perhaps im just being a little overly pessimistic

Desktops are not going any place soon - if ever. You do not do word processing on a smart phone. I doubt if Microsoft are in the business of cutting off their nose to spite their own face, and if they think they can sell an operating system with a smart phone GUI to businesses, or other desktop users, they might be in for a rude awakening.