How widespread is .Net among home users?

  • Thread starter Thread starter Jim Hubbard
  • Start date Start date
There haven't been many mainstream user applications (except for some MS
server products & passport) that are built on .NET yet. I do suspect that
will change.

I think right now, .NET is very popular for corporate use.
 
Thanks Scott. Just trying to determine the best platform for my next
project.

Seems like MS would've made .Net EXEs DL only the needed portions from MS as
they are needed to avoid the whole 20MB Framework issue.

But, what do I know?

Jim
 
A basic winform app requires the following assemblies:
mscorlib, System, System.Xml, Accessibility,
System.Runtime.Serialization.Formatters.Soap, System.Drawing, and
System.Windows.Forms. That comes to about 6 meg uncompressed, probably
compresses down aroudn 2-4. Add ontop of that the mscoree.dll and all the
other required runtime dlls(the workstation garbage collector is over 2
megs, as is the server one), and I imagine your resultant package would be
about 10 meg. I don't think that it would be worth it to cut down to 10
megs, which is just as troubling as twenty, IMHO.
Now, if the app is written in VB or J#, additional libraries are *probably*
needed(is it possible to write a vb app that doesn't use anything from
Microsoft.VisualBasic? If you do so, will the vb compiler allow you to drop
the reference?).
 
Daniel O'Connell said:
A basic winform app requires the following assemblies:
mscorlib, System, System.Xml, Accessibility,
System.Runtime.Serialization.Formatters.Soap, System.Drawing, and
System.Windows.Forms. That comes to about 6 meg uncompressed, probably
compresses down aroudn 2-4. Add ontop of that the mscoree.dll and all the
other required runtime dlls(the workstation garbage collector is over 2
megs, as is the server one), and I imagine your resultant package would be
about 10 meg. I don't think that it would be worth it to cut down to 10
megs, which is just as troubling as twenty, IMHO.

I agree completely....

I use Thinstall to pack my .Net EXEs, but they are still 4-7MB in size.
(Good point is that it makes your code even harder to steal than using an
obfuscator - but if you use an obfuscator *with* Thinstall it makes the code
theft *extremely* unlikely).

What I really need to do is learn C++ and write smaller apps using the MFC.
..Net will be great once the runtime is installed on all Win Pcs. Until then
(1-2 years in the future), who really wants to DL a 20MB file over a modem
connection to run an application? Not me.

What's needed is a really kick-ass application - that people are willing to
go to almost any lengths to get - written in .Net. Maybe file-sharing with
integrated, cross-platform messaging (like a Jabber client) that allows 3rd
party extentions or a really cool implementation of a browser (like Avant
Browser) in .Net or even a spam eliminator for FREE in .Net. (Remember how
3rd party controls really blasted VB out front - along with ease of use - ?
Do that with an app that a lot of people will want to own.)

Then people will be more likely to DL the 20MB .Net framework. (For modem
users you may need to provide a "resume download" thingy to make sure they
get it all.)

Heck! You could just gather a list of all of the FREE .Net applications
known to exist and list them (with links) on a website dedicated to .Net
computing and send out the email to a few friends and ask them to pass it
on - a "Look What You Can Do With .Net!!" kinda site that will make people
want to click the .Net framework link and get some of those FREE .Net apps.

MS really is blowing getting this .Net framework out. Sure businesses use
it, but home users have to use it if it is going to live up to the MS hype -
or if it is going to go mainstream with 3rd party developers.
Now, if the app is written in VB or J#, additional libraries are *probably*
needed(is it possible to write a vb app that doesn't use anything from
Microsoft.VisualBasic? If you do so, will the vb compiler allow you to drop
the reference?).

Hmmmm.....not sure.
 
I don't have much to add to the other posts except that more and more users
are installing SP1 for XP which contains the .Net framework so even without
realising it themselfes I think a lot of home users already have it.

Yves
 
Hi Jim,

When in next version (or current selling versions) the Net is a standard
part, you do not have to add it, you get it back as free space using it, in
oposite to systems where you have to add a smaller runtime.

Just a thought,

Cor
 
¤ There haven't been many mainstream user applications (except for some MS
¤ server products & passport) that are built on .NET yet. I do suspect that
¤ will change.
¤
¤ I think right now, .NET is very popular for corporate use.

