Date parsed: 28/12/2007 01:53:20
Date: Fri, 28 Dec 2007 06:53:20 -0500
"Chris Shepherd" <chsh@nospam.chsh.ca> wrote in message
news:eHe04rMSIHA.748@TK2MSFTNGP04.phx.gbl...
> jim wrote:
>>> 2, You don't need to install all those versions of the framework. If a
>>> user has any kind of recent OS installation (XP SP2 or higher) they
>>> already have a framework installed.
>>
>> Really? When did that start? I am not aware of the framework being
>> installed as a security update or as a part of SP2? That's been one of
>> my pet peeves - why wasn't it?
>
> I must be mistaken about XP, but I know Vista has the framework installed.
But it has an old version of the .Net framework and Vista still does not
automatically install newer versions of the .NEt framework as they are
released. Same problem, different version.
>>> At most you need 2.0/3.0/3.5.
>>
>> Unless you or your company wrote 1.0 or 1.1 apps.
Most users ( I am talking about users in general, not users in a rigid
corporate environment) will want to use applications regardless of the .Net
framework version. That means that users that want the capability to run
any app written for their version of Windows will need to have every version
of the .Net framework installed.
To my knowledge, there is 1.0, 1.1, 2.0, 3.0 and 3.5. That's just over 1.04
GB of uncompressed installations for the .Net framework (assuming a regular
uncompressed size of 208,625,088 bytes as was the case for installing .Net
2.0 on my VM).
> Yes, then you only need 1.0/1.1.
>
>>> It's only problematic in not up to date OSes, and if you are targeting
>>> old PCs you probably shouldn't be writing stuff in .NET anyway.
>>
>> Sound logic.....people with older PCs should just get the hell off the
>> internet. I like that! (But I wonder what they would think about it.
>> Hmmmm.... )
>
> What I said and your response are vastly different. I simply suggested you
> should use a different language for development if your target environment
> has little to no support for recent updates/the .NET framework. My onus
> was on the developer, not on the user.
I was being sarcastic - sorry. You are right. The onus is on the
developer.
>>> 4, Installing an application does not require administrator privileges
>>> in any way. Installing an application which needs to access certain
>>> parts of the filesystem or registry may require installation privileges,
>>> which are available to Power Users.
>>
>> Most useful applications write some data to the registry and do
>> manipulate files (although not necc system files). I have rarely found
>> programs useful that are so simple as to not use the system registry or
>> manipulate files on my systems.
>
> Note the *certain parts* in the point you replied to. Anyone can write
> files to the system, there's a specific spot for it for each user in fact.
> It's more *where* you can write files to that are controlled by security.
I suppose I am looking at things from the viewpoint that a user simply want
to use the program that s/he wants to use. They don't care (or even know)
about security issues. If they are challenged with a security dialog, they
will just keep hitting "yes" until they get what they want (which, btw, is
why Vista's UAC is a miserble failure).
As a hobbyist coder, I wnt to code apps that are on par with the system and
environment of my users (the general PC-using public) and to make using my
apps as smooth and seemless as possible. That does not include talking them
through how to get around security restrictions when a simple product like
Thinstall makes security a moot point (for 99.9% of users).
>>> Using this and #5 as a point *for* Thinstall and its ilk seems odd,
>>> since most commercial software nowadays installs.
>>
>> I guess that depends on your Windows permissions and network admin's anal
>> tension.
>
> Yes, but trying to get around restrictive administrative policies such as
> not installing software is probably a breach of the AUP of the
> organization you work for. Most AUPs I've read/written include copying
> files which do not alter the windows registry or install to a permanent
> location as "installation".
I'm not talking about using software at work that is restricted. Clearly
you should work when at work.
I am talking about being able to use your software anywhere you choose.
That mey be at home, at school, at an internet cafe, at your friend's
house - anywhere. Being able to simply run software without requiring a
true installation (where directories are created and registry entries that
will NEVER be removed are placed on the PC).
>>> 5, Yes, it may make running the software easy, but how trivial is
>>> updating the software, keeping track of (and securing) temporary data
>>> caches, etc., etc..?
>>
>> You don't work with the general public, do you?
>
> Which is exactly my point. This is why the majority of software comes in
> installable form and maintains itself by checking for updates.
Those installable apps are restrigcting themselves when dealing with the
general public by their very nature.
>>>> Actually it was smaller the last time we tested Thinstall. I will try
>>>> and test it again and get you Paint .Net to try for yourself.
>>> Smaller than what?
>>
>> Than Paint .Net + the .Net framework.
>
> Which wasn't even the discussion at hand. I'm not saying Paint.NET should
> be used as the basis for comparison, in fact, I have no idea how you came
> to that conclusion. What I'm saying is that I would like to see Paint.NET
> using Thinstall vs Paint.NET and the .NET framework.
What I was saying is that an executable of Paint .Net using Thinstall is
MUCH smaller than an installation of Paint .Net that requires the install of
the .Net framework.
>>>> As a simple test, we made a "hello world" windows form and compiled it
>>>> to 6MB. That beat the 24+MB download of the .Net framework alone.
>>> And what was the size of your hello world EXE plus the framework
>>> compressed into one file?
>>
>> Just over 24MB. (The .Net install is already compressed.)
>
> Then how does Thinstall manage to provide full framework functionality in
> 6MB?
It scans the .Net framework and only includes the functions that are called
for the particular application. Or, it did the last time I used it.
> Not only that, you're missing the obvious point that the 24MB framework
> download is just once, then there's just application updates. 24MB
> one-time vs 6MB every time there's any kind of update/new version? On some
> software that could be weekly. Plus, it's not a 1:1 like
> Xenocode/Thinstall are, since the framework can/will get used by other
> applications as well.
That is true. But, since the onus is on the developer as you have said, my
consideration is for my applicatio to be as seemless and worry free as
humanly possible. As the developer, I am not concerned with what other
applications use or must install on the users PC. My goal is an orgasmic
experience with my software...period.
And, I so not wish to limit my users from using my software from USB drives
either. Thinstall can wrap the 208+ MB .Net framework plus an app like
Paint .Net into a 47 MB executable that can be executed from almost anywhere
on any PC. (See
http://thinstall.com/demos/dnet20/ for this example.)
>> Now, I haven't tried to make a portable app in some time, but when I did,
>> they basically required you to change your app to fit into the portable
>> app scheme. Thinstall\Postbuild do not.
>
> Well, mostly not.
The current version of Thinstall that I have tried actually works this
way....
You design and
>
>>>> It isn't for everybody.....but I think it improves the distribution and
>>>> maintenance of .Net apps for most people.
>>> Distribution and ease of access, maybe, but I don't see how it improves
>>> maintenance at all.
>>
>> Streaming and replacing or updating single EXEs on a streaming server or
>> on each desktop is infinitely easier than running updates (or, God
>> forbid, uninstalls & re-installs) on each desktop.
>
> I don't see how [replacing one file] is "infinitely easier" than
> [replacing multiple files].
From the viewpoint of a hobbyist developer that develops for the internet
community as a whole, the fewer files that upi have to distribute the fewer
things there are to go wrong (i.e. be stomped on by an antivirus app or
anti-Xware app or accidentally deleted by a user or PC cleaning app, etc.).
>> I currently care for 18 small businesses and 300+ PC users, and I'll take
>> the short road every time, if the users get the same end result.
>
> If you care for all these users' PCs, can't you ensure their PCs have
> appropriate .NET framework versions?
Yes, I can. But I don;t write software for distribution to these PCs only.
I write for the general public. And, while my 300 users may be fat and
happy, I want 3,000,000+ users fat and happy - without having to administer
their PCs.
> If it's of use to you, power to you for being able to use something like
> this. I was not disputing that in any way, shape, or form. I'm simply
> suggesting not everyone believes the same, especially since there aren't
> many threads clamoring to have an all-in-one package like you're
> suggesting.
I agree. Its not for everybody. There are many developers that write for a
closed system (like a corporate environment) where they can control the
client machines to the nth degree.
But, for my needs in writing and distributing software to the masses, being
able to distribute a single executable and not worry about having a
framework installed or having some other app overwrite my DLL or ActiveX
component with a newer version is a God-send.
> Again, I think it has its place, but for me it wouldn't be anything more
> than a nifty feature I might use once or twice. Especially since the
> framework is on everyone I know's PC anyway.
Thanks so much for your thoughts on the subject.
jim
