Stand Alone EXE

[Jim Hubbard]

How does Thinstall help here? While Thinstall is available for Windows
95, I doubt that it magically lets you run .NET 1.1 applications on
Windows 95, for example. (If it *does* effectively change your
operating system capability, I'm even more worried about the
compatibility with the real framework.)

It does run on Win95A+. It does so by basically creating a virtual machine
that your original exe and dependencies run in. Since your application is
running in a virtual machine (with a virtual registry) you actually don't
alter the core OS at all.

Being worried about a new technlogy is the sign of a good developer. Only
sloppy developers aren;t concerned that a new technology will break their
code. Overcoming this concern can only be done by trying Thinstall
yourself.

That cuts out your financial argument too, as far as I can see - and
I'd suggest that the cost of using Thinstall (e.g. the double testing
that I mentioned before) is going to have to be passed on to the users
at some point...

As a professional developer, you need to test your Thinstall apps on all
supported OSs. But, you'd have to do that anyway - even without Thinstall.

Thinstall is (in essence) a distribution application, much like an
installer - except that Thinstall minimizes the changes to a user' system,
allows a much wider distribution of your application and protects your
application in ways that common distribution avenues cannot.

Thinstall is not for everyone. It makes more sense for the professional
developer of a widely distributed (sold) application and for desktop
development and distribution inside large companies that wish to make sure
that newer applications do not have a negative impact on their current
applications.

In the later instance, Thinstall actually saves time. You know it won;t
break what's already on the user's PC, so testing compliancy with other
applications is eliminated.

Like I said, Thinstall is not for everyone. But, professional developers
will see the value of Thinstall very quickly.

Jim Hubbard

 

[Jim Hubbard]

Actually, I'd argue that if you're running your development in a way
that always *requires* immediate support answers, you aren't leaving
nearly enough contingency time.

I'd agree. But, who (in the real world of business programming) is given
enough time to do the job right most of the time? In my experience with
large companies - most of the time you are pushed to speed development time
at the expense of quality. This is why most software has bugs that may
never be fixed.

There will always be potential for
problems which require significant investigation, so assuming that such
problems won't happen to you is a recipe for disaster. Do you think JIT
always, always, always have the answer for every single customer
question immediately? I'd be amazed if that were the case.

In fact, they don't. I have seen a time or two where they have taken a day
or even 2 to answer with an update to Thinstall to provide new functionality
or to change the way Thinstall works to be more in line with the way
developers think.

But, I have never called them and not had my question answered immediately.

Like others, I don't see why there can't be different pricing
structures - the "support at your beck and call" price for those who
need it, and the "I'm capable of reading a manual, and I'm patient when
I have a problem" price for those on a tighter budget. The cost would
still be pretty high on the testing side IMO (unless you're willing to
hit all your customers who *do* have .NET already installed with a
larger download), but I'm sure it would encourage others.

I agree. A tiered approach to pricing would be nice if it were made plain
what the customers were getting for their level of support. And, they
already have a forum for user to share with each other on the site.

Tiered is good for customers, but it can create headaches for supplying
support. Customer calls tend to fluctuate. They are not an even flow of
calls. So, you either have to have enough support reps to take all calls in
a timely manner (which means a great number of them may be sitting around
doing nothing for most of some days) or you have customers upset at being on
hold for a more tan 10 minutes or so.

Balancing customer needs with the needs of the business can be difficult.
But, so far, I am well pleased with the level of support that I recieve
under the current pricing structure.

Jim Hubbard

 

[Jim Hubbard]

Updates to .NET have distinct version numbers (already 1.0 vs. 1.1) and
software is tied to a specific one; you can have both installed on the
same machine. Ending "DLL Hell" was a specific goal of .NET.

I'd like to speak directly to the issue of "DLL Hell".

"DLL Hell" was only an issue for the developers that followed incorrect,
outdated programming practices advocated by Microsoft. Microsoft had long
promoted the use of "shared DLLs". This practice started when hard disk
space was a big expense as a way to maximize the investment in hardware and
to get more use out of limited hard disk space.

