Slashdot Mirror

Learn yourself something. This is the internet afterall.
http://blogs.msdn.com/b/oldnew...

Win 9X didn't run 'on top of' DOS. This explains it better than I ever could:
http://blogs.msdn.com/b/oldnew...

Since they realised their customers were going to use a mixture of systems anyway. For example, they turned off a feature in the Windows CIFS client because the server side was broken in Samba.

I used to develop on Windows with Eclipse and Cygwin. I quickly moved to MinGW because silly things like random games, utilities, etc. that use it would interfere with the version I was developing against.

Which C runtime library do you use with MinGW? I'm told third-party applications shouldn't use MSVCRT.dll anymore.

The demo starts at 2:31:00 into the keynote video:
https://channel9.msdn.com/Events/Build/2015/KEY01

Why does Windows not recognize my USB device as the same device if I plug it into a different port?
http://blogs.msdn.com/b/oldnew...

It does sound and awful lot like the notorious MS07-052: Code execution results in code execution

.

refusal to compete has made Lunix (which is a fitting title as its run by loonies) so low on every metric other than servers

Linux is probably the most installed and most widely used operating system in the world. It's in servers, routers, smart TVs, mobile phones, tablets, etc. It's massively successful.

name any major sites OTHER than Google that supports WebM?

Okay, I've disabled H.264 support in Firefox 38 beta. Let's try some sites and see what works!

Microsoft's Channel 9 supports WebM and works.

Yahoo Screen supports WebM and works.

Yahoo Music supports WebM and works.

Revision 3 supports WebM and works.

Wikipedia supports WebM and works.

Name any hardware OEMs supporting WebM acceleration?

Well, here's a list. It features names like Intel, Broadcom, Qualcomm, Rockchip, Nvidia, Samsung and so on.

Except MSIE is dead. And "Project Spartan" still doesn't have an official name.

I'm not sure if the Windows NTFS driver is not terribly portable either...probably would need a lot of work to make it work with the Linux block layer.

But anyway, there's better SSD TRIM support in Windows: vectorized TRIM ranges, and TRIM integration also with volume level commands.[1]

Then there is GPU driver in userspace, which is a nice concept, although not portable really.

You need to get the industry support behind it

Opus is implemented by all browsers (Firefox, Chrome, Opera, IE soon) that implement WebRTC (or ORTC). Even IE will support Opus soon.

Classic Shell uses DLL injection to get a lot of its functionality to work. This is pretty much the definition of undocumented functionality. You're essentially dynamically inserting code into another process to re-routing function calls to your own code. It allows you to do a lot of really cool things (measuring FPS in any game and displaying it in an overlay, like Fraps), but it's also used by malware writers to do sneaky things (such as hiding itself from the file system or processes viewer).

Undocumented APIs are used by a lot of programmers. It's not all that hard, and many of them are "documented" outside of official channels, like this one: NtCreateThreadEx(), which is used to perform said dll-injection.

I have no doubt that the classic shell programmers did a fine job in getting these things to work, but again, it's impossible to know for sure what the side effects may be. In all honesty, classic shell is probably well-vetted enough that there are probably no major issues with it, but I tend to err on the safe side.

http://blogs.msdn.com/b/oldnew...

  About every ten months, somebody new discovers the Notepad file encoding problem. Let's see what else there is to say about it.

First of all, can we change Notepad's detection algorithm? The problem is that there are a lot of different text files out there. Let's look just at the ones that Notepad supports.

        8-bit ANSI (of which 7-bit ASCII is a subset). These have no BOM; they just dive right in with bytes of text. They are also probably the most common type of text file.
        UTF-8. These usually begin with a BOM but not always.
        Unicode big-endian (UTF-16BE). These usually begin with a BOM but not always.
        Unicode little-endian (UTF-16LE). These usually begin with a BOM but not always.

If a BOM is found, then life is easy, since the BOM tells you what encoding the file uses. The problem is when there is no BOM. Now you have to guess, and when you guess, you can guess wrong. For example, consider this file:

