Windows Technical Preview  

1,031 members have voted

  1. 1. On a scale of 1-5, 1 being worst, 5 being best. What do you think of Windows 10 from the leaks so far?

    • 5.Great, best OS ever
      156
    • 4. Pretty Good, needs a lot of minor tweaks
      409
    • 3. OK, Needs a few major improvements, some minor ones
      168
    • 2. Fine, Needs a lot of major improvements
      79
    • 1.Poor, Needs too many improvements, all hope is lost, never going to use it
      41
  2. 2. Based on the recent leaks by Neowin and Winfuture.de, my next OS upgrade will be?

    • Windows 10
      720
    • Windows 8
      20
    • Windows 7
      48
    • Sticking with XP
      3
    • OSX Yosemite
      35
    • Linux
      24
    • Sticking with OSX Mavericks
      3
  3. 3. Should Microsoft give away Windows 10 for free?

    • Yes for Windows 8.1 Users
      305
    • Yes for Windows 7 and above users
      227
    • Yes for Vista and above users
      31
    • Yes for XP and above users
      27
    • Yes for all Windows users
      192
    • No
      71


Recommended Posts

Huh? Is Android a desktop OS? I think not...

I suppose you meant "switch to mac", in that case, well, we have other alternatives, we can stick to older versions of windows like XP, Vista and 7... not everyone needs to have the latest piece of software all the time... Windows 8 (with some tweaks and with 8.1 update 1 installed) works great for me but I really really miss the start menu.

Android - like it or not - is as capable of becoming a desktop OS as any Linux distribution; in fact, usable ISOs of Android-x86 (based on ICS and all the successors - including Lollipop, by the by) are available today.  The only lack is Google Play Services - and even that is fixable; a Google search even details exactly how. (In fact, I have an Android-x86 VM based on the forthcoming 5.0.2 in my copy of Oracle VirtualBox.)  While Android started with ARM, it certainly hasn't stayed there - remember Intel's Atom? Any Intel Core 2 Duo (possibly even Core 2 Solo, and certainly Celeron DC and later) can run Atom-based code untouched - that is why HAXM works with ATOM-based images in Android developer packages (and how Hyper-V is leveraged by VS 2015).  I didn't bring up the transition issues (DALVIK->ART and hardware changes in terms of Android support moving forward) as merely a looking-forward problem for Android developers - the issue exists now, because Atom-based hardware running Android exists today. And because Atom is, in fact, a *supported* (by Google, no less) Android platform, ARM-isms in Android (certainly back to at least Jelly Bean - which has an official Google API Atom image) have to go.  In other words, the ball is back in the court of developers, as the ARM-box they have been in is now gone.

Android - like it or not - is as capable of becoming a desktop OS as any Linux distribution;

 

Android emulator works great in a Windows 10 VM, with full touchscreen support.

Android emulator works great in a Windows 10 VM, with full touchscreen support.

I wasn't referring to ARM emulation, Dot - I was referring to Android on x86; in other words, native Android.

 

If you download either Eclipse or Android Studio, x86 is now a supported target platform as far back as Ice Cream Sandwich.  Remember, x86 - including x86_64, as far back as Intel's own Core 2 architecture, can indeed run Atom-based (including Atom x86_64) software directly - as in without emulation.  If you can completely banish native code in your application, the underlying hardware becomes completely irrelevant.  Naturally, hardware-irrelevancy is the Holy Grail of multiplatform developers - and a world-class nightmare to any developer (for any platform) that relies on hardware lockdown - and especially leveraging native code.  Android is moving away from reliance on native code - and has been since the merger of the tablet and phone-targeting code with Android 4.0 - the aforementioned Ice Cream Sandwich.  Rather amusingly, iOS development is following suit - despite iOS only running on ARM.  So who is left relying on native code among mobile platforms?  Only Windows Phone - the least-popular mobile target - and entirely due to that native-code reliance.  In other words, native code - especially in terms of mobile development - is in serious trouble.

There's no doubt that winrt is going to be what they push going forward but for now they're making it possible to call/user win32 APIs from within modern/metro apps. The only question here is do they keep that or try to redo many of the old win32 stuff as new winrt ones?

 

I think in the end we'll see a pure winrt environment with very little if any win32 code left, even on the desktop. They can do this because the OS already has the ability to either emulate the legacy bits or just run old apps in a VM using something like app-v.

 

Using more fresh, new and most important, legacy code free winrt APIs going forward is better in my opinion. Now that you can have apps windowed or full screen with responsive UIs so they can adapt to the device type then you can do quite a lot and have less of a need to use the older technology.

 

True, the other possibility is they're using win32 API's to speed up development and then eventually they'll replace those win32 dependencies with a home grown modern underpinning. I remember reading that a while back on Arstechnica regarding this and it does sound like a viable plan especially since once you've got people using WinRT then it is easier to change code behind the scenes without all the drama that exists today with the win32 api. When it comes to feature parity with Win32, I'd say that Microsoft is probably having to rationalise what API's they feel that they need to provide to third parties whilst at the same time stepping back and recognising that it isn't something that they should provide. Win32 became a giant mess in part because it tried to be everything to everyone rather than clearly defining "this is what we should provide but if you want something more then it falls on your shoulders" or otherwise you end up with a set of API's that become unwieldy.