Had Microsoft told developers that the simple way to eliminate this "DLL
Hell" was simply to place the DLLs needed by their applications in the same
directory as their executables, the whole "DLL Hell" myth would have died a
quick and painless death.

Instead, we get handed the "DLL Hell" mis-information as one reason an
ENTIRELY NEW LANGUAGE is needed.

This was outright deception on the part of Microsoft and the ignorance of
supposed expert programmers that wrote many deceiving articles about the
supposed tragedy of something that only existed in software shops that did
not understand how a win32 executables actually worked.

Now, we have a real problem that reallocation of the program resources (i.e.
..Net framework) cannot as easily fix. It's "Fix Hell" and it's real.

With "Fix Hell", Microsoft issues a "fix" for a problem with .Net (only if
you spend 20 to 30 minutes per fix to call them and request the "fix").
"Fixes" are small patches that change the behavior of the .Net framework or
IDE on which the Microsoft "fix" is installed.

If you install the "fix" your .Net framework is no longer the same as your
potential market. In other words, it won't work for others that have not
downloaded the "fix".

If a user installs a "fix" (via a call to Microsoft, another developer's
setup or on his/her own) that "fix" may break your programs that rely on the
same .Net framework version but were designed without the "fix".

If you install the "fix" on another's PC, you may break the functionality of
other vendor's applications that use the same version of .Net that your app
uses and for which the "fix" was applied.

With Thinstall, the "Fix Hell" goes away. Your Thinstall executable
contains all of the .Net framework (with or without fixes) that your
application needs, and no "fixes" installed on the users' PCs will alter the
performance of your Thinstall application.

To put it bluntly......Thinstall is the only way to mass-market software in
the .Net platform and be 100% sure that a "fix" will not screw up your
application and increase your customer service calls.

Please read the blog at
http://weblogs.asp.net/fbouma/archive/2004/03/13/89021.aspx for another view
on this "fix" situation.

Jim Hubbard

 

[Jim Hubbard]

Just Google the web and newsgroups for "problems installing .net framework"
and you'll see quite a few examples.

My examples are from experience and other software support teams.

 

[Jim Hubbard]

Is Delphi planning on continuing as is or is it going to be sucked into the
..Net vacuum as well?

 

[Jim Hubbard]

Either that or some of us smart guys can develop our own single package
installer and undercut the competition.

If anyone is thinking about competing, may I suggest doing so on Linux.

If we had a truly RAD development tool (like VB - dumbed down, quick
development- lots of drag and drop functionality using 3rd part components)
on Linux and a tool like Thinstall, we wouldn't have to put up with the
Microsoft forced marches anymore.

I'm not at all against new developments in programming. Without them, we
never would have had classic VB.

But, any new languages should make sense, they should solve more problems
than they create, they should simplify development instead of making it more
complex and they should expand the base of programmers not contract it.
..Net fails on every one of these aspects.

If there was a VB-like tool that worked on Linux, I'd love to try it out.
The only problem with Linux is the GPL. I completely agree with an open API
structure, but the open source thing has simply resulted in hundreds of
Linux distros that are just different enough to make programming more
complex.

Even Microsoft doesn't need to open the source code. But, they should
document ALL APIs for the Windows OS and programming frameworks. This alone
would put everyone on equal footing and keeping the source code private
would prevent the OS fragmentation that Linux has created for itself.