D0 AE

Depending on which encoding you assume, you get very different results.

        If you assume 8-bit ANSI (with code page 1252), then the file consists of the two characters U+00D0 U+00AE, or "". Sure this looks strange, but maybe it's part of the word VATNI which might be the name of an Icelandic hotel.
        If you assume UTF-8, then the file consists of the single Cyrillic character U+042E
        If you assume Unicode big-endian, then the file consists of the Korean Hangul syllable U+D0AE
        If you assume Unicode little-endian, then the file consists of the Korean Hangul syllable U+AED0

  Some people might say that the rule should be "All files without a BOM are 8-bit ANSI." In that case, you're going to misinterpret all the files that use UTF-8 or UTF-16 and don't have a BOM. Note that the Unicode standard even advises against using a BOM for UTF-8, so you're already throwing out everybody who follows the recommendation.

Okay, given that the Unicode folks recommend against using a BOM for UTF-8, maybe your rule is "All files without a BOM are UTF-8." Well, that messes up all 8-bit ANSI files that use characters above 127.

Maybe you're willing to accept that ambiguity, and use the rule, "If the file looks like valid UTF-8, then use UTF-8; otherwise use 8-bit ANSI, but under no circumstances should you treat the file as UTF-16LE or UTF-16BE." In other words, "never auto-detect UTF-16". First, you still have ambiguous cases, like the file above, which could be either 8-bit ANSI or UTF-8. And second, you are going to be flat-out wrong when you run into a Unicode file that lacks a BOM, since you're going to misinterpret it as either UTF-8 or (more likely) 8-bit ANSI. You might decide that programs that generate UTF-16 files without a BOM are broken, but that doesn't mean that they don't exist. For example,

cmd /u /c dir >results.txt

This generates a UTF-16LE file without a BOM. If you poke around your Windows directory, you'll probably find other Unicode files without a BOM. (For example, I found COM+.log.) These files still "worked" under the old IsTextUnicode algorithm, but now they are unreadable. Maybe you consider that an acceptable loss.

The point is that no matter how you decide to resolve the ambiguity, somebody will win and somebody else will lose. And then people can start experimenting with the "losers" to find one that makes your algorithm look stupid for choosing "incorrectly".

The original Xbox OS was derived from Windows 2000

Contrary to popular belief, Windows XB wasn't a fork of NT 5 any more than CE or NT was a fork of Windows 9x. (Source: Xbox Engineering)

Visual Studio has been a veritable breeding ground for bad design decisions, particularly the ALL-CAPS menus and monochromization of the entire interface in Visual Studio 2012. The now-fully-expected Microsoft PR cycle materialized: a salvo of Delay, Defend, Deny... http://blogs.msdn.com/b/visual... ...followed by an admission by Visual Studio product manager Brian Harry: "The implementation of the new UI in 2012 was a mess" ( http://www.itwriting.com/blog/... )

Probably the most damning quote from Harry is this: http://blogs.msdn.com/b/bharry... "...there was a bit of a 'cone of secrecy' around the new UI because we didn't want it 'leaking'. Even I didn't get to see it until months into it." That seems emblematic of the era when the Metro design team going full steam ahead with Metrofying every Microsoft product before, during, and even after Windows 8's buildup, launch, and colossal customer repudiation, as well as the ouster of main Metro proponent Steven Sinofsky. And yet even now, we continue with an MS PR demeanor that could be charitably described as "proselytizing" (yes, that's normal for PR, but that's only one part of their job; another part is to listen to customer feedback).

Visual Studio has been a veritable breeding ground for bad design decisions, particularly the ALL-CAPS menus and monochromization of the entire interface in Visual Studio 2012. The now-fully-expected Microsoft PR cycle materialized: a salvo of Delay, Defend, Deny... http://blogs.msdn.com/b/visual... ...followed by an admission by Visual Studio product manager Brian Harry: "The implementation of the new UI in 2012 was a mess" ( http://www.itwriting.com/blog/... )