Not very. The latest version of Symantec's PowerQuest DriveImage uses it but I'm not aware of
another commercial application.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)
 
Have you forgotten, that any Windows XP system that has been keeping up with
its updates already has the .NET Framework on it?

In future versions of Windows, .NET will be "baked in" and Automatic Updates
will be turned on from the start. Users won't need to download anything.

Scott M.
 
No, I haven't forgotten. In fact, I specifically remember the .Net
Framework 1.1 showing up in Windows Update. However, It was not a critical
update, and as such would not be downloaded automatically and installed by
the Windows update service.

Why don't non-critical updates get installed automatically like the critical
updates? Who knows?

It is nice that future editions will have .Net baked in, but (as MS is
finding out) not everyone (around 50% of current Windows systems) upgrades
to the newest system. People will only upgrade when it makes financial
sense to do so. MS has failed miserably at making their OS affordable to
most home users - so they will not upgrade.

Besides financial, there's the migration headache. Some stuff may not work
anymore. People have been stung by this little problem before and resist
changing their systems because of it. They need some radically neat toys or
tools to make them want to migrate. Re-hashing the same old stuff just
won't do it.

Then, there is the universal resistance to change that all humans share.
People get comfortable with an OS and they don't want their world turned
upside down. They don't want to learn a new OS (unless they are in IT or
are just geeky) - so why does MS move the menus around and rename the same
old services to something unfamiliar?

Beats me. Maybe MS should invest in a little book entitled "Don't Make Me
Think" by Steve Krug. It's an easy read in an afternoon, and they may just
re-learn something it seems they have forgotten. i.e. Dumb it down and keep
it simple.

Want to make a killer OS (as far as income from sales and platform
distribution is concerned)? Lower the price. Or integrate the ability to
play Xbox games into the OS (after all the Xbox itself is a loss leader -
the real money is in the games). BAM! It's in every home in the free
world!

Then......what do I know?

Jim
 
I think most companies are worried about their software's safety from
hacking and theft of company secrets when using .Net. I know I am.

It is great for a server application - which is how MS intends to use it to
control software licensing. But for non-internet applications.....well, it
sucks.

What was the reason for .Net anyway? What major problems (besides DLL
HELL - which they created by sharing components when drive space was at a
premium) does .Net solve? For my money, it has created more problems for
the companies that write software.

This is only a problem when you realize that the software companies create
software for your OS that creates a desire for people to purchase your OS to
use the software. If the software manufacturers are not making money like
they need to, they don't write as much software and there are fewer reasons
to upgrade to the new OS.

..Net was made to make Microsoft's job easier. IMHO, it is a very
short-sighted move that will not be corrected without significant financial
loss to Microsoft and the software industry as a whole.

Jim

 
Ah yes, but Windows XP SP 1 included the .NET Framework 1.0 and that was a
critcal update, so that's why the 1.1 wasn't considered critical.
 
What was the reason for .Net anyway? What major problems (besides DLL
HELL - which they created by sharing components when drive space was at a
premium) does .Net solve? For my money, it has created more problems for
the companies that write software.

Oh Jim, you haven't really immersed yourself in .NET yet then.

Benefits Over COM:
No registration necessary.
This means no DLL Hell (as you pointed out).
It also means no stopping a web server to update a dll either
(since a registry change would always need to be accompanied by a reboot).

Better Cross-Language Development:
Since all .NET languages must adhere to the Common Type System (CTS), it
is MUCH simpler to pass values between code written in different .NET
languages.

"Thinner" Applications
The CLR takes over many of the basic functionality that we used to write
directly into our applications (garbage collection/memeory management,
security, etc.).
This means that the applications we build with .NET can be "thinner".
The down side here is the size of the Framework, but with a web app. there
are no deployment issues.

HUGE set of classes - UNIFORM interfaces
So much can now be accomplished with the classes in the Framework, that
going to the Windows API is rarely needed.
Also, if I learn how a specific class works in one language, I know how
it works in all of them.

ASP.NET
Completely new server-side architecture which allows for a rich set of
controls to be used in web pages and programmed (with events) server side.
COMPILED CODE rather than the interpreted VBScript/JavaScript = Much
more scalable and robust.
Separation of code from content with Code Behind pages.

