Current (desktop-based) installers can only install desktop applications. AFAIK Windows will refuse to load Metro apps that aren't digitally signed by the app store.

This is nothing new, the same problem exists with any .NET service pack that was released in the past. Whenever a bug is fixed, people will start writing code that ends up breaking when encountering the bug on a machine without the fix. To avoid this issue, every .NET release (including minor service packs) would have to be side-by-side. Looking at the .NET releases + service packs, that means we'd be at .NET 13 right now. Users would likely need many .NET versions installed at the same time. Java has the same issues, and there, applications often come with their own private copy of the Java runtime to ensure the users have exactly the same version as the developers. In .NET 4.5, Microsoft has been quite aggressive with changes that are backwards but not forwards compatible, so I expect many more people will run into such issues now than before. But what else are they supposed to do? Are you suggesting that Microsoft shouldn't fix bugs? Or that we start shipping private .NET copies with each application? By the way, the same stuff can happen with the compiler. It's less bad than the runtime problems as you can control which compiler version your developers are using, but this can still bite you in your case where you're switching your development environment back to 4.0 due to such runtime issues... Consider this bit of C# code:

List<Action> list = new List<Action>();
foreach (int i in new int[] { 1, 2, 3 }) {
list.Add(delegate { Console.WriteLine(i); });
}
foreach (Action action in list) {
action();
}

If you compile this code on a machine with .NET 4.5 installed, it'll print "1, 2, 3", which is what most people would expect. But compiling on a machine with .NET 4.0 will print "3, 3, 3" due to a quirk in definition of the variable lifetime of foreach loop variables in C# 4.0. The quirk got fixed in C# 5.0 and it is a mostly backward compatible change (the old behavior wasn't useful, so almost nobody was writing code like this). But someone using C# 5.0 might write such code not realizing that he's depending on the new variable lifetime, and then when the project switches back to C# 4.0, the code will break in a subtle way.

'd3dx9_27.dll' isn't really part of DirectX 9.0c, it is a "DirectX extension library" that was released later. In fact there are lots different versions of d3dx9_*.dll that were released post-Direct 9.0c (and they're all side-by-side installs - if you have a later versions like d3dx9_42.dll already installed, you still need the old one for older games). The DirectX setup coming with Spore is probably a combined setup that installs DirectX 9 (if necessary) + the additional extension libraries.

No, that will fail to compile unless T and U are known to be related at compile-time. See §6.2.7 "Explicit conversions involving type parameters" in the C# specification for an explanation.

Code base size: 852 000 lines of code. "occured": 14 results (4 error messages, 10 comments) "occurred": 30 results "occurence": 13 results "occurrence": 58 results

How about using the good old StringWriter? No need to convert from text to bytes and back.

The smallest available blocks in IPv6 are 2^64 addresses. A personal permanent block for everyone is not possible; routers can't have individual routing table entries for every person on earth. Your block of IP addresses has to be within the block allocated to your ISP, you can't keep it when switching ISPs (unless your old ISP forwards the packets -> Mobile IP[^]). The packet size is limited by the MTU of the underlying link layer (1500 bytes for ethernet). The IPv4 header (IP + TCP) is at least 40 bytes (can be more due to the use of optional headers); IPv6 (with TCP) is at least 60 bytes. So yes, IPv6 packets carry slightly less data.

The current SharpDevelop 4.2 release is already ready for .NET 4.5 and async/await, just install .NET 4.5 and it'll appear in the target framework list. Yes I guess this might boost our user numbers a bit :) Though I'm not too hopeful that that will translate into increased contributions - Windows developers tend not to think about contributing :( Unfortunately the reduced Windows SDK will also screw us over in some aspects, e.g. the XML documentation files (documentation in IntelliSense) for the .NET 4.5 BCL are no longer available without Visual Studio (previously these were part of the .NET/Windows SDKs).

PIEBALDconsult wrote:

Basically, yes, but is that technically true? Can't you compile and run a program that doesn't link to and use any libraries? Certainly you can write a program that doesn't # include anything.

That depends. Built-in C language features may very well map to library functions - think embedded CPUs with a software floating point library. As soon as the language has more features, inevitably some of them will need a runtime library. For example the new operator in C++ will need a malloc implementation or similar. And then there's exceptions, dynamic_cast, ...

PIEBALDconsult wrote:

What I'm more concerned about is that the underlying structure (framework, virtual machine, whatever) needs to have a concept of System.IDisposable and System.IEnumerable in order to compile the language.

Why is that a concern, but string isn't? IDisposable and IEnumerable are trivial interfaces, strings and arrays are much more complex. There are actually quite a few types in .NET that are well-known to the compiler, many more than you think. decimal is just a struct, nothing special on MSIL level. And then there are at least these types that any C# compiler will need: * Type - for typeof() * Array - base class for arrays * Attribute - base class for attribute, required for the disambiguation rule in §17.2 * ValueType - base class for structs * Enum - base class for enums * Delegate - base class for delegates * Exception - base class for exceptions * IEnumerable and IEnumerator - for foreach * IEnumerable<T> and IEnumerator<T> - for yield return * IList<T> - interface implemented by arrays * IReadOnlyList<T> - interface implemented by arrays in .NET 4.5 * Task and Task<T> - for async/await * Nullable<T> - nullable operator lifting etc. * IDisposable - using statement Of course there are many more, e.g. attributes that have special effects (ParamsAttribute etc.), but those can be said to be specific to the .NET implementation of C#, they aren't necessary in general. Still, the abov

The VS 2010 express editions will stay available. However, you won't get C++11 support that way (except for the tiny portions already supported in VS 2010), so staying with 2010 certainly isn't a long-term option. Hopefully MS will reconsider after the Win8 release, when they realize that Metro isn't wanted (except on tablets). On the .NET side, VS express users won't be able to use async/await (except for Metro development). Fortunately SharpDevelop 4.2 already supports async/await[^] ;)