Probably the most damning quote from Harry is this: http://blogs.msdn.com/b/bharry... "...there was a bit of a 'cone of secrecy' around the new UI because we didn't want it 'leaking'. Even I didn't get to see it until months into it." That seems emblematic of the era when the Metro design team going full steam ahead with Metrofying every Microsoft product before, during, and even after Windows 8's buildup, launch, and colossal customer repudiation, as well as the ouster of main Metro proponent Steven Sinofsky. And yet even now, we continue with an MS PR demeanor that could be charitably described as "proselytizing" (yes, that's normal for PR, but that's only one part of their job; another part is to listen to customer feedback).

Exceptions make it easy to handle fault conditions badly, but no easier (and arguably harder) to handle fault conditions correctly. I was just reading this rant on Old New Thing today about this very subject. If nothing else, the amount of debate on "how to do this easy thing properly" should suggest that exceptions aren't a silver bullet.

Does this include ".NET Native", where they compile ahead-of-time using the same backend Visual Studio uses for C++?

Keep in mind that, even with new APIs introduced, the old stacks still continue working just fine. WinForms or WPF apps will still run on Windows desktop machines decades from now, just like native Windows applications are still using Windows API calls written decades ago.

Also, despite rumors to the contrary, WPF is still being actively developed, although it's probably fair to say it's "peaked" as a technology, and is now transitioning into a maintenance mode. I'd have no qualms about creating a new WPF project tomorrow - so long as you know you're only targeting the Windows desktop. There are benefits to using a mature technology, and WPF is pretty mature at this point.

You really only need to use the new stack (WinRT) if you're planning to do cross-platform stuff across the entire Windows ecosystem (Metro/Surface/Mobile).

Yeah I know the UAC bit, but that was more to do with being unable to install drivers without elevated privileges.

Also I just looked this up, seems like it's a relatively recent Windows thing. I most certainly have a few unsigned drivers on Windows 7, and I distinctly remember the warning as being quite a bit different from the others. Had a red error cross on the left but what made it distinct was a red banner across the top. Quick image search : this.

All that's needed is elevated privileges, which any installation program will already have after going through a UAC prompt, which means a user will click yes (they've already clicked yes once at this point). So if you end up with something like this distributed with software you chose to install then you're likely outta luck.

Though it appears this no longer works on Windows 8 and you need to go through a massive rigmarole to install them.

Or is there something else I'm missing?

I think a 2006 blog post by Larry Osterman of Microsoft actually explains it better than I could. He talks about the OOTB, or "Out Of The Box" experience by the customer, and how Apple managed to do so much better than nearly any other company at the time.

When people look at hardware specs and raw capabilities, they're completely missing the point of the Apple products. I think if I could sum up the difference in one word, that would be "polish".

These just came out, so I haven't read them, but you can't go wrong with these authors:
A Tour of C++ by Bjarne Stroustrup (the original creator of C++)
Effective Modern C++ by Scott Meyers

Dr Dobbs journal is always good.
Microsoft's Channel 9 has a lot of good talks like these and these.
The ISO C++ committee has a great website.

These just came out, so I haven't read them, but you can't go wrong with these authors:
A Tour of C++ by Bjarne Stroustrup (the original creator of C++)
Effective Modern C++ by Scott Meyers

Dr Dobbs journal is always good.
Microsoft's Channel 9 has a lot of good talks like these and these.
The ISO C++ committee has a great website.

These just came out, so I haven't read them, but you can't go wrong with these authors:
A Tour of C++ by Bjarne Stroustrup (the original creator of C++)
Effective Modern C++ by Scott Meyers

Dr Dobbs journal is always good.
Microsoft's Channel 9 has a lot of good talks like these and these.
The ISO C++ committee has a great website.

Kinda right, kinda wrong...

See http://blogs.msdn.com/b/b8/arc...

As I said, there's a bit of work to do this in regular MSIs, but it's not quite as off-the-beaten-path as with RPM: http://blogs.msdn.com/b/rflami...

