Slashdot Mirror

> and not to be a testbed for new technologies

But IPV6 is not new technology. The RFC is 14 years old, and current computer operating systems already speak it. An 11 year old operating system, Windows XP, speaks it. http://support.microsoft.com/kb/2478747

The "install" is merely enabling what is already there.

> From their point of view, they are good for years to come so why change that.

But they aren't good for years to come. Once IPV6 comes out regularly, that horde of addresses will be worthless and they will be stuck with obsolete tech. No, wait, it's already obsolete.

--
BMO

Best look at the new technet T&C that were instituted on 16 July....

The software now has gone to the more 'subscription based' model where as if you do not renew, your keys expire (Previously, unrenewed accounts did have keys expire). They've also removed some 'non enterprise' software such as Windows 7 Ultimate, Home Edition, reduced number of keys, etc etc.

List of software offered on first tab, list of 'retired' software on second tab: http://download.microsoft.com/download/C/7/8/C78DB720-88CB-455E-AA0E-A087CB332A23/TechNet_Product_List.xlsx

Are you better off? Probably if you use it to its full extent "for testing purposes" but you won't get 5 keys unless you go Pro, I believe.

Cheers
-m

Ick -- WSAAsynGetHostByName? In this day and age, you have a window handle lying around?

I'm the Program Manager for WinSock at Microsoft. Have you looked at GetAddrInfoEx? In Windows 8/Server 2012, the DNS team added some Async features into it. Even better, it will properly handle IPv6 AND international domain names.

And if you're doing the new "Runtime" programming for Windows 8, we done our best to make sure that most network programs never have to deal with IP addresses at all -- that means that new new RT apps should be IPv6 ready out of the box.

(We also do the dual-stack thing with our sockets, so listener sockets just specify a port (or service) to listen on, and we automatically listen to both IPv6 and IPv4. We updates .NET 4.5 in the same way to make dual-stack be simpler.)

Links: http://msdn.microsoft.com/en-us/library/windows/desktop/ms738518(v=vs.85).asp

I can pretty much guarantee that XP will be around for at least another decade.