stephen.hazel wrote:

Honestly, stuff like this aaaaalmost makes me wanna give up on win32 and use linux.

I don't see Linux going anywhere on the desktop. But the number of Macs is going to increase dramatically if MS keeps screwing up.

It may not require a "framework" as extensive as the .NET framework, but C# (as any high-level language) certainly requires some form of runtime library. Even C needs a runtime library, the trick is to have the ability to statically link against only those portions used by your program. Unfortunately C# programs require bit of code - a good portion of the BCL (strings, arrays, etc.), the garbage collector, etc. Mono comes with an mkbundle tool that can create a native executable from managed code. Unfortunately the static linking option is not available for Windows.

Firefox says "This website is asking to store data on your computer for offline use". I think that's HTML5 local data, not cookies.

OriginalGriff wrote:

Control Panel, Administrative Tools, Computer Management, Storage, Disk Management, find the disk, right click, Delete Volume.

There's a UAC prompt when opening computer management, but the Win7 "tamed down" UAC suppresses that and just silently runs stuff with admin privileges if it's launched from the control panel. This tamed-down UAC is useless, malicious applications can easily exploit these holes to elevate without any prompt[^]. Either turn UAC on completely ("always notify") or turn it off completely, the default setting in between is useless.

The was a hidden registry setting in the Developer Preview, but that was removed in the Consumer Preview. At least for now, Metro is mandatory in Windows 8 - for desktop use, it replaces the start menu.

Even those can be shut down using the same hardware button that was used to turn them on - same as all other electronic devices. Sure, a shutdown button would be nice for desktop use. But Windows 8 clearly isn't designed for desktops. It's all about the consumer market and consumers are using laptops, netbooks and tablets.

JoeSox wrote:

it's like 3 to 4 clicks now to freakin shutdown... crazy.

Only for those few old-school users who still click the shutdown button. Most just close the lid of their notebook and it shuts down (or hibernates) automatically.

You realize that almost any use of a pointer in C outside the array bounds is an exploitable buffer overflow? Even dereferencing a null pointer can be exploitable in some rare cases. It's not just restricted to the simple stack buffers you might remember seeing - in fact those simple cases are difficult or impossible to exploit due to NX and stack cookies, and they're easily detected by static code analysis. But think about more complex code as occurs when parsing complex binary file/message formats; it's extremely hard to test for all possible invalid kinds of input. You rarely have a chance of finding this type of bug without writing a protocol-specific fuzzer. And don't forget that C / C++ have tons of undefined behavior that attackers can exploit. For examples, the standard allows compilers to assume that no overflows happen with signed integers and pointer, and some C compilers have been seen optimizing away security checks because they were "always false" (except for the cases with the integer overflow, which the compiler is allowed to ignore). http://blogs.msdn.com/b/david_leblanc/archive/2008/04/04/evil-compiler-tricks-and-checking-for-pointer-math.aspx[^] I don't think we'll see a reduction in the number of security issues until the industry switches to a safer language. (this isn't a Microsoft-specific problem)

Spoofed IPs can't complete the TCP three-way-handshake to establish a connection; so they can be only used with UDP (or for good old SYN floods).

rmdir /s removes a folder and all files within it. If you have a too-small SSD, you might want to use symlinks to move folders to a harddrive. This way you can install programs to the fast SSD and move them later (when you discover you don't use them much) to the hard drive without having to uninstall. For example, if you are a C# developer, you could move the huge C++ portion of Visual Studio (1.1 GB) to the HDD while keeping the all other parts of VS on the SSD:

mklink /D "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC" "d:\MovedFromSSD\VS10VC"

BobJanova wrote:

Well, if not, it is obviously possible to invent a language where one symbol does this operation

Why one symbol? If you're inventing a new language, you might as well invent one where the empty program solves this challenge.