There's another fairly major point: although the title of this /. thread talks about "computing teachers", the summary talks about "primary and secondary teachers", and the original press release talks about "teachers responsible for teaching computing". Primary school teachers, who were already expected to know everything about everything, are now (PDF warning) expected to teach programming, debugging, networking, etc. There's no particular reason why people who signed up to teach 5 to 7 year-olds ten years ago would be more likely than the general populace to be good at debugging.

The UI is crazy.
Try to turn it off using the mouse (not sleep, really turn off).

DOS - press the power button, no mouse required
Win95/98/Me/2000/XP - start/shutdown on the bottom left
WinVista/7 - orb / shutdown on the bottom left
Win8 - hover on the top right, wait for something to show up, click beside the power icon, choose shutdown

It remained the same for nearly twenty years.
Why fix what isn't broken?

This would be like moving the file menu to the bottom of a window.
The masses would revolt.

Just look what happened when Visual Studio went to ALL CAPS MENUS
Get some popcorn for the comments.

I'm surprised that .Net doesn't have more popularity in other countries. It has full Unicode support for strings and identifiers. Here's an example in Hindi. Java also supports Unicode variable names. I guess they aren't completely open source/free, but if having multilingual identifiers is as important as you state, then you'd expect these languages to be highly used over thing like PHP which seem to have very little Unicode support.

Promises and async is indeed a good point. I've been writing async (UI) code in C# for the past two years, and have almost forgotten what a mess it was before tasks and await.

BTW, async/await is also proposed for C++, though it is a much more generalized construct there:

http://www.open-std.org/jtc1/s...

VC++ has a preview of the implementation in the current betas:

http://blogs.msdn.com/b/vcblog...

Perhaps you need to read the the original announcement Salient points:

Lay the foundation for a cross platform .NET

As a .NET developer you were able to build & run code on more than just Windows for a while now, including Linux, MacOS, iOs and Android.

The challenge is that the Windows implementation has one code base while Mono has a completely separate code base. The Mono community was essentially forced to re-implement .NET because no open source implementation was available. Sure, the source code was available since Rotor but we didn’t use an OSI approved open source license, which made Rotor a non-starter. Customers have reported various mismatches, which are hard to fix because neither side can look at the code of the other side. This also results in a lot of duplicated work in areas that aren’t actually platform specific. A recent example is immutable collections.

The best way to build a cross-platform stack is to build a single stack, in a collaborative manner. And the best way to do exactly that is by open sourcing it. Building and running on non-Windows platforms. We currently only provide the ability to build and run on Windows. We intend to build a public working group between us and the Mono community once we have enough code out there.

In other words, it hasn't happened yet. They're still at the "laying the foundation" stage, by their own admission. NOT ready for prime time. Anyone using it today still needs to maintain multiple code bases.

.NET Core Runtime (CoreCLR). We’re currently figuring out the plan for open sourcing the runtime. Stay tuned!

Again, an announcement of what WILL happen. Again, not there yet.

The question isn't "is .NET viable today" but "is open-source .NET viable today"? The answer is a resounding NO. You're the one presenting the straw man, not me.

Umm. Are you using Dragon speech to text? Because otherwise you need to learn how to communicate.

Clearly you don't know much about .NET, and clearly you don't know about huge parts of the web, which would not do fine without it.

The open source parts of .NET are not the entire CLR. If you don't use Windows, you don't care about this news. And if you don't use Windows, your only interest is curiosity.

If you were curious, you would try it out and see if you like it. Ergo, I can tell you, the argument for avoiding .NET is that you haven't already done otherwise.

Specifically, read the announcement page and see if you have questions about this. "Working on" means "not open source".

http://blogs.msdn.com/b/dotnet...

These are areas weâ(TM)re working on:

        More libraries. Consider the subset we have today a down-payment on what is to come. Our goal is to open source the entire .NET Core library stack by Build 2015.

        Building and running on non-Windows platforms. We currently only provide the ability to build and run on Windows. We intend to build a public working group between us and the Mono community once we have enough code out there. .NET Core Runtime (CoreCLR). Weâ(TM)re currently figuring out the plan for open sourcing the runtime. Stay tuned!