XP will be "around" but no longer supported after April, 2014, when Microsoft ends security updates for Windows XP. This means that if a security issue or bug is found in the system, Microsoft will be under no obligation to fix it (and hopefully they don't so I can stop supporting IE6).
See Windows Lifecycle chart: http://windows.microsoft.com/en-US/windows/products/lifecycle#section_2

I don't see tablets and cell phones as a very viable market for document creation and editing. Tablets and cell phones are for consumption and it's going to take a hell of an engineering feat to make it more practical otherwise.

Why would it take "a hell of an engineering feat"? What's wrong with these?

Office 2000 still works. It'll even open docx files with this.

I'm happy to use the more recent versions of Office, but it has to be on someone else's dime. (Like, my place of employment.) I bought 2000, it works, and they're gonna havta pry it from my cold dead hands (at least until I switch to something open source).

Why would a home user waste valuable income on a new version of Office? Are ribbons all that important for that letter to Aunt Edna?

Right. HTML5 local storage is a fairly recent addition. You might also have been able to use a cookie with the "secure" flag set, which means the cookie is sent only over HTTPS connections, but AFAIK can be accessed in JavaScript code locally. I'm not certain whether such cookies are accessible through JavaScript that arrived over unencrypted HTTP, though, so that might not work.

Regarding cross-origin XHR, it's pretty straightforward. It works just like regular XHR. The only difference is that the server has to send out an Access-Control-Allow-Origin header to indicate that the browser should be allowed to make the request. And the browser makes two requests—a HEAD request to check the ACAO header and an actual request for the URL. As a small caveat, unless they have fixed it recently, Internet Explorer requires you to use a different object, XDomainRequest.

That are NOT all that different than what I suggested, by using IE "zones" & setting Scripting + ActiveX controls to restricted & using IE's "Enhanced Security Configuration" to do so via EMET!

(Which does a LOT of what I suggested here earlier in my 3 posts, mainly the 2nd one, where I noted turning off scripts & such!):

---

Microsoft Security Advisory (2757760) - Vulnerability in Internet Explorer Could Allow Remote Code Execution:

http://technet.microsoft.com/en-us/security/advisory/2757760

---

* For now? That'll work!

APK

P.S.=> However - setup that way? IE'll "nag you to death" saying "do you wish to run this" etc./et al!

(Which is 1 thing about IE I could NEVER stomach - you turn off scripts or ActiveX? It keeps nagging, & not even a "do not show this again" option... ugh!)

... apk

Let's not forget that Microsoft Research has done remarkable job at discovering and developing real life HUDs. For example back in 2004 Bill Gates himself assigned the goal of

I think you are confused with FUD research.

Let's not forget that Microsoft Research has done remarkable job at discovering and developing real life HUDs. For example back in 2004 Bill Gates himself assigned the goal of

• Microsoft's solution: System Center Configuration Manager
• Free + OSS solution: Local Update Publisher (uses the same official, documented APIs as SCCM)

The enterprise MSIs are patched in sync with the other updates. Managing Chrome via LUP + the Chrome ADMs is a breeze, since if an "uncontrolled" (LocalAppData) Chrome instance starts and there's a MSI on the machine, the uncontrolled instance will respect the GPO settings.

Find the actual advisory here: http://technet.microsoft.com/en-us/security/advisory/2757760

[Grumble]Should have been included in the post...[/Grumble]

http://technet.microsoft.com/en-us/security/advisory/2757760 There's a list of what's affected on that page :)

Windows isn't used for high-performance computing, nor as a real-time OS, so it probably won't ever get this feature.

O RLY? (okok, only 2 of the top500, but it's not like it's NOT used. I'd be surprised if it's used anywhere that's not being paid by Microsoft to do it though.)

As I said :-)

Windows isn't used for high-performance computing, nor as a real-time OS, so it probably won't ever get this feature.

O RLY? (okok, only 2 of the top500, but it's not like it's NOT used. I'd be surprised if it's used anywhere that's not being paid by Microsoft to do it though.)

http://technet.microsoft.com/en-us/security/advisory/2757760

Linking from "Microsoft issued an advisory" to submitter's site is kinda lowbrow.

[You don't need a hardcore gamer PC to do common office tasks]

Microsoft is working on solving that problem as we speak!

As I see it, system requirements have increased far less from Windows Vista to Windows 8 than they did from Windows XP to Windows Vista. In fact, Windows 8's system requirements are explicitly exactly the same as those of Windows 7. Part of this is that Microsoft doesn't want the 10" laptop segment to go back to Ubuntu.

I expect these tablets will be locked to Windows 8 through a secure boot system. It remains to be seen that users will be able to install other OSes.

I.e., it remains to be seen whether the tablets will not conform to the Windows Hardware Certification Requirements for Windows 8 Client and Server Certified Systems (look for "non-ARM") by not supporting Custom Mode and not allowing Secure Boot to be disabled?

For me, the year of linux on desktops is now. With Steam coming to Linux, along with Crossover and pure Linux-ported games, the inevitable has happened. I'm glad Visual Studio also runs perfectly on Wine (I'm also making sure to have a party with my friends on Visual Studio 2012 Virtual Launch Party, where thousands of geeks around the globe connect together to party the release of latest Visual Studio). Everything I need works in Linux.

Steam coming to Linux is a start. It would take a lot more than the handful of valve games getting ported to seriously interest me, though. In my opinion it will be viable when you can reasonably assume any random game that is released will have a Linux version available. As far as I'm concerned a wine based solution is really no solution at all; unless it's like the last app you need and everything else is already native. I'm all for Linux on the desktop, but I think it's still got a long way to go.

For me, the year of linux on desktops is now. With Steam coming to Linux, along with Crossover and pure Linux-ported games, the inevitable has happened. I'm glad Visual Studio also runs perfectly on Wine (I'm also making sure to have a party with my friends on Visual Studio 2012 Virtual Launch Party, where thousands of geeks around the globe connect together to party the release of latest Visual Studio).

Everything I need works in Linux.

Comparing Vista to 7 is like saying XP was just Win2000 with a better kernel, its horseshit.

Fixed for ya and I agree: it's horseshit, XP and Win2000 basically shared the same kernel, Vista and 7 do the same. Then, the new features of Windows 6.1 were so groundbreaking that they were rightfully backported to Windows 6.0, through Platform Update and Platform Update Supplement. However i might concede that some drastic improvements like the "10px taller taskbar" or the "fade-in highlight effect when the user moves the mouse over" the start orb are still Windows 6.1 exclusive.

Comparing Vista to 7 is like saying XP was just Win2000 with a better kernel, its horseshit.

Fixed for ya and I agree: it's horseshit, XP and Win2000 basically shared the same kernel, Vista and 7 do the same. Then, the new features of Windows 6.1 were so groundbreaking that they were rightfully backported to Windows 6.0, through Platform Update and Platform Update Supplement. However i might concede that some drastic improvements like the "10px taller taskbar" or the "fade-in highlight effect when the user moves the mouse over" the start orb are still Windows 6.1 exclusive.

What about "partial", "ref" and "^" that are specific to Microsoft C++. If you use them then your code not work elsewhere, and you probably do need to use them when developing using Windows libraries, yeah?

No, you don't have to.

First of all, there are two language extensions involving those. One (the original one, which introduced them in 2005) is C++/CLI. This was simply a better designed replacement for Managed C++, that made semantics of managed classes more coherent with regular C++ - e.g. it had RAII for managed objects. You only need that if you want to call something inside a .NET library from C++ code or vice versa, and can't or don't want to use COM Interop or P/Invoke.

Second extension, a new one which just reuses the syntax, is C++/CX, which lets you consume and author WinRT classes in Win8 apps. It makes things a lot easier, but it's basically just a thick layer of syntactic sugar, and you can ignore it if you want to. Since WinRT is a well-documented ABI (COM with bells and whistles), you can work with it on that same level, treating interfaces as classes, or even as structs with raw vtable pointers. There's a library to help you do it that way.

The right way to treat C++/CX, IMO, is not as an extension of C++, but as a different language that happens to include C++ as a proper subset. Much like Objective-C is with respect to C, or Obj-C++ and C++. Consequently, if you want to write portable code, the easiest way is to stick to conforming C++ for all areas that don't change from platform to platform, and use C++/CX (or WRL, if you really hate anything other than vanilla C++) for platform-specific bits. Then you'd replace those platform-specific bits with Obj-C++ on iOS, with Java on Android etc. It's not just my advice - it's actually what those official MSDN docs and videos tell you to do.

From another perspective, you can consider C++/CX to be a lot like Qt language extensions for slots and metadata, except implemented directly in the compiler rather than as a separate preprocessor.

In the case of _VARIADIC_MAX why not make the more-standard behaviour the default?

What do you mean by "more standard behavior" here? The old default of 10? The reason why it was reduced to 5 is because variadics are basically emulated by optional template parameters with defaults, and the more you have, the more implicit template specializations you end up with when trying to use them. With more stuff added to the headers for C++11 library support, compile times have grown beyond the pain threshold, and it was decided to reduce the default to something more manageable.

The only proper fix for this is to implement variadics, and they (I'm not on that team) are certainly working on it. Not the least because the library guys hate the current hack with a passion as it's a huge pain in the ass to maintain. If you look at how e.g. std::tuple is implemented in the corresponding header, you'll quickly understand.

However, the Unix guys had worked out a better solution ahead of this (since they had made the transition much earlier, just like Linux was used in 64-bit mode for years before it became common for Window users). short was always 16-bits and long was always 32-bits, and int was for when you didn't need to care. Pointers were whatever the platform said they were (and you had a simpler 'flat' memory model than the segmented/thunked stuff Windows kinda exposed you to at the time).

Back in DOS/Win16 days, Microsoft wasn't really the biggest supplier of dev tools for its own platforms, ironically - if you recall, there was also Borland, and they made some mighty fine tools for both Pascal and C. So it wasn't really something that was unilaterally decided, rather the platform slowly evolved from a combination everyone's

What about "partial", "ref" and "^" that are specific to Microsoft C++. If you use them then your code not work elsewhere, and you probably do need to use them when developing using Windows libraries, yeah?

No, you don't have to.

First of all, there are two language extensions involving those. One (the original one, which introduced them in 2005) is C++/CLI. This was simply a better designed replacement for Managed C++, that made semantics of managed classes more coherent with regular C++ - e.g. it had RAII for managed objects. You only need that if you want to call something inside a .NET library from C++ code or vice versa, and can't or don't want to use COM Interop or P/Invoke.

Second extension, a new one which just reuses the syntax, is C++/CX, which lets you consume and author WinRT classes in Win8 apps. It makes things a lot easier, but it's basically just a thick layer of syntactic sugar, and you can ignore it if you want to. Since WinRT is a well-documented ABI (COM with bells and whistles), you can work with it on that same level, treating interfaces as classes, or even as structs with raw vtable pointers. There's a library to help you do it that way.

The right way to treat C++/CX, IMO, is not as an extension of C++, but as a different language that happens to include C++ as a proper subset. Much like Objective-C is with respect to C, or Obj-C++ and C++. Consequently, if you want to write portable code, the easiest way is to stick to conforming C++ for all areas that don't change from platform to platform, and use C++/CX (or WRL, if you really hate anything other than vanilla C++) for platform-specific bits. Then you'd replace those platform-specific bits with Obj-C++ on iOS, with Java on Android etc. It's not just my advice - it's actually what those official MSDN docs and videos tell you to do.

From another perspective, you can consider C++/CX to be a lot like Qt language extensions for slots and metadata, except implemented directly in the compiler rather than as a separate preprocessor.

In the case of _VARIADIC_MAX why not make the more-standard behaviour the default?

What do you mean by "more standard behavior" here? The old default of 10? The reason why it was reduced to 5 is because variadics are basically emulated by optional template parameters with defaults, and the more you have, the more implicit template specializations you end up with when trying to use them. With more stuff added to the headers for C++11 library support, compile times have grown beyond the pain threshold, and it was decided to reduce the default to something more manageable.

The only proper fix for this is to implement variadics, and they (I'm not on that team) are certainly working on it. Not the least because the library guys hate the current hack with a passion as it's a huge pain in the ass to maintain. If you look at how e.g. std::tuple is implemented in the corresponding header, you'll quickly understand.

However, the Unix guys had worked out a better solution ahead of this (since they had made the transition much earlier, just like Linux was used in 64-bit mode for years before it became common for Window users). short was always 16-bits and long was always 32-bits, and int was for when you didn't need to care. Pointers were whatever the platform said they were (and you had a simpler 'flat' memory model than the segmented/thunked stuff Windows kinda exposed you to at the time).

Back in DOS/Win16 days, Microsoft wasn't really the biggest supplier of dev tools for its own platforms, ironically - if you recall, there was also Borland, and they made some mighty fine tools for both Pascal and C. So it wasn't really something that was unilaterally decided, rather the platform slowly evolved from a combination everyone's

Single reason to stop using WinXP: end of vendor security patch support on April 8, 2014. Unless you have air-gapped systems with no sneakernet either, you need to have plans to remove WinXP by that date.

For trivial examples the Microsoft C++ compiler will work ok. The only real pragma needed here is one to prevent a spurious compiler warning, something like 1481 IIRC. The embrace phase is intended to assuage fears that developing for this platform means you won't have Standard C++

You don't need pragmas to disable compiler warnings globally, that's what compiler switches are for. In this case, /wd.

There's no such thing as compiler warning 1481 in VC++, since its warning numbers range from 4000 to 4999. 1481 would be an error, except that number is not used there, either.

I suspect you're actually referring to one of those "this code is unsafe" warnings that got added in VS 2005, and which annoyed a lot of folk to no end, especially since they've also prompted to use the "safe" (and non-standard) alternatives. These were disabled by default, if I remember correctly, in VS 2010.

Now for non-trivial examples we start to have to use #defines to get around optimizations that Microsoft bake into their compiler that will break standard-compliant code if you don't put the #define in

I've read the article you've linked to, but I don't see any mention of #defines or non-conformant optimizations there. Please clarify.

If you are referring to _VARIADIC_MAX, then that's not an optimization. It's a hack to work around the lack of support of variadic templates in the compiler while still wanting to provide the corresponding library facilities. In other words, it's the case of not supporting the standard well enough (yet), not deliberately straying from it to break your code.

Now this may not be intentional by the Microsoft C++ compiler team these days but at one point it absolutely was Microsoft's goal to tie developers into their technology and make it hard to get out (eg. all the extensions for Managed C++, now deprecated, sigh) -

Managed C++ and C++/CLI were there to let you quickly write glue code between native C++ libraries and .NET apps. That scenario presupposes that you're already "tied" into our technology. If you're not, than why would you even want to use it?

Now we get to the bits of a program that are dependent on Windows (that is, required to make a program do anything useful on Windows). Here we get types and macros all over the place that are specific to Windows. Once you start using these your code is not going anywhere else. Now you may argue that this is the case on any platform but it is not so. Most other toolkits use Standard C++ types in their interfaces, they don't define a whole new set of types via macros. Now, this may be a legacy of old ways of doing Windows development

This is indeed the legacy of old ways of doing Windows. Keep in mind that most of those typedefs hearken back to the days when Windows was a 16-bit OS, and there were such (inherently non-portable) concepts as "near" and "far" pointers in that memory model (LP in LPSTR means "long pointer", a synonym for "far"). And there was also a time when 16-bit and 32-bit Windows were widespread side by side, so you had to contend with the fact that e.g. int could be 16-bit on one platform and 32-bit on another.

You are not, however, required to use any of those typedefs in your own code. Since we've got stdint.h (and VC has it since 2010 SP1), portability is fully settled. Personally, I always use int32_t, intptr_t and such in my code. The declarations of Win32 functions use all that ULONG and DWORD crap, but so what? They're all just aliases, you can ignore them, and what they're defined to is actually documented on MSDN.

Hungarian Notation 'warts' that persist in C# today with the 'I' prefix [completely unnecessary and unhelpful when you refactor between classes and interfaces - but the drones cannot help themselve

Well, as a Microsoft employee I'm surprised you need to ask, but let's go ...

Embrace
For trivial examples the Microsoft C++ compiler will work ok. The only real pragma needed here is one to prevent a spurious compiler warning, something like 1481 IIRC. The embrace phase is intended to assuage fears that developing for this platform means you won't have Standard C++.

Extend
Now for non-trivial examples we start to have to use #defines to get around optimizations that Microsoft bake into their compiler that will break standard-compliant code if you don't put the #define in (cite: http://msdn.microsoft.com/en-US/library/vstudio/bb531344.aspx; some are needed to be more standards compliant [good!], some are needed to regain standards compliant because the default implementation is not to be [bad :(]). Once these #defines are in a large codebase you are starting to get tied to the Microsoft compiler only unless you do a lot of additional work to add additional #ifdefs. Now this may not be intentional by the Microsoft C++ compiler team these days but at one point it absolutely was Microsoft's goal to tie developers into their technology and make it hard to get out (eg. all the extensions for Managed C++, now deprecated, sigh) - which means the legacy behavior of their compiler and current accepted techniques (eg. requiring special defines to get standard behavior back) are permitted by their design team (they should not be, non-standard behavior should be selected by specifying exceptions/defines, not the other way around).

Extinguish
Now we get to the bits of a program that are dependent on Windows (that is, required to make a program do anything useful on Windows). Here we get types and macros all over the place that are specific to Windows. Once you start using these your code is not going anywhere else. Now you may argue that this is the case on any platform but it is not so. Most other toolkits use Standard C++ types in their interfaces, they don't define a whole new set of types via macros. Now, this may be a legacy of old ways of doing Windows development (grrr Charles Simonyi, stealing FORTRAN abominations to make Hungarian Notation 'warts' that persist in C# today with the 'I' prefix [completely unnecessary and unhelpful when you refactor between classes and interfaces - but the drones cannot help themselves any more and can't see the badness of that style]). Anyway, my point is that you can't write modern C++ for Windows without injecting a whole lot of platform-dependencies into the code (eg. types, macros) that are far more than just the class interfaces of Windows-specific libraries. The original intent from Microsoft was to tie your code to the Windows platform (hence decrease the ability to move code to competitors). IMHO, it seems the Windows engineers are valiantly trying to remove the sins of the past (for which I give them full credit) - I even remember Microsoft announcing in the first releases of .NET that not only was C++ not standard but it would never be standard. Fortunately this attitude has changed, but we still remember the danger of depending on Microsoft C++ before. I aim never to be in a position where my code is tied to Microsoft again, hence my post warning others.

After all, much of the world can't upgrade to IE 9 and they may not be willing to install a non-MS web browser. Might as well let them keep using Google Apps until Microsoft pulls the plug on XP support.

On the other hand, if Google's goal was to help push people off of Windows XP or at least off of IE8, they shouldn't wait until November.

if it's a win8 only chip, it quite possibly includes the damn "Trusted Boot" feature that MS wants on all hardware with UEFI. This means that unless the fucking bootloader and OS is blessed by MS, it wont run.

Unless you turn on "Custom Mode", which, according to Microsoft's Windows Hardware Certification Requirements for Client and Server Systems, has to be supported for "non-ARM systems" (see item 17 under "System.Fundamentals.Firmware.UEFISecureBoot"), or disable Secure Boot, which also has to be supported for "non-ARM systems" (see item 18 under "System.Fundamentals.Firmware.UEFISecureBoot").

They stated this is a windows 8 only chip. So they won't release specs for other operating systems to use this. Also since windows 8 'require's' the uefi secure boot option

It requires that it not support other OSes on ARM machines. It requires that it be possible to turn it off on x86 machines.

how much do you want to bet intel made Clover trail boards 'won't' support either disabling it nor adding your own keys?

How much do I want to bet that Intel-made Clover Trail boards will violate the Windows Hardware Certification Requirements for Client and Server Systems item 17 in the "System.Fundamentals.Firmware.UEFISecureBoot" section by not supporting "Custom Mode"? Not very much.

How much do I want to bet that Microsoft will change that part to allow that? Maybe a little more, but not much.

This won't stop linux dev's. Saying something can't work is a challenge to some of them. it's just intel won't provide patches for the in kernal systems to get it running, they might even go as far as to stop such patches being added if they actually 'did' make an agreement with microsoft to make this a 'windows 8 only' chip.

Stop them, presumably, either by threatening patent suits (if there are patents involved) or threatening not to contribute patches in the future?

You're welcome. And yes that includes a commercial license.

Linux advocate:

"It may be slower, but you're not stuck with anything Windows-like and you can fix the code yourself!"

Prospective user:

"Wait... It's slower, AND it doesn't work like Windows, AND you want me to fix the code myself?!"

A key difference you curiously left out of these two statements is at least $120.

I read the full article, I have to say, I was a bit disappointed. Nothing really of interest. The LED encoding has been done, before, and better. The "Display without Borders" has also been done, before, and much better. And the digital signage was a gimmick. Even as a prototype, it's silly. Yes, you took 18 androids, put them in cases, and glued them to a display rack. Presto, digital signage. Please....

I find it more interesting to read up on the research.microsoft.com projects, or MIT Media lab.

I doubt it but do you have a link? There's no reason they would need to port MFC and ATL for desktop, Office or IE

MFC or ATL are just wrappers over the vanilla Win32 APIs. The latter is what I'm talking about.

I'm not sure what you need a reference for. That Windows RT comes with Office? If so, then the spec sheet for Surface lists it, and it's been widely discussed elsewhere, just Google for it.

It doesn't actually take all that much effort to port the libraries. It's mostly C and C++, remember, and ARM is a 32-bit architecture, same as x86, so you can get pretty far with just a recompile. Not to mention that those libraries have historically had ports to other architectures already - Itanium, most recently. So most of the quirks of relying on platform-specific behavior have already been ironed out way back then.

transmitting beacons frames without the privacy bit set

That's not really a privacy bit. It's an encryption flag. I say this knowing that it's called the "Privacy bit". /quibble

It really doesn't matter what I think. This is how the standard was designed and implemented, and IE using it in its current form is clearly abuse.

When you start Win8 or run IE10 for the first time, it'll ask you to configure some settings. One of them is DNT. You can choose "express", which will set it to on, among other things - but it will also tell you that it'll do so before you choose. Kinda like this.

So, yes, this is user choice. Ad companies may not like the fact that it's easier to enable DNT than it is to disable it, but that's another story.

If DNT ever does get worked into law such that ignoring it carries fines and/or legal penalties

It's already here.

Joining their network and using the internet or anything similar to that is akin to going into someone's house and sleeping on their couch while they're not home.

The problem with your analogy is that they are transmitting beacons frames without the privacy bit set. This frame basically says: "Hi I am a WiFi network, here is my name and all the other info you need to connect to me if you want to!" If you set the privacy bit it basically says: "Hi I am a WiFi network, here is my name and all the other info you need to connect to me if you are authorized!"

In the case of your analogy, the beacon frame sans privacy bit is the eqivalent of posting a sign that says: "Feel free to sleep on my couch if you want to!"

Whether or not the default mode should be open or private is another debate, and I understand that most new consumer wifi equipment has been addressing this from the should private point of view for quite a while. (see WPS)

API docs and open standards are available for Microsoft stuff and they always have been. There have been 100% free dev tools since 2002. The C# compiler ships with the OS still (check inside c:\windows\microsoft.net\framework\v3.5\csc.exe )

MSDN: http://msdn.microsoft.com/en-us/library/ms123401.aspx

Standards: http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).aspx