Ok, these are still but a few. I'll agree that there is a learning curve,
but I think the .NET solves much more problems than it creates and opens up
possibilities that didn't exist before it.

This is only a problem when you realize that the software companies create
software for your OS that creates a desire for people to purchase your OS to
use the software. If the software manufacturers are not making money like
they need to, they don't write as much software and there are fewer reasons
to upgrade to the new OS.

.Net was made to make Microsoft's job easier. IMHO, it is a very
short-sighted move that will not be corrected without significant financial
loss to Microsoft and the software industry as a whole.

Jim
 
Jim Hubbard said:
I think most companies are worried about their software's safety from
hacking and theft of company secrets when using .Net. I know I am.

It is great for a server application - which is how MS intends to use it to
control software licensing. But for non-internet applications.....well, it
sucks.

What was the reason for .Net anyway? What major problems (besides DLL
HELL - which they created by sharing components when drive space was at a
premium) does .Net solve? For my money, it has created more problems for
the companies that write software.

DLL Hell wouldn't be a problem if new DLLs actually tended to solve
more problems than they introduce. Linux has .so-Hell and Java has
CLASSPATH Hell, so there's no easy escape by switching platforms.
However, if you want to continue developing for Winblows, you have
no choice, since the CLR appears to be /the/ native API for future
versions of Winblows, and Win32 will be a second-class citizen at
best.

All your code-base are belong to Bill.

Resistance is futile.
 
Jim Hubbard said:
I think most companies are worried about their software's safety from
hacking and theft of company secrets when using .Net. I know I am.

Well, you need to learn a bit. I've known crackers that can read X86
assembly like C++ code. Its not really that much protection either. As soon
as you let ANY code out of your company, chances are it is going to be
stolen. Even if its in native code, it won't last long, I mean, people even
crack and steal playstation, etc games. Don't get lulled into thinking that
simply using native code is any safer, it isn't. Most big cd protection
schemes(like safedisc, etc) can be removed using tools, doesn't even require
a user to do anything. For playstation, I spoke with one cracker who
described the tool they used(it was written in vb6). It basically scanned
for certain hexadecimal patterns that corresponded to specific known
protection instruction sequences. One run would identifiy all the protection
in the majority of games. I'm sure things like hardware dongle emulator
skeletons exist as well. Its amazing how far people will go to steal
something, but people do it. All you can do is make it harder for the
average user just to copy it to a friends computer. But to do that without
making the app hard to use is next to impossible.
When it comes down to it, if your app isn't stolen it probably means no one
wants it, not that your protection scheme is great.

Beyond that, as far as technique goes. I'm sorry, once you ship your app you
have already given it away. There are plenty of people out therethat don't
need your source code to understand how things work, just watching it work
is enough to form the framework in their minds to copy it. Pretty much any
programmer should be able to, its what makes us capable of doing our jobs,
being able to find a way to do something from what it does, not how it does
it.
It is great for a server application - which is how MS intends to use it to
control software licensing. But for non-internet applications.....well, it
sucks.

What was the reason for .Net anyway? What major problems (besides DLL
HELL - which they created by sharing components when drive space was at a
premium) does .Net solve? For my money, it has created more problems for
the companies that write software.

This is only a problem when you realize that the software companies create
software for your OS that creates a desire for people to purchase your OS to
use the software. If the software manufacturers are not making money like
they need to, they don't write as much software and there are fewer reasons
to upgrade to the new OS.

.Net was made to make Microsoft's job easier. IMHO, it is a very
short-sighted move that will not be corrected without significant financial
loss to Microsoft and the software industry as a whole.

Jim
 
Scott M. said:
Oh Jim, you haven't really immersed yourself in .NET yet then.