Not trolling - apparently the Android emulator by Microsoft is faster and has more features (GPS, camera, accelerometer emulation): http://blogs.msdn.com/b/visual... Requires windows, but should be usable with Android Studio and Eclipse ADT.

Why would compatibility be an issue? They already have compatibility shims for things like version numbers.

See, e.g.:

http://blogs.msdn.com/b/oldnew...

Or any of countless other Old New Thing posts.

In enterprise organizations (meaning those with >250 PCs or > $1M in annual revenue) no use is permitted beyond the open source, academic research and classroom learning environment scenarios described above.

I think you need to read the awesome Chriss Brumme's blogs.

Have a look at SafeHandle - garbage collection is so fantastic in .NET that they had to create a reference counted smart pointer class.

Read the "I wouldn't do it like that again" about putting AppDomains into SQLServer and IIS. Oh dear, that was bad... quote: "Frankly, we gave the host and the application a lot of rope to hang themselves. In retrospect, we screwed up."

The blogs are brilliant, don't knock them - but it shows how complex the whole thing is, as he is a techie guy who will say all the things that are imperfect in a way that a marketing guy would not even understand.

As for WCF, WPF, WWF, APS.NET MVC.. my biggest issue with these is not the complexity (though turn on full tracing in WCF and be amazed at how a webservice framework can have so many frigging layers of code to pass a message to app code) but the 'black box; of them. They are all "you do this and this and it works", seemingly by magic. You can trace calls through in the debugger.. and suddenly it will vanish into a section of "it just does its own thing here" magic. Its fine if you're a programmer who is taught to just copy and paste the required code in.. which is I suppose the target audience. Don't think, just follow the rules.

I think you need to read the awesome Chriss Brumme's blogs.

Have a look at SafeHandle - garbage collection is so fantastic in .NET that they had to create a reference counted smart pointer class.

Read the "I wouldn't do it like that again" about putting AppDomains into SQLServer and IIS. Oh dear, that was bad... quote: "Frankly, we gave the host and the application a lot of rope to hang themselves. In retrospect, we screwed up."

The blogs are brilliant, don't knock them - but it shows how complex the whole thing is, as he is a techie guy who will say all the things that are imperfect in a way that a marketing guy would not even understand.

As for WCF, WPF, WWF, APS.NET MVC.. my biggest issue with these is not the complexity (though turn on full tracing in WCF and be amazed at how a webservice framework can have so many frigging layers of code to pass a message to app code) but the 'black box; of them. They are all "you do this and this and it works", seemingly by magic. You can trace calls through in the debugger.. and suddenly it will vanish into a section of "it just does its own thing here" magic. Its fine if you're a programmer who is taught to just copy and paste the required code in.. which is I suppose the target audience. Don't think, just follow the rules.

That's an excellent question but a bit complex to answer. :)

A Microsoft engineer would probably be happy to talk about the specifics. The dotnet blog is a good starting point.

You have a good point. Saying you're "open sourcing .net" can mean a lot of things. Mono is actually useful today. An open source .net that's missing a huge number of libraries and Windows specific features is useless. Might as well just stick with Mono at that point.

Microsoft is closely working with Miguel de Icaza from Xamarin/Mono in order to create a shared code base that can become a cross-platform implementation of .NET Core. More information in Microsoft .NET blog.

It's because Windows boots too fast.

http://blogs.msdn.com/b/b8/arc...

Indeed. I turn off all animations they waste time and resources.

Counter-intuitively, and contrary to the label "Adjust [Visual Effects] for best performance", turning off animations on Windows Vista and above will make your system slower because it disables hardware acceleration.

http://blogs.msdn.com/b/oldnew...

That is only via some Java API, which does exactly what I said above, which is turn the actual internal version into some higher-level OS name.

So what do you think that Java API would return on Windows 9? Don't you think Oracle would have it return the string "Windows 9"?

