Proof that Windows is bloatware

[MachineCode]

Windows7UpgradeAdvisorSetup.exe = 8.26 MB, plus .NET Framework 2.0 = 22 MB. Okay.
So, I need to install 30.26 MB of software for Microsoft to tell me if my PC can run Windows 7.
This really makes you appreciate the small, tight executables that PureBasic creates. Really.

[Shield]

See it from the bright side...you can't run Windows 7 if you can't run .NET.

[netmaestro]

This really makes you appreciate the small, tight executables that PureBasic creates. Really.

Don't get me wrong, I agree with you. But to be fair you have to also consider the fact that Purebasic creates Windows executables and in doing so taps into many API's present in the operating system. To a large extent Windows is providing the functionality and PB is calling it. Many libs are built from the ground up to be sure, but by no means the whole product. That said, personally I hate .net too!

For example, I have a transparent clock program that I wrote some years back that compiles to 131k, images and all. But that clock uses gdiplus.dll from the OS and that's a 1.7mb dependency. So is my program tight and small or not? "Depends" on how you look at it.

[Shield]

Some of you guys should stop seeing .NET as some kind of tumor attached to Windows.
It isn't. .NET is an integral part of the Windows API since Vista and it brings so many unbelievable opportunities
to the developers that the advantages clearly outweigh those 30 MBs. Times change.

[MachineCode]

Shield, you're missing the entire point here, which is: .NET is not part of or integral with XP! So, I need to install 30 MB of stuff just to test if my PC can run Windows 7. Surely the people at Microsoft could have just written a small standalone native executable to do the test! Why the (false) reliance on .NET to do everything? It's rubbish and we all know it.

[Shield]

It's rubbish and we all know it.

It's probably the most advanced application environment out there and such systems are going to be the future.
But sure you can rely on years of experience using it to make such statements.

This is not a personal "attack" in any way...I'm just amazed for how many people out there this is such a big deal
to have to install 30MBs of additional data. I can't understand that but than again it isn't really my problem.

[MachineCode]

I know it's not a personal attack, so don't sweat it.

And no, I will NEVER install 30 MB of software just to run something for 1 minute to get a yes/no answer. Well, without using something like Sandboxie anyway.

As you can't understand my hesitation, I also cannot understand those that WOULD install 30 MB of stuff just for such a simple one-off task. To me, that's horrific! "Waste not, want not" and so on. But then again, I come from a VIC-20 coding environment, where every single byte counted.

[Inf0Byt3]

30 MB is not that much, but...

Why would I want to wrap the API in another layer and code in that layer when I can have direct access to anything I want in the OS? I never understood the actual purpose of .NET... What can you do with the help of .NET that you can't do by classic API calls?

[netmaestro]

.NET's raison d'etre doesn't have much to do with adding functionality as I understand it (which is admittedly not that well) but I think its design with the CLR is an attempt to provide an extra execution step during which malicious or potentially damaging code can be refused. Afaik this is why .net programs are called "managed" code. You are no longer programming hardware directly with .net, but submitting your code to a software runtime which will decide whether or not it is safe to run. It has always been my understanding that this is the main purpose of .net.

Stability and security are the goals and what makes it a hard sell in some circles is the natural aversion most programmers have to interpreted languages. These goals being paramount to the execs at Microsoft, I really believe that at some point down the road they will remove direct access to OS functions and the only way you'll code for Windows is through the CLR with dotnet.

[Shield]

Why would I want to wrap the API in another layer and code in that layer when I can have direct access to anything I want in the OS? I never understood the actual purpose of .NET... What can you do with the help of .NET that you can't do by classic API calls?

Why would you use PB functions if you can use WinAPI directly? Because they are easier to use and platform independent. It's exactly the same with .NET.
Using .NET classes and methods is way easier than using native API and due to the additional layer it also is platform independent (but obviously more bound to Windows systems).

[MachineCode]

Why would you use PB functions if you can use WinAPI directly?

If you mean: why would I use Sleep_() instead of Delay(), then the answer is: I do!
I'll always use an API call, when possible, instead of the PureBasic equivalent. I use:

GetTickCount_() instead of ElapsedMilliseconds().
GetAsyncKeyState_() instead of KeyboardPushed().
GetSystemMetrics_(#SM_CXSCREEN) instead of DesktopWidth().
#VK_LSHIFT instead of #PB_Key_LeftShift.

You get the picture. My source codes are half API and half PureBasic.

[Danilo]

Some of you just ignored all improvements over the last 10 years. You hate the new API's,
advancements in programming languages, newer Operating Systems.

You just don't get it, sorry. Just stay with your Win95 stuff. It is your own fault -
the world will continue to grow/expand/develop.

[Tenaja]

...I really believe that at some point down the road they will remove direct access to OS functions and the only way you'll code for Windows is through the CLR with dotnet.

Considering that Windows 8 is supposed to run on ARM and x86, this point in the road may occur next year...or, perhaps, be visible, at the least.

And no, I will NEVER install 30 MB of software just to run something for 1 minute to get a yes/no answer. Well, without using something like Sandboxie anyway.

As you can't understand my hesitation, I also cannot understand those that WOULD install 30 MB of stuff just for such a simple one-off task. To me, that's horrific! "Waste not, want not" and so on. But then again, I come from a VIC-20 coding environment, where every single byte counted.

If you view .NET as being required for a single application, you are being shortsighted. Seeing how Visual Studio is likely the most popular development environment in the world, your "one time use" aversion is causing you to lose out on numerous opportunities.

I actually learned on a computer that predated the VIC-20... it was difficult to get over the "conserve resources" attitude, but face it, MachineCode--we have "unlimited" resources in today's PC's when it comes to disk space and ram. I have counted more instructions than I care for, and remember vividly the day ram prices dropped to $45/MB, it was so exciting... but now I moan and install my own if the pc mfr wants to charge more than that per GB. Heck, Newegg has it listed as low as $13 for 2GB sticks! Squeezing every drop out of code for personal reasons is often a fun challenge, but certainly not viable for today's commercial market, unless you are trying to make a ground-breaking video game.

[buddymatkona]

Tenaja is right. It is time to change the mindset that we need to conserve desktop resources.
I have an XP system that I still like and never update but I also got a new WIN7 system for a project.

Now GBs of memory and TBs of disk space allow me to design any of my nonvideo projects as if space were unlimited.
The .NET 30 MB install would have me looking for a block of space on my XP but on the WIN7 system, it would be no more of a burden than an extra README.TXT file.
The old attitudes might still be useful for phone apps but for new desktops...think unlimited space.

[Inf0Byt3]

.NET's raison d'etre doesn't have much to do with adding functionality as I understand it (which is admittedly not that well) but I think its design with the CLR is an attempt to provide an extra execution step during which malicious or potentially damaging code can be refused. Afaik this is why .net programs are called "managed" code. You are no longer programming hardware directly with .net, but submitting your code to a software runtime which will decide whether or not it is safe to run. It has always been my understanding that this is the main purpose of .net.

I see... But speaking of security, isn't this the good old cat-and-mouse game? Of course, no one is saying that it won't make it harder to code malicious stuff, but the malware writers will eventually find ways to bypass all those measures.

Some of you just ignored all improvements over the last 10 years. You hate the new API's,
advancements in programming languages, newer Operating Systems.

You just don't get it, sorry. Just stay with your Win95 stuff. It is your own fault -
the world will continue to grow/expand/develop.

Regarding my statements about, .NET, I should add that personally I have no use for it. But not all programmers are the same (fortunately) and they don't write the same kind of programs. Some want speed, some want portability, etc. And saying that I don't like .NET doesn't mean that I don't respect others (that do like it and need it). Don't get me wrong, I like new stuff, but I only use what I need...