The problem is that they're closing the tooling and making it subscription based.

This is abusing the trust they have created.

API docs and open standards are available for Microsoft stuff and they always have been. There have been 100% free dev tools since 2002. The C# compiler ships with the OS still (check inside c:\windows\microsoft.net\framework\v3.5\csc.exe )

MSDN: http://msdn.microsoft.com/en-us/library/ms123401.aspx

Standards: http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).aspx

The problem is that they're closing the tooling and making it subscription based.

This is abusing the trust they have created.

Here you go

Seriously, you need to work to either 1) get Visual Studio working and fully supported in Linux or 2) develop as good IDE as Visual Studio. For that matter the whole Linux API needs work. It's simple and elegant under Windows and Mac OS X, but not under Linux.

Btw, if you need a great programming IDE, then download Visual Studio 2012. It's just released now and it's free! MAKE SOMETHING SIMILAR!

There was never the idea that developers had to pay for acces to the API use or information, as in MS charging $500 then $1000 for MSDN.

Win32 API documentation is available for free on the MSDN website and has been for years. There's no need to pay for any subscription. If you do a Google search for a Win32 API function name, the first result will usually be the official documentation for that function.

I know that some people say that MS gives away visual studio, but anyone who says that has not tried to write a non trivial app using the free version.

What specifically can't you do with the free version? I know it doesn't support MFC, but hardly anyone ever uses that any more anyway. If you want to work with the bare metal you code to the Win32 API, otherwise you use C#/.NET, both of which are fully supported in VS Express.