Trust me, MS doesn't give the slightest concern about any broken Java apps.

Perhaps you should read some of the stories on The Old New Thing about the hoops MS jumps through to maintain compatibility. Here's one (of many). In that one, we find that MS changed the internal implementation of critical sections in Vista, but found that some programs were looking directly at the internals instead of using the API. So in order to not break those programs, MS made sure the value in the internal struct people were peeking at had the value those programs were expecting. Keep looking back through the archives and you'll find dozens of examples of MS doing crazy stuff just to keep programs working in newer versions of the OS. And with many Java apps being big and enterprisey, you can be sure that MS is going to do whatever it can to keep them from breaking on Windows 9^H10.

That is only via some Java API, which does exactly what I said above, which is turn the actual internal version into some higher-level OS name.

So what do you think that Java API would return on Windows 9? Don't you think Oracle would have it return the string "Windows 9"?

Trust me, MS doesn't give the slightest concern about any broken Java apps.

Perhaps you should read some of the stories on The Old New Thing about the hoops MS jumps through to maintain compatibility. Here's one (of many). In that one, we find that MS changed the internal implementation of critical sections in Vista, but found that some programs were looking directly at the internals instead of using the API. So in order to not break those programs, MS made sure the value in the internal struct people were peeking at had the value those programs were expecting. Keep looking back through the archives and you'll find dozens of examples of MS doing crazy stuff just to keep programs working in newer versions of the OS. And with many Java apps being big and enterprisey, you can be sure that MS is going to do whatever it can to keep them from breaking on Windows 9^H10.

You've probably got a bunch of crapware running in the background or aren't taking into consideration that the committed amount of RAM also included paged virtual memory. Here are a few links that show the memory usage:

XP, Vista and 7 baselines
Usage with 512MB RAM
7 SP1 Compared to 8

from what I understand, the winsxs folder contains what appears to be lots of duplicate files, but are acutally hard-links to the same file. Doing a simple right-click -> properties on the winsxs folder and it shows 19 GB != the acutal space it's using. see here

On most current architectures a cache line is 64 bytes or a small multiple of 64 bytes, not 4K, and the CPU will almost always have a prefetcher that will try to optimize sequential accesses. Here is a pretty accessible rundown on some of the things a person can do very easily.

Do Android phones automatically update to the latest version? iPhones do not, as far as I am aware, and require the user to manually initiate the download and installation of the newest iOS firmware; this - of course - requires the user to be logged in already, at which point the data is accessible anyway.

In other words, it sounds like this proposed vulnerability involves you being on the other side of the airlock hatchway already.

Peter is an academic with exactly 0 successful programming languages to his name.

When Rob Pike, Bjarne Stroustrup, Andrei Alexandrescu, Niko Matsakis and others talk about languages and someone cites Scala as a fine example of a rudderless accretion of programming fads, no one objects. They giggle instead.

I'll take these guys over your programming philosopher every time.

I prefer the Windows 3.1 BSoD

Well, that's interesting, because TFA precisely talks about Ballmer designing the Windows 3.1 BSOD. The BSOD in the article looks different than your screenshot.

Most likely there are multiple BSODs in Windows 3.1, and Ballmer designed one of them.

Interestingly, Visual Studio got C99 library support [msdn.com] last year. I'm mentioning this because the C support in VS has mostly been a desert scene with tumbleweeds passing by. I'm not sure how close VS is to full C99 support and what pieces are possibly missing. Does anyone know?

Microsoft's VC++ team blog provides details on conformance to C99, C++11 and C++14 on a regular basis. Here's a recent one:

http://blogs.msdn.com/b/vcblog...

The TL;DR: their C99 support is complete except for tgmath.h (though they do have ctgmath from C++11). VS2013's printf is also missing some format specifiers though that has been resolved for VS "14". Apparently they had to rewrite their 1980s-era implementation of printf from scratch to get this finished...... not exactly a trivial job. A couple of other minor things are missing too.