True, the other possibility is they're using win32 API's to speed up development and then eventually they'll replace those win32 dependencies with a home grown modern underpinning. I remember reading that a while back on Arstechnica regarding this and it does sound like a viable plan especially since once you've got people using WinRT then it is easier to change code behind the scenes without all the drama that exists today with the win32 api. When it comes to feature parity with Win32, I'd say that Microsoft is probably having to rationalise what API's they feel that they need to provide to third parties whilst at the same time stepping back and recognising that it isn't something that they should provide. Win32 became a giant mess in part because it tried to be everything to everyone rather than clearly defining "this is what we should provide but if you want something more then it falls on your shoulders" or otherwise you end up with a set of API's that become unwieldy.

That is indeed pretty much the case, Mr. N.

As a developer, if you are looking multiplatform from the start (and I do get why - betting on a single platform is becoming more and more dangerous, and this is especially the case for mobile development) you want to use as little native code as possible.

The same is, in fact, true of multiconsole development (and especially multiconsole AND PC development) why has THAT become not just the pre-dominant target, but DOMINANT target for gaming development as a whole, even prior to PS4 and XBOX ONE?

 

WinRT is neutral in several ways that Win32 (which it is a subset of) is not - the most important is that it doesn't rely as much on native code  - that is actually provided by the OS itself, and is one thing that the developer doesn't have to worry about.  An API (any API) is a bridge - it's a lot easier to build a footbridge than the Golden Gate Bridge.

That is indeed pretty much the case, Mr. N.

As a developer, if you are looking multiplatform from the start (and I do get why - betting on a single platform is becoming more and more dangerous, and this is especially the case for mobile development) you want to use as little native code as possible.

The same is, in fact, true of multiconsole development (and especially multiconsole AND PC development) why has THAT become not just the pre-dominant target, but DOMINANT target for gaming development as a whole, even prior to PS4 and XBOX ONE?

 

WinRT is neutral in several ways that Win32 (which it is a subset of) is not - the most important is that it doesn't rely as much on native code  - that is actually provided by the OS itself, and is one thing that the developer doesn't have to worry about.  An API (any API) is a bridge - it's a lot easier to build a footbridge than the Golden Gate Bridge.

 

And I also think that Microsoft coming back with a focus on native code, the move to improve their compiler and supporting C++ '14 after years of aimlessly wondering around in a 'managed code is the future haze' (Apple went through the same phase with their Garbage Collector for Objective-C, but they found their senses, developed ARC, Swift and Clang/LLVM and the new libc++ library has put them squarely in the camp of C++ developers best friend) - WinRT is what developers wanted for years, not managed code framework (aka .NET for the desktop) but a better set of frameworks for native code with the added bonus that it can span from smart phone to tablet to laptop without all the pain and heartache that came with win32. Then add to that the language agnostic nature of WinRT and it is definitely a winner - don't like C++ then use HTML5, don't like that then use JavaScript, want to use Python? great, go a head and use it till your hearts content. Microsoft has gotten back its developer groove by having a developer at the helm - 'developers, developers, developers, developers'.

 

Edit: Given the clean nature of WinRT I wouldn't be surprised if we see an implementation ala wine appearing given that it should be a lot easier to implement WinRT based on the fact that it is new, properly documented and built from the ground up. I'd hazard to guess that going forward we're going to see Microsoft move their whole Office stack to sit on top of WinRT, create underpinnings in WinRT for OS X, Android and iOS backends then recompile for each platform and take the relevant parts they need from WinRT with them aka like what they did back in the days they used Mainsoft to provide Internet Explorer/Outlook Express on Solaris and HP-UX.

  • Like 1

Does this new Login Screen has been discussed already or not, I deleted my VM, so can't test here: http://news.softpedia.com/news/Windows-10-Build-9901-Features-New-Login-and-Lock-Screen-Design-468942.shtml

Nope, first time I've seen it, interesting. Another thing in those shots that's interesting are the new icons you see fort things like task manager.

 

It'd be something if they can make task manager, or at least a basic mode of it into a modern app as well.

Android - like it or not - is as capable of becoming a desktop OS as any Linux distribution; in fact, usable ISOs of Android-x86 (based on ICS and all the successors - including Lollipop, by the by) are available today.  The only lack is Google Play Services - and even that is fixable; a Google search even details exactly how. (In fact, I have an Android-x86 VM based on the forthcoming 5.0.2 in my copy of Oracle VirtualBox.)  While Android started with ARM, it certainly hasn't stayed there - remember Intel's Atom? Any Intel Core 2 Duo (possibly even Core 2 Solo, and certainly Celeron DC and later) can run Atom-based code untouched - that is why HAXM works with ATOM-based images in Android developer packages (and how Hyper-V is leveraged by VS 2015).  I didn't bring up the transition issues (DALVIK->ART and hardware changes in terms of Android support moving forward) as merely a looking-forward problem for Android developers - the issue exists now, because Atom-based hardware running Android exists today. And because Atom is, in fact, a *supported* (by Google, no less) Android platform, ARM-isms in Android (certainly back to at least Jelly Bean - which has an official Google API Atom image) have to go.  In other words, the ball is back in the court of developers, as the ARM-box they have been in is now gone.

 