Biometrics are not and should not be used for authentication at all, they fall under the category of identification.

Good article on the differences between Identification, Authentication, and Authorization here:

http://technet.microsoft.com/en-us/library/cc512578.aspx

There is even a section which addresses biometrics specifically.

Coders are the pillar of our industry. We need more of them. Here, get Visual Studio and start coding today!

Knowing how to code does not a developer make.

Coders are the pillar of our industry. We need more of them. Here, get Visual Studio and start coding today!

Windows 2008 backup is already obsolete.

"Note: You cannot use Windows Server Backup to back up file and folders on volumes that require more than 2040 GB (or 2 TB). However, as long as the data size is less than 2 TB, you can perform a file or folder backup. For example, you can back up 1.5 TB of data from a 3-TB volume. But, a full server or volume recovery using the backup will recreate a 2-TB volume instead of a 3-TB volume."

http://technet.microsoft.com/en-us/library/cc753528.aspx

Also, Windows 2008 Backup does not support 4k sector external backup drive. It will support the standard 512 or newer 512e sectors however (emulated and formatted with a vendor provided utility).

Basically to sum it all up, you *must* go with another backup solution. Even if you keep your internal server partitions under 2TB in size, almost all newer external drives are now designed with 4k sector sizes.

Yes, I'm a Windows Server admin. And yes, this fact is frustrating as hell having to inform clients they will need to go with Backup Exec or some other 3rd party backup solution. Especially if they desire BMR functionality.

Yes, I'm serious. However, as DeathFromSomewhere noted in reply to my post, they have apparently restored SD support in WP8 back to normal and are touting it as a new innovative feature (no-one remembers Windows Mobile 5 do they?).

SUA is officially deprecated in Server 2012. Microsoft recommends (!) you use Cygwin instead.

Microsoft's flawed implementation (or lack of implementation) of PAE modes

PAE has worked fine on Windows Server. Microsoft just disables PAE on 32-bit client operating systems because developers of drivers for desktop PC peripherals have been even slower to make their drivers PAE-clean.

You are correct, and the two replies to you are lies. Datacenter gives you UNLIMITED guest OS CALs.

This site is pathetic. The amount of linux shilling that goes on here is sad.

Funny that somebody posting anonymously accuse others of lying without presenting any references to support the claim.

Well, here is the fact: http://www.microsoft.com/licensing/about-licensing/client-access-license.aspx#tab=2 "Windows Server Per-Processer licensing also requires a CAL"

The truth is never shilling (or penny, or pound...)