A "download set" would be a named collection of MSDN Downloads which meet a common purpose.

e.g. "SharePoint Dev Box" (consisting of SharePoint, SQL Server, Visual Studio).

This would allow a page so that collaborative users can download specific versions (e.g. "SQL 2008 R2 SP1 CU4") of software that are required for specific builds.

Ideally you would be able to add comments or notes, as well as tags.

Bonus points if I can make my "download sets" public so I can share them with members of the community (and people can then rate or bookmark their "favourite" sets from MVPs and bloggers).

Here are my ideas for the Nokia Developer site in becoming ''a true Microsoft site'', 1) archive all old content, fora, and discussions into a new section called ''archives - Nokia'' for S30, S30+, S40, S40+, S60/Symbian, SmarterPhone OS (Mimiria), S70, S80, S90 (Hildon), Meamo, MeeGo, and MANY, ,MANY, MANY, MORE, Ertc. as well as Nokia Asha and Nokia X after Microsoft will officially cease their developer efforts (meanwhile they can be archived at http://msdn.microsoft.com/nokiaasha, and http://msdn.microsoft.com/nokiax, respectively), 2) create a separate Microsoft Lumia section http://msdn.microsoft.com/Lumia which will host the Nokia SensorCore SDK and the Nokia Imaging SDK until Microsoft will make them compatible with Windows Phone in general when they'll be avaiable from Dev.windows.com, 3) keep DVLUP and make it http://msdn.microsoft.com/dvlup and ALL other Nokia interactive sites for developers to continue the trusted brands, and expand it from Windows Phone to PC Windows, and add it to dev.windows.com as well. 4) archive the SDK's and make them available for download from Microsoft Downloads for those still interested in supporting unsupported Nokia/Microsoft Mobile Oy operating systems (much like how one can still download the Windows Mobile Emulator from Microsoft Downloads, or Zune software), and finally 5) rename the ''Nokia Developer'' publisher in the Windows Phone Store to the ''Microsoft Developer'' and let users on non-Nokia Windows Phone download its applications too in prepation for releasing the Microsoft SensorCore and Microsoft Mobile Imaging SDK's for non-Lumia Windows Phones.

I think that making the introductory signup fee so high as a means of minimizing the amount of non knowledge having developers is not the correct way to have the system set up. I feel that most of the greatest ideas to ever pass by anyone important first was past from a nobody.

There should at least be a way for the average joe or everyday pc used to implement their ideas without having to get a degree or have schooling in that area. Why not make it easier to get the information from the little man directly to the developers?

Does Microsoft can improve the documentation page of Microsoft Extensions to C and C++?
http://msdn.microsoft.com/en-us/library/34h23df8.aspx

It would be nice to list all the behavior differences between /Ze and /Za options. For example, I have the following source code that reveals two differences that seem not to be documented:

struct A
{
operator int () const
{ return 0; }
};

struct B
{
B (A)
{ }

private:
B (const B&)
{ }
};

struct C
{
C (int)
{ }
};

int main(int argc, char** argv)
{
A a;
B b1 (a);
C c1 (a);

B b2 = a;
C c2 = a;

return 0;
}

The program compiles fine with /Ze but not with /Za. The following lines don't compile for a different behaviour in the copy elision:
B b2 = a;
C c2 = a;

First line, the standard says that you can do the copy elision of B only if B has a public copy constructor. With /Ze, I guess the copy elision is done even if the copy contructor is not public.

For the second line, the standard says that you cannot convert a type to another type with two implicit conversions. Here this is the case: A converted to int and int converted to C. With /Ze, I guess the complier doesn't take into account the conversions.

It would be nice at least to document this difference of copy elision as it is a common difference between Microsoft Extensions and the other compilers. Developping code with this extension will not compile later with other compilers for the developpers that prefer 'type variable = x;' syntax intead of 'type variable (x);' syntax.