JAVA is dangerously close to making this open source mistake. If it does,
it will fragment too. And, the very thing that Sun sued Microsoft for doing
(adding it's own Windows hooks to the JAVA environment) will become the
norm.

Jim Hubbard

 

[Jim Hubbard]

Is Delphi planning on continuing as is or is it going to be sucked into
the .Net vacuum as well?

Nevermind........they're circling the drain.net as well.

Jim Hubbard

 

[Jon Skeet [C# MVP]]

It does run on Win95A+. It does so by basically creating a virtual machine
that your original exe and dependencies run in. Since your application is
running in a virtual machine (with a virtual registry) you actually don't
alter the core OS at all.

But .NET 1.1 requires things that W95A doesn't provide - otherwise MS
would have made it run there. If Thinstall is shipping the libraries
from other OSes in order to run, I think there's a serious potential
legal issue which would worry me considerably. (I think there already
is in shipping *bits* of the .NET framework, to be honest.)

Being worried about a new technlogy is the sign of a good developer. Only
sloppy developers aren;t concerned that a new technology will break their
code. Overcoming this concern can only be done by trying Thinstall
yourself.

I don't think it can actually be done. I'd never trust Thinstall to run
exactly the same as the real .NET any more than I'd trust two OSes to
run exactly the same way.

As a professional developer, you need to test your Thinstall apps on all
supported OSs. But, you'd have to do that anyway - even without Thinstall.

Yes, but if I'm going to have two different deployment models, one with
Thinstall and one without, that doubles the testing effort. I need to
test on XP with Thinstall, XP without Thinstall, 2000 with Thinstall,
2000 without Thinstall etc.

Thinstall is (in essence) a distribution application, much like an
installer - except that Thinstall minimizes the changes to a user' system,
allows a much wider distribution of your application and protects your
application in ways that common distribution avenues cannot.

Thinstall is not for everyone. It makes more sense for the professional
developer of a widely distributed (sold) application and for desktop
development and distribution inside large companies that wish to make sure
that newer applications do not have a negative impact on their current
applications.

In the later instance, Thinstall actually saves time. You know it won;t
break what's already on the user's PC, so testing compliancy with other
applications is eliminated.

Like I said, Thinstall is not for everyone. But, professional developers
will see the value of Thinstall very quickly.

I think many will see some of the problems I've outlined too though.

 

[Jon Skeet [C# MVP]]

I'd agree. But, who (in the real world of business programming) is given
enough time to do the job right most of the time? In my experience with
large companies - most of the time you are pushed to speed development time
at the expense of quality. This is why most software has bugs that may
never be fixed.

So why is Thinstall different? Why is it absolutely *vital* for every
single customer of Thinstall to get immediate answers when other
development products aren't in the same situation?

More importantly, why should the Thinstall vendors themselves be the
ones who get to decide what kind of support my business *must* have?

In fact, they don't. I have seen a time or two where they have taken a day
or even 2 to answer with an update to Thinstall to provide new functionality
or to change the way Thinstall works to be more in line with the way
developers think.

But, I have never called them and not had my question answered immediately.

Frankly, I'd be slightly worried at getting a new version of Thinstall
with only a couple of days testing. It seems to me it's the kind of
product which requires *really* extensive testing.

I agree. A tiered approach to pricing would be nice if it were made plain
what the customers were getting for their level of support. And, they
already have a forum for user to share with each other on the site.
Right.

Tiered is good for customers, but it can create headaches for supplying
support. Customer calls tend to fluctuate. They are not an even flow of
calls. So, you either have to have enough support reps to take all calls in
a timely manner (which means a great number of them may be sitting around
doing nothing for most of some days) or you have customers upset at being on
hold for a more tan 10 minutes or so.

So they need to work out how many support reps to have to deal with the
customers who've paid for premium support. I don't see how that's
really different to the situation now, to be honest. In fact, it's
somewhat better, because they'd get *some* money from those who have
paid for "second rate" support, which could occupy the support reps
when there are no premium customers requiring support. Rather than
those reps sitting around doing (and thus earning) nothing, they're
effectively earning their money at a lower rate.

Balancing customer needs with the needs of the business can be difficult.
But, so far, I am well pleased with the level of support that I recieve
under the current pricing structure.

But that's because you happen to be in a situation where the price
isn't too much of a problem. It's clear from other replies in this
thread that others aren't in the same situation.

 

[Jon Skeet [C# MVP]]

It does run on Win95A+. It does so by basically creating a virtual machine
that your original exe and dependencies run in. Since your application is
running in a virtual machine (with a virtual registry) you actually don't
alter the core OS at all.

<snip>

I've just been reading their page about linking with the .NET
framework, and they don't support your claim. Specifically:

<quote>
Supports all Intel platforms supported by .NET (Windows 98, ME, NT, 2k,
XP, 2003, PE, XP Embedded)
</quote>

That's on
http://www.thinstall.com/help/index.html?linking_netframework.htm

Note the lack of a mention of Windows 95. As I said, Thinstall itself
may work on 95, but that doesn't mean that programs which themselves
don't run on Windows 95 are going to run on 95 under Thinstall.

 

[Jim Hubbard]

So why is Thinstall different? Why is it absolutely *vital* for every
single customer of Thinstall to get immediate answers when other
development products aren't in the same situation?

I think the JIT team is going more for professional developers more than
occassional developers. These developers typically demand a higher level of
support.

More importantly, why should the Thinstall vendors themselves be the
ones who get to decide what kind of support my business *must* have?

They aren't deciding what type of support you must have. They have built
their business around the model of customer that they are targeting -
professional developers that want top rate products and support.

Frankly, I'd be slightly worried at getting a new version of Thinstall
with only a couple of days testing. It seems to me it's the kind of
product which requires *really* extensive testing.

These are admitedly minor changes, and the version that is available that
quickly is a beta version. They test extensively and churn out tested
versions quite regularly (both in GUI and command line).

In fact, I can't wait for version 3 due out later this year. If all goes as
planned, it will directly integrate with the .Net framework.

So they need to work out how many support reps to have to deal with the
customers who've paid for premium support. I don't see how that's
really different to the situation now, to be honest. In fact, it's
somewhat better, because they'd get *some* money from those who have
paid for "second rate" support, which could occupy the support reps
when there are no premium customers requiring support. Rather than
those reps sitting around doing (and thus earning) nothing, they're
effectively earning their money at a lower rate.

Have you ever done support like this? I have (and still do), and my
experience is just the opposite of what you seem to think will happen.

Jim Hubbard

 

[Jon Skeet [C# MVP]]

I think the JIT team is going more for professional developers more than
occassional developers. These developers typically demand a higher level of
support.

You haven't answered my question. I'm talking about professional
developers, who are *used* to sometimes having to wait for support.
True professional developers build in contingency for just such a
reason - I don't see why I should have to pay more just because *some*
developers don't build in that kind of contingency.

They aren't deciding what type of support you must have. They have built
their business around the model of customer that they are targeting -
professional developers that want top rate products and support.

In other words, they've decided that professional developers aren't
capable of reading manuals or waiting for support. Guess what? I'm a
professional developer who's capable of doing both. By choosing the
route they have - and by preventing downloads for "those who are just
curious" - they've ruled me out of their target audience. There's no
reason for that at all.

These are admitedly minor changes, and the version that is available that
quickly is a beta version. They test extensively and churn out tested
versions quite regularly (both in GUI and command line).

So would you ship with a beta version? Sounds pretty dodgy to me.

In fact, I can't wait for version 3 due out later this year. If all goes as
planned, it will directly integrate with the .Net framework.

I wonder if by then they'll actually have permission to distribute bits
of the framework in the way they do. To quote from the Thinstall
website:

<quote>
This form of .NET Framework redistribution is not yet officially
blessed by microsoft.
</quote>

(http://www.thinstall.com/help/?microsoft_netframeworklinki.htm)

Have you ever done support like this? I have (and still do), and my
experience is just the opposite of what you seem to think will happen.

That just suggests that it hasn't been implemented properly. If you
think it's impossible to get tiered support like that to work
(effectively making your support reps more efficient), please explain
why rather than just stating that it doesn't work.

 

[Jim Hubbard]

But .NET 1.1 requires things that W95A doesn't provide - otherwise MS
would have made it run there. If Thinstall is shipping the libraries
from other OSes in order to run, I think there's a serious potential
legal issue which would worry me considerably. (I think there already
is in shipping *bits* of the .NET framework, to be honest.)

I had asked Jonathan about the legal issues long ago and he assures me that
there aren't any that they are aware of. Microsoft has looked into
Thinstall. You can read their review at
http://thinstall.com/help/index.html?msdnfeb2005.htm .

If there were legal issues, I'm sure that Microsoft would not have issued
this review, and would have surely contacted JIT with any concerns by now.

I don't think it can actually be done. I'd never trust Thinstall to run
exactly the same as the real .NET any more than I'd trust two OSes to
run exactly the same way.

It does not seem that you would be interested in Thinstall. And, that's
perfectly fine. Not everyone will be interested in Thinstall. Some people
like to stick with the old methods of software distribution. I don't sell
Thinstall. But, if I can point you to something that may help you, I am
happy to do so.

So why all the questions about a product you are not interested in? IMHO,
you really should try Thinstall (or any application) before you pass
judgement.

Yes, but if I'm going to have two different deployment models, one with
Thinstall and one without, that doubles the testing effort. I need to
test on XP with Thinstall, XP without Thinstall, 2000 with Thinstall,
2000 without Thinstall etc.

You won't have 2 deployment models. The idea is to use Thinstall as your
sole deployment model. This way you would still have the same testing that
you have today.

If you could deploy your applications as a single EXE that requires no
external dependencies, has built-in licensing, has auto-update
functionality, does not require administrative privileges to "install" and
run, encrypts your internal exes and data and will not be adversly affected
by changes to the .Net framework - why would you also do a deployment
without Thinstall?

I think many will see some of the problems I've outlined too though.

Maybe I've missed something. I don't see any problems. Could you please
post the problems you see for the benefit of folks like me that may have
missed them?

Jim Hubbard
"Every man, woman and child has something they can teach you. Be sure to
listen."

 

[Jim Hubbard]

<snip>

I've just been reading their page about linking with the .NET
framework, and they don't support your claim. Specifically:

<quote>
Supports all Intel platforms supported by .NET (Windows 98, ME, NT, 2k,
XP, 2003, PE, XP Embedded)
</quote>

That's on
http://www.thinstall.com/help/index.html?linking_netframework.htm

Note the lack of a mention of Windows 95. As I said, Thinstall itself
may work on 95, but that doesn't mean that programs which themselves
don't run on Windows 95 are going to run on 95 under Thinstall.

You are right. I didn't fully answer your question before - my bad.

Any application that you wrap with Thinstall must be able to run without
Thinstall on the destination OS. Remember that Thinstall is a new
deployment tool not an OS replacement.

The same goes for the DLLs that you wrap with your application. If your
application calls API functions that are only available on XP, the
application will fail to run on Win98 and Win2000 - with or without
Thinstall.

Sorry for the confusion about the Win95 + .Net issue.

Do you still have many Win95 customers?

Jim Hubbard

 

[Cor Ligthert]

Jim,

Just Google the web and newsgroups for "problems installing .net
framework" and you'll see quite a few examples.

I did as you said and got 3 pages, not much for such a question. Some of
them asking if installing would give problems, some of them telling that
they had only a removable disk, some if them about what the message that the
Net was required did mean. I did not directly problems with installing over
internet of from CD/DVD.

Cor

 

[Jon Skeet [C# MVP]]

I had asked Jonathan about the legal issues long ago and he assures me that
there aren't any that they are aware of. Microsoft has looked into
Thinstall. You can read their review at
http://thinstall.com/help/index.html?msdnfeb2005.htm .

If there were legal issues, I'm sure that Microsoft would not have issued
this review, and would have surely contacted JIT with any concerns by now.

So why haven't they given their official blessing to it?

It does not seem that you would be interested in Thinstall. And, that's
perfectly fine. Not everyone will be interested in Thinstall. Some people
like to stick with the old methods of software distribution. I don't sell
Thinstall. But, if I can point you to something that may help you, I am
happy to do so.

I *am* interested in Thinstall, mostly in my capacity as an MVP.
Unfortunately, that capacity doesn't seem to make me good enough to
deserve an evaluation...

So why all the questions about a product you are not interested in? IMHO,
you really should try Thinstall (or any application) before you pass
judgement.

I *would* try it - if their wretched web site allowed me to, as an
enthusiast. However, in order to get an evaluation version, I'd have to
use my work email address. As I would be evaluating it as an MVP rather
than for work (at the moment) they've cut me out of evaluation. Not
exactly an encouraging start, frankly.

You won't have 2 deployment models. The idea is to use Thinstall as your
sole deployment model. This way you would still have the same testing that
you have today.

That means it effectively penalises those who already *have* the
framework, and want to download just your application, rather than half
of the framework again. If you've already got the framework, 2.7MB for
a "hello world" program is utterly ridiculous.

If you could deploy your applications as a single EXE that requires no
external dependencies, has built-in licensing, has auto-update
functionality, does not require administrative privileges to "install" and
run, encrypts your internal exes and data and will not be adversly affected
by changes to the .Net framework - why would you also do a deployment
without Thinstall?

Because those external dependencies may already be there, I may well
already have a separate licensing model to integrate into other parts
of my app, I may not want or even desire auto-update, my app may well
require admin privileges to install anyway, I may have no particular
desire to encrypt my internal executables, and I may wish to get the
benefit of improvements to the framework that service packs etc make
available without having to redistribute my app.

Maybe I've missed something. I don't see any problems. Could you please
post the problems you see for the benefit of folks like me that may have
missed them?

1) Potential legal issues. You may have dismissed them as not a
problem, but that doesn't mean everyone else will. Heck, even the
vendors recognise is as a problem. (It's in the "Cons" section on one
of their pages.)

2) Cost.

3) Discouraging interested parties from evaluating it.

4) If a customer downloads several Thinstall products (or even several
versions of my Thinstall product) they'll have downloaded more than if
they'd downloaded the framework once and then the products
individually.

5) For system administrators, having control over the installed
application using the framework security control panel is better than
the app having full control. Of course, this may not be an issue - I
wouldn't know, as JITIT have decided that my (e-mail address removed) email
address isn't good enough to deserve an evaluation.

6) Unless debugging protection is enabled, I *suspect* that there are
still (reasonably easy) ways to decompile the .NET code, using cordbg
to get access to the decrypted resources. If I ever get to evaluate
Thinstall properly, I'll give it a try.

7) Slower startup time (as acknowledged on the Thinstall site).

8) Harder to debug (I gather).

9) Another potential point of failure - it's an extra technology rather
than a replacement one; if JITIT decides to up its prices, or goes
belly-up, you're back to square one.

 

[Jon Skeet [C# MVP]]

You are right. I didn't fully answer your question before - my bad.

Any application that you wrap with Thinstall must be able to run without
Thinstall on the destination OS. Remember that Thinstall is a new
deployment tool not an OS replacement.

Absolutely. So where exactly does the following paragraph written by
you come into the equation?

<quote>
Financial constraints are eliminated (from the software's end-user
standpoint) because they don't need to upgrade their OS to use your
Thinstall applications.
</quote>

Either the application would already run on the end user's OS, in which
case there's no financial constraint, or it won't run under Thinstall
without upgrading their OS anyway, in which case the financial
constraint isn't eliminated after all.

The same goes for the DLLs that you wrap with your application. If your
application calls API functions that are only available on XP, the
application will fail to run on Win98 and Win2000 - with or without
Thinstall.

Sorry for the confusion about the Win95 + .Net issue.

Do you still have many Win95 customers?

No - but then I wasn't the one posting an article about how loads of
companies still use Windows 95. Was there a point to posting that
article?

 

[Jim Hubbard]

Jon,

Perhaps I am mis-reading your posts, but you only seem to want to argue
about a product you are not interested in purchasing or even trying.

I don't work for Thinstall. I use it. I like it. I recommend it.

However, I don't have the time or inclination to try and convince
someone so determined NOT to test or use a product to do so. I am happy to
help those that I can, but I am loathe to devote time to convincing someone
of the usefulness of a product against their will.

I wish you all the best in the development and support of your
applications.

Jim Hubbard

 

[Jon Skeet [C# MVP]]

Perhaps I am mis-reading your posts, but you only seem to want to argue
about a product you are not interested in purchasing or even trying.

You've most definitely mis-read my posts if you think I'm not
interested in trying it. Unfortunately, without using my work email
address, I *can't* try it.

I don't work for Thinstall. I use it. I like it. I recommend it.

You recommend it for invalid reasons, such as meaning that people won't
need to upgrade their OS to use an application. You later admitted that
if an application is going to work under Thinstall on a particular OS,
it would have to be able to work on that OS without Thinstall too.

You not only recommend Thinstall though - you spread FUD about .NET,
with posts like the one about the KB list. It's not like .NET is the
only product to have a list of problems/fixes. Do you think the
knowledge bases for the various versions of Windows themselves are
empty? Do you know every single issue raised about every version of
Windows your apps support?

However, I don't have the time or inclination to try and convince
someone so determined NOT to test or use a product to do so. I am happy to
help those that I can, but I am loathe to devote time to convincing someone
of the usefulness of a product against their will.

As I've said before, I'd like to test the product. I'm interested in it
as a technology, even though I don't currently have a commercial reason
to use it. Jitit don't want me to test it though. Shame, really. It
doesn't exactly give me a warm, fuzzy feeling about them.

I wish you all the best in the development and support of your
applications.

Likewise.

 

[Jim Hubbard]

So why haven't they given their official blessing to it?

You, an MVP, are honestly asking me to explain Microsoft's actions?

To me, this is further proof that you are not really interested in
Thinstall. It seem to me that you are interested only in asking rhetorical
or argumentative questions.

Please stick to asking questions that a USER of Thinstall (that's me) would
be able to answer.

I *am* interested in Thinstall, mostly in my capacity as an MVP.
Unfortunately, that capacity doesn't seem to make me good enough to
deserve an evaluation...


I *would* try it - if their wretched web site allowed me to, as an
enthusiast. However, in order to get an evaluation version, I'd have to
use my work email address. As I would be evaluating it as an MVP rather
than for work (at the moment) they've cut me out of evaluation. Not
exactly an encouraging start, frankly.

Have you called them? Try that. Then get back to me.

That means it effectively penalises those who already *have* the
framework, and want to download just your application, rather than half
of the framework again. If you've already got the framework, 2.7MB for
a "hello world" program is utterly ridiculous.

Then don't use it. Gamble on their not having "fixes" in that will break
your code or that tthey will not install them in the future or that they
have admin rights to install and run your app or that another app won't
overwrite the DLLs you may want to register and use in your .Net
application.

You seem happy with what you have. I say stick with it.

Because those external dependencies may already be there, I may well
already have a separate licensing model to integrate into other parts
of my app, I may not want or even desire auto-update, my app may well
require admin privileges to install anyway, I may have no particular
desire to encrypt my internal executables, and I may wish to get the
benefit of improvements to the framework that service packs etc make
available without having to redistribute my app.

Maybe you should not use Thinstall.

1) Potential legal issues. You may have dismissed them as not a
problem, but that doesn't mean everyone else will. Heck, even the
vendors recognise is as a problem. (It's in the "Cons" section on one
of their pages.)

I'd like to see that. Please post the link.

2) Cost.

Nothing I can do. Talk to JIT.

3) Discouraging interested parties from evaluating it.

Have you called them?

4) If a customer downloads several Thinstall products (or even several
versions of my Thinstall product) they'll have downloaded more than if
they'd downloaded the framework once and then the products
individually.

Not neccesrily. Thinstall includes the ability to check for and use the
local .Net framework (if you trust it), to assist the user in downloading
the framework if it isn't there or to include it all in your Thinstall EXE.

5) For system administrators, having control over the installed
application using the framework security control panel is better than
the app having full control. Of course, this may not be an issue - I
wouldn't know, as JITIT have decided that my (e-mail address removed) email
address isn't good enough to deserve an evaluation.

Call them.

6) Unless debugging protection is enabled, I *suspect* that there are
still (reasonably easy) ways to decompile the .NET code, using cordbg
to get access to the decrypted resources. If I ever get to evaluate
Thinstall properly, I'll give it a try.

Let us know.

7) Slower startup time (as acknowledged on the Thinstall site).

Yes. It does seem that if you start a virtual machine before running an app
there may be added time to the process.

8) Harder to debug (I gather).

Not really. Call them and get a demo.

9) Another potential point of failure - it's an extra technology rather
than a replacement one; if JITIT decides to up its prices, or goes
belly-up, you're back to square one.

And if Microsoft decides to trash .Net for .Whatever you're toast. With
Avalon, it will ONLY run on Longhorn. have fun with that.

Jim Hubbard