Android X86 stable distributions actually have play store access, the main problem is apps (mostly games) compiled with the native code libraries will only work on ARM processors. I'm hoping that more developers will start making their stuff x86 compatible as tablets powered by atom processors are becoming more common.

Nope, first time I've seen it, interesting. Another thing in those shots that's interesting are the new icons you see fort things like task manager.

 

It'd be something if they can make task manager, or at least a basic mode of it into a modern app as well.

 

those are modern icons, so i doubt they are anything but modern applications. i also wouldnt be surprised, and fully expect most os utilities, like notepad,paint,calculator,etc. to all be replaced by modern versions as well.

 

the modern/metro takeover is real

  • Like 2

I'm fine with modern apps replacing the others as long as we don't lose things in the process feature wise. To that point though I'm expecting a large increase in new winrt APIs that will allow for things with Windows 10.

Nope, first time I've seen it, interesting. Another thing in those shots that's interesting are the new icons you see fort things like task manager.

 

It'd be something if they can make task manager, or at least a basic mode of it into a modern app as well.

IF you refer to the icons on that list, I think that list isn't a Windows thing, rather a tool that user has installed on Windows.

IF you refer to the icons on that list, I think that list isn't a Windows thing, rather a tool that user has installed on Windows.

That could be it, wouldn't surprise me but at the same time I still like to see updated modern versions of the core apps and tools that come with the OS.

Dot Matrix, on 05 Jan 2015 - 20:36, said:Dot Matrix, on 05 Jan 2015 - 20:36, said:Dot Matrix, on 05 Jan 2015 - 20:36, said:Dot Matrix, on 05 Jan 2015 - 20:36, said:

I hope those icons hold out to be true. I'd love to see modern replacements for tools that have long sat in the weeds.

 

Well the metro calculator in Windows 8 is f*@(3ng sh!#@. If that's something to go by then I'd rather they let paint, calculator and task manager sit in the weeds

We're not looking at the windows 8 versions, we're talking about what comes with v10. We've already seen glimpses of updated apps with new/tweaked UIs in 9901. There's little reason to keep the old apps around once the new and universal ones have surpassed them.

I have a video driver issue with the Win 10 preview, My video card is a Nvidia GT 635 (it's an oem card Dell uses). I've tried multiple video drivers (all of them WHQL), I choose the 8.1 64-bit versions. Explorer stops drawing periodically and I have to kill & restart explorer.exe, otherwise the taskbar etc is all glitched.

 

I think the build number is 9878, not home now to check. Is there a later build I can install or should I just wait for the Jan 21 CP release?

New Calculator App:

iedyd0.png

 

 

Well the metro calculator in Windows 8 is f*@(3ng sh!#@. If that's something to go by then I'd rather they let paint, calculator and task manager sit in the weeds

Better?

 

I will try the reg hack when I get home for the new login screen.

I have a video driver issue with the Win 10 preview, My video card is a Nvidia GT 635 (it's an oem card Dell uses). I've tried multiple video drivers (all of them WHQL), I choose the 8.1 64-bit versions. Explorer stops drawing periodically and I have to kill & restart explorer.exe, otherwise the taskbar etc is all glitched.

 

I think the build number is 9878, not home now to check. Is there a later build I can install or should I just wait for the Jan 21 CP release?

 

It's not much of a graphics driver issue than one that's Windows 10 build related. It's a bug, that has been reportedly fixed via two updates for it. Try to install the updates within Windows Update and see if that solves your trouble. There's also the leaked 9901 build that from my testing did not have the GDI+ rendering leak occurring as in the 9879 one, however, it is slightly incomplete on its own way.

 

Luckily, the consumer preview is 2 weeks and 2 days away, which should be more of a solid preview than these ones so far, focusing on consumer features too.

It's not much of a graphics driver issue than one that's Windows 10 build related. It's a bug, that has been reportedly fixed via two updates for it. Try to install the updates within Windows Update and see if that solves your trouble. There's also the leaked 9901 build that from my testing did not have the GDI+ rendering leak occurring as in the 9879 one, however, it is slightly incomplete on its own way.

 

Luckily, the consumer preview is 2 weeks and 2 days away, which should be more of a solid preview than these ones so far, focusing on consumer features too.

Didn't realize it was a Windows 10 bug. I reported it using the feedback tool and didn't see any other mention of it, and my Windows Update is current. I think I shall wait for the CP, which I'm going to clean install anyway. Thanks.

Why does that Calculator app repeat itself twice? You've got "Calculator" and the hamburger menu in the title bar, then it repeats again in the sidebar. Bad design, if you ask me.

The second one in the side menu is for the category, notice that under it, it says standard, scientific and then you see the converter category listing.

This topic is now closed to further replies.