I haven't drowned in it......however I have a library of 53 .Net books
(mostly ASP.Net and VB.Net with a couple on C#), and I have implemented .Net
as a development platform at Innotrac and started the process at ConAgra's
Poultry headquarters in Duluth, GA (since sold to Pilgrims' Pride) and I
developed the first 3rd part .Net application for Qwest Communications (user
base was over 2,000 and growing when I left the project).

I don't consider myself a guru of .Net by any means, but I believe I
understand the relationship of business and code bases fairly well.
Benefits Over COM:
No registration necessary.
This means no DLL Hell (as you pointed out).
It also means no stopping a web server to update a dll either
(since a registry change would always need to be accompanied by a reboot).

I never had a problem with this. We cycled our clustered servers to
avoid any down-time. When the server was not clustered, we took the backup
machine (as everybody has....right?) and upgraded it, re-routing traffic to
the new machine's IP to avoid down-time in that situation. However, I am
sure that this capability will come in handy. It certainly is easier than
the previous solutions.
Better Cross-Language Development:
Since all .NET languages must adhere to the Common Type System (CTS), it
is MUCH simpler to pass values between code written in different .NET
languages.

True. But, again, this was never an issue on my teams.
"Thinner" Applications
The CLR takes over many of the basic functionality that we used to write
directly into our applications (garbage collection/memeory management,
security, etc.).
This means that the applications we build with .NET can be "thinner".
The down side here is the size of the Framework, but with a web app. there
are no deployment issues.

I love the idea if a smaller EXE. But, the problem as I see it is
getting people to adopt the new framework and install it. That shouldn't be
required for users. It should (as it is in Installshield) be automatic for
them. The only problem is when the user is still on a 56k modem and an AOL
account - they'd be better off ordering a CD.
HUGE set of classes - UNIFORM interfaces
So much can now be accomplished with the classes in the Framework, that
going to the Windows API is rarely needed.

You're right. Less coding. But, most API's have already been wrapped
in classes. Just take a look at the available components and code on the
web.
Also, if I learn how a specific class works in one language, I know how
it works in all of them.

The idea that a programmer should be well-versed in multiple languages
means that s/he will be great in none of them. It seems to me that the
*real* reason behind a common code base is to reduce the work required by MS
support teams. Remember, MS is controlled by shareholders....not
programmers.....not Bill......not anybody with an iota of knowledge about
what it really takes to succeed financially from a software vendor
standpoint (other than that of Microsoft).
ASP.NET
Completely new server-side architecture which allows for a rich set of
controls to be used in web pages and programmed (with events) server side.
COMPILED CODE rather than the interpreted VBScript/JavaScript = Much
more scalable and robust.
Separation of code from content with Code Behind pages.

This was a big improvement. However, the web pages still suck when
compared to coding a desktop application. Fortunately, you can write
desktop apps now and run them from your website to keep all users on the
most current release. Of course, they screwed that up too by restricting
the .Net framework when code is run from a web page.

Yeah....I know......security. They could make the .Net administration a
little easier for home users to administer. Besides, users will continue to
DL and install all kinds of crap and mischeivious code (even in .Net)
regardless of the "safety" features of .Net. These so-calles safety
features only make it more difficult to write code that runs from a server.
Ok, these are still but a few. I'll agree that there is a learning curve,
but I think the .NET solves much more problems than it creates and opens up
possibilities that didn't exist before it.

I have to disagree. The goal is not to write software. The goal is to
make money. Unless you are a newbie to programming or an Open-Source
proponent or independently wealthy you probably write code for a living.

Making the code base less secure makes programming less profitable.
Sure, I know, you can crack anything and copy the functionality of anything
if you are a good coder. But, there's no need in making it as easy as
running a MS-supplied decompiler. The easier it gets to crack the code, the
less money you make. The more complex it is to write code, the fewer people
you have putting out software....the fewer reasons there are to upgrade to
your OS....the more expensive the available software will become.....the
more attractive alternative OS's become.

If you have savy customers with always-on internet or your application
is meant to be used with an internet connection, .Net does make it easier to
secure your code by placing some of its functionality on a central server.
Thinstall does this. The only draw-back is the internet connection. If I
don't have one, I can't use Thinstall without buying a $395 dongle. This
may make some customers look for an easier to use (if not less expensive)
solution.

Don't be fooled. .Net was written for Microsoft's benefit, not yours or
mine. It just wasn't well thought out. Like removing the ability to change
code while it was running in VB (which MS is attempting to bring back in the
next VB.Net release). End users (non-technical end users especially) were
not consulted in any numbers (if at all). And, they definitely weren't
listened to.

Just look at the legions of VB programmers.... They, for the most part,
are just end users. They want a simple way to do some programming to
accomplish their goals. They did NOT want to re-learn programming from the
ground up. They did NOT want to be C/C++ programmers (or they would've
studied that). They did NOT want .Fred. For the most part, they loved
Visual Basic and wanted to keep it.

But MS didn't ask them. Because the move to .Net was NOT about the
customer.....it was about Microsoft. As evidenced by the uproar over
VB.Net, Visual Basic programmers felt betrayed.

Did they feel betrayed because they got what they asked for? No. They
got what MS wanted. .Net is a reaction to JAVA and an effort at moving
Microsoft's "software-as-a-service" model forward.

Regardless of my personal feelings about the abandonment of the Visual
Basic programmers, you are stuck with .Net if you want to continue down the
MS path.

And, I wonder why some Linux company doesn't take this opportunity to go
for the MS jugular. Now would be a perfect time to come out with an
easy-to-use programming language modeled on Visual Basic 6 (with the ability
to design 3rd party components and add-ins) and include it with Linux.

VB.Net has left a huge hole for non-programmers who want to write simple
applications. Add to that the expense of the MS OS vs Linux, and you have
an opportunity to lead Linux forward based on cost (non-programmers work
cheaper and the OS is cheaper) and ease of use - dumb it down!

But, this won't happen. The failure of Linux is that it is run by
techies. They can't seem to grasp the concept of simple software. Until
they do, Linux will not be an acceptable alternative for the masses. (Hint:
Read "Don't Make Me Think" by Steve Krug) If they made a programming
language for non-programmers (like Visual basic got its start) they'd soon
have legions of developers and would gain significant ground on the desktop.

Enough of my ranting.......got to go finish my new installation of .Net
2003.

Jim
 
Sure anything can be hacked. But, you shouldn't be making it easier to
hack. The easier it is, the more hackers there will be, the less money
software will make.

Jim


Daniel O'Connell said:
Jim Hubbard said:
I think most companies are worried about their software's safety from
hacking and theft of company secrets when using .Net. I know I am.

Well, you need to learn a bit. I've known crackers that can read X86
assembly like C++ code. Its not really that much protection either. As soon
as you let ANY code out of your company, chances are it is going to be
stolen. Even if its in native code, it won't last long, I mean, people even
crack and steal playstation, etc games. Don't get lulled into thinking that
simply using native code is any safer, it isn't. Most big cd protection
schemes(like safedisc, etc) can be removed using tools, doesn't even require
a user to do anything. For playstation, I spoke with one cracker who
described the tool they used(it was written in vb6). It basically scanned
for certain hexadecimal patterns that corresponded to specific known
protection instruction sequences. One run would identifiy all the protection
in the majority of games. I'm sure things like hardware dongle emulator
skeletons exist as well. Its amazing how far people will go to steal
something, but people do it. All you can do is make it harder for the
average user just to copy it to a friends computer. But to do that without
making the app hard to use is next to impossible.
When it comes down to it, if your app isn't stolen it probably means no one
wants it, not that your protection scheme is great.

Beyond that, as far as technique goes. I'm sorry, once you ship your app you
have already given it away. There are plenty of people out therethat don't
need your source code to understand how things work, just watching it work
is enough to form the framework in their minds to copy it. Pretty much any
programmer should be able to, its what makes us capable of doing our jobs,
being able to find a way to do something from what it does, not how it does
it.

It is great for a server application - which is how MS intends to use it to
control software licensing. But for non-internet applications.....well, it
sucks.

What was the reason for .Net anyway? What major problems (besides DLL
HELL - which they created by sharing components when drive space was at a
premium) does .Net solve? For my money, it has created more problems for
the companies that write software.

This is only a problem when you realize that the software companies create
software for your OS that creates a desire for people to purchase your
OS
 
Scott M. said:
HUGE set of classes - UNIFORM interfaces
So much can now be accomplished with the classes in the Framework, that
going to the Windows API is rarely needed.
Also, if I learn how a specific class works in one language, I know how
it works in all of them.

I'm only a tinkerer in .NET at the moment, but the above factor is an
*enormous* positive for me. It's just so pleasurable to have that
vast and consistent framework there - I'm finding I'm saving a lot of
time and effort due to it.
 
Daniel O'Connell said:
Well, you need to learn a bit. I've known crackers that can read X86
assembly like C++ code. Its not really that much protection either.

Yep, I decided to not worry about this issue when I once watched what
a friend could do with a good disassembler. You're fooling yourself
if you think native code is any safer from a determined hacker than
IL.
 
Back
Top