I was wondering if it is at all posible to write a stand alone .EXE program
in Visual Studio .NET. Hopefully in VB.NET but if not another language would
be ok. Thanks for the assistance
Jul 21 '05
121  9637 
Brett <no@spam.com> wrote: The problem is, as soon as you've got a few programs using Thinstall,
you end up having downloaded more than you would have done if you'd got
the real framework and individual small programs...
You give people the option to download the Framework or stand alone EXE.
Explain the benefit of download the Framework as it applies to future .NET
apps they may use. If they are on dial-up and still don't have .NET
Framework, chances are they probably won't for a while. In that case,
they'll more than likely choose the stand alone EXE.
That's certainly an option. Of course, it means running all your tests
on both versions unless you're *really* trusting of Thinstall not to
change behaviour at all (which I certainly wouldn't be).
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Brett" <no@spam.com> schrieb: I still doubt that there are no legal issues with distributing only parts
of the .NET Framework...
If you want to write a shareware app and know most people that are going
to use it are on dial-up, what are your options? 20+ megs is out of the
question in this case.
Use Delphi, VC++, or another programming language that doesn't rely on
separate libraries.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
I just found another program which looks like it will do the trick and it
costs a lot less. Check out http://www.molebox.com
It doesn't explicitly say it can handle dot net applications but it looks
like it is cpaable of placing the necesary DLL files within the EXE file so
it should be good. I'll be doing some more research into this and I'll let
you all know. A program which costs $99 is a lot more affordable than one
that costs $4000 :)
"David Pendrey" <fa*******@dodo.com.au> wrote in message
news:42********@news.comindico.com.au... I just found another program which looks like it will do the trick and it
costs a lot less. Check out http://www.molebox.com
It doesn't explicitly say it can handle dot net applications but it looks
like it is cpaable of placing the necesary DLL files within the EXE file
so it should be good. I'll be doing some more research into this and I'll
let you all know. A program which costs $99 is a lot more affordable than
one that costs $4000 :)
Good research David. Molebox doesn't support .NET yet and has no schedule
to. They say support should be available by the time Longhorn is released,
which will come with .NET. Seems as though they get to the ball game a
little to late. http://www.molestudio.com/forum/view...&highlight=net
Brett
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Brett <no@spam.com> wrote: > The problem is, as soon as you've got a few programs using Thinstall,
> you end up having downloaded more than you would have done if you'd got
> the real framework and individual small programs...
You give people the option to download the Framework or stand alone EXE.
Explain the benefit of download the Framework as it applies to future
.NET
apps they may use. If they are on dial-up and still don't have .NET
Framework, chances are they probably won't for a while. In that case,
they'll more than likely choose the stand alone EXE.
That's certainly an option. Of course, it means running all your tests
on both versions unless you're *really* trusting of Thinstall not to
change behaviour at all (which I certainly wouldn't be).
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Thinstall doesn't change behavior. Once the EXE is created, it does not
change unless you tell it to update itself or the files it contains.
Cool thing about this is that when Microsoft issues a Service Pack that
scerws up something, your Thinstall app is not affected.
If you create a Thinstall app that works, it will always work unless
Microsoft goes and changes the way windows works at a core level......which
is unlikely.
Jim Hubbard
Damn, just in time to not be usefull :(
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:lq********************@giganews.com...
First, you never have your application's files overwritten (i.e. DLL
Hell). Second, your users don't need administrative rights to run the
application. Third, your users don't need the .Net framework installed.
Only the third of these is different from normal life with .NET Framework,
as far as I can tell...
But it sounds useful.
As for #1 - As we saw with SP6 for VB6, Microsoft is perfectly capable of
and willing to (not intentionally) send out service packs that break old
functionality. With Thinstall .Net applications, there is no danger of that
happening.
As for #2 - Even under .Net, users need admin rights to install a .Net
application if that application utilizes the registry. Not so with
Thinstall applications.
Jim Hubbard
"J L" <jo**@marymonte.com> wrote in message
news:3v********************************@4ax.com... Hi Jim,
I was very excited about Thinstall until I got this pricing from
Jonathan:
1 Application License per unit with Basic support $4,000.00
That is outrageous. For those who dont believe it, here is the link he
sent me to get that pricing
https://thinstall.com/store/index.php
He definetly needs to rethink his pricing structure! I do agree with
all you are saying. Thinstall's philosophy is the right way to go for
XCOPY to really work and they could make a killing if they set thier
price points correctly. I am a single developer creating custom
applications for some fairly large food processors. No way can I
afford that price. A few hundred dollars and it is tempting. I believe
Jonathan should rethink the possible/probable price/volume curve if he
did price this aggressively...let's see, how many millions of .Net
programmers?...
The price is a little steep for freeware or small software shops, but there
is a reason for the price.
Although Thinstall is very useful, the vast number of options it affords the
developer usually means a great deal of hand-holding and one-on-one
development assistance while the developer "learns the ropes". This support
is not cheap for Jonathan and the only other option is to leave developers
hanging with only written instructions or charge for hourly support (which
most customers won't go for).
Jonathan (like myself) would rather do it right and make every customer a
success story than to have legions of customers that may or may not be
satisfied.
I have to go with Jonathan on this one. Running my own business, I have
learned the hard way that going cheap only causes lots of lost sleep, upset
customers and a so-so reputation. I abandoned this WalMart approach as soon
as my customers weren't being taken care of like I would like to be taken
care of (like I am the most important customer the company has - even if I'm
not).
Jonathan's company (JIT) takes care of you like you are the most important
customer they have. They go far beyond just answering a question or
two....they learn your product and goals and offer suggestions to maximize
your profits. If needed, they will also create small demo applications
specifically for what you need to do - because seeing it done is always
better than hearing how it should be done.
Jonathan takes calls himself and stays in touch with his customer base. He
is a real "hands on" company president. Not because he has to be, but
because he wants to keep an eye on the quality of their product and customer
service.
I speak from experience on all of these points. He has helped me personally
with my projects. He has developed demos personally to help me understand
the possibilities that Thinstall affords developers and how those Thinstall
capabilities can help me acheive my goals.
Admitedly, I am a fan of Thinstall and the support I have recieved from
Jonathan Clark and the JIT team. I am so because of the product, service
and personal treatment by the JIT team.
If this unabashed endorsement of a product makes you queasy, I apologize.
But, if you try Thinstall, you'll understand why I am such a fan of it and
the JIT team.
Jim Hubbard
"Jim Hubbard" <re***@groups.please> wrote in message
news:uL********************@giganews.com... As for #1 - As we saw with SP6 for VB6, Microsoft is perfectly capable of
and willing to (not intentionally) send out service packs that break old
functionality. With Thinstall .Net applications, there is no danger of
that happening.
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.
As for #2 - Even under .Net, users need admin rights to install a .Net
application if that application utilizes the registry. Not so with
Thinstall applications.
Surely only if you write in a part of the Registry that requires
administrator privileges to access.
"Jim Hubbard" <re***@groups.please> wrote in message
news:Mc********************@giganews.com...
1 Application License per unit with Basic support $4,000.00
The price is a little steep for freeware or small software shops, but
there is a reason for the price.
Although Thinstall is very useful, the vast number of options it affords
the developer usually means a great deal of hand-holding and one-on-one
development assistance...
But if you price it out of most programmers' reach, it never becomes well
known to the programming community. It may make sales, but it won't make
history.
If it were $99, I'd use it for the demo version of one of my apps, so that
users could download and try it without any awareness of .NET.
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:uG**************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:Mc********************@giganews.com...
1 Application License per unit with Basic support $4,000.00
The price is a little steep for freeware or small software shops, but
there is a reason for the price.
Although Thinstall is very useful, the vast number of options it affords
the developer usually means a great deal of hand-holding and one-on-one
development assistance...
But if you price it out of most programmers' reach, it never becomes well
known to the programming community. It may make sales, but it won't make
history.
Thinstall is actually making history. It is the most stable method of
distributing desktop applications in the world.
If it were $99, I'd use it for the demo version of one of my apps, so that
users could download and try it without any awareness of .NET.
Not to minimize your observation, but if it were $99, it wouldn't be the
great product it is today. (It takes more money to build a Mercedes than a
Yugo.)
As a small business myself, I understand the financial constraints that
small businesses must face. However, you also must weigh the benefits of
the product (which are substantial in this case) against the price.
I think it's worth it. It will reduce your installation and maintenance
customer service calls to almost nil. if you write software for a living or
distribute software as a major product, it pays itself in short order.
Jim Hubbard
Hi Jim,
I appreciate your enthusiasm for the company and the product. I too
was impressed very much with the Thinstall concept when I first
encountered it over a month ago. In fact we had some threads on it at
that time.
And I have no doubs about Jonathan's integrity and desire to produce a
top-rate product. I only question his business model and pricing
structure. If he can make a go of it without the programming community
who are expressing thier interest here but can not afford his tariff,
then I say...good for him. But if it were me I would seriously look at
the market and reconsider. And if the product is so complicated that
the level of users here is not adequate, then for sure he needs to
review his product design, documentation or both. From what I read on
his site, it did not seem that complicated (at least for most of the
applications I would be creating).
And my last thought is that he has stirred some good interest which
may create strong competitive pressures in the future.
Just my 2cents worth,
John
On Sat, 19 Mar 2005 00:06:23 -0500, "Jim Hubbard"
<re***@groups.please> wrote:
"J L" <jo**@marymonte.com> wrote in message
news:3v********************************@4ax.com.. . Hi Jim,
I was very excited about Thinstall until I got this pricing from
Jonathan:
1 Application License per unit with Basic support $4,000.00
That is outrageous. For those who dont believe it, here is the link he
sent me to get that pricing
https://thinstall.com/store/index.php
He definetly needs to rethink his pricing structure! I do agree with
all you are saying. Thinstall's philosophy is the right way to go for
XCOPY to really work and they could make a killing if they set thier
price points correctly. I am a single developer creating custom
applications for some fairly large food processors. No way can I
afford that price. A few hundred dollars and it is tempting. I believe
Jonathan should rethink the possible/probable price/volume curve if he
did price this aggressively...let's see, how many millions of .Net
programmers?...
The price is a little steep for freeware or small software shops, but there
is a reason for the price.
Although Thinstall is very useful, the vast number of options it affords the
developer usually means a great deal of hand-holding and one-on-one
development assistance while the developer "learns the ropes". This support
is not cheap for Jonathan and the only other option is to leave developers
hanging with only written instructions or charge for hourly support (which
most customers won't go for).
Jonathan (like myself) would rather do it right and make every customer a
success story than to have legions of customers that may or may not be
satisfied.
I have to go with Jonathan on this one. Running my own business, I have
learned the hard way that going cheap only causes lots of lost sleep, upset
customers and a so-so reputation. I abandoned this WalMart approach as soon
as my customers weren't being taken care of like I would like to be taken
care of (like I am the most important customer the company has - even if I'm
not).
Jonathan's company (JIT) takes care of you like you are the most important
customer they have. They go far beyond just answering a question or
two....they learn your product and goals and offer suggestions to maximize
your profits. If needed, they will also create small demo applications
specifically for what you need to do - because seeing it done is always
better than hearing how it should be done.
Jonathan takes calls himself and stays in touch with his customer base. He
is a real "hands on" company president. Not because he has to be, but
because he wants to keep an eye on the quality of their product and customer
service.
I speak from experience on all of these points. He has helped me personally
with my projects. He has developed demos personally to help me understand
the possibilities that Thinstall affords developers and how those Thinstall
capabilities can help me acheive my goals.
Admitedly, I am a fan of Thinstall and the support I have recieved from
Jonathan Clark and the JIT team. I am so because of the product, service
and personal treatment by the JIT team.
If this unabashed endorsement of a product makes you queasy, I apologize.
But, if you try Thinstall, you'll understand why I am such a fan of it and
the JIT team.
Jim Hubbard
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:uL********************@giganews.com...
As for #1 - As we saw with SP6 for VB6, Microsoft is perfectly capable of
and willing to (not intentionally) send out service packs that break old
functionality. With Thinstall .Net applications, there is no danger of
that happening.
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.
Don't delude yourself for one minute that Microsoft will upgrade the version
for every patch. It won't happen.
And if it does......may God help us all. I don't want a dozen .Net
frameworks to run 2 dozen apps.
As for #2 - Even under .Net, users need admin rights to install a .Net
application if that application utilizes the registry. Not so with
Thinstall applications.
Surely only if you write in a part of the Registry that requires
administrator privileges to access.
You are correct. But, unfortunately, if you are distributing applications
to the general public, you cannot be sure that they have any .Net framework
installed - let alone the version that your application needs.
At a minimum, this requires a setup application to determine the user's
needs. For many, that means that the application cannot be installed
because they may not have Administrative rights to do any installation (no
matter how safe the application may be).
One way that Microsoft could get everyone up to speed would be a mass OS
giveaway. It'd be akin to giving everyone a fresh start - including
Microsoft. They could retire all older desktops immediately and we'd all
have a common starting point.
Like that's gonna happen......
At the very least, they could make all .Net frameworks an automatic install.
Since they can run side by side, this should be a no-brainer.
Jim Hubbard
John,
Thanks for your views on Thinstall. I'll pass them along to Jonathan
and the JIT team.
Maybe he can do something different with the pricing scale like what
Microsoft does with its products.....give away 2 tech support calls, then
charge for the rest.
Thanks again for your thoughts.
Jim Hubbard
"J L" <jo**@marymonte.com> wrote in message
news:dq********************************@4ax.com... Hi Jim,
I appreciate your enthusiasm for the company and the product. I too
was impressed very much with the Thinstall concept when I first
encountered it over a month ago. In fact we had some threads on it at
that time.
And I have no doubs about Jonathan's integrity and desire to produce a
top-rate product. I only question his business model and pricing
structure. If he can make a go of it without the programming community
who are expressing thier interest here but can not afford his tariff,
then I say...good for him. But if it were me I would seriously look at
the market and reconsider. And if the product is so complicated that
the level of users here is not adequate, then for sure he needs to
review his product design, documentation or both. From what I read on
his site, it did not seem that complicated (at least for most of the
applications I would be creating).
And my last thought is that he has stirred some good interest which
may create strong competitive pressures in the future.
Just my 2cents worth,
John
On Sat, 19 Mar 2005 00:06:23 -0500, "Jim Hubbard"
<re***@groups.please> wrote:
"J L" <jo**@marymonte.com> wrote in message
news:3v********************************@4ax.com. .. Hi Jim,
I was very excited about Thinstall until I got this pricing from
Jonathan:
1 Application License per unit with Basic support $4,000.00
That is outrageous. For those who dont believe it, here is the link he
sent me to get that pricing
https://thinstall.com/store/index.php
He definetly needs to rethink his pricing structure! I do agree with
all you are saying. Thinstall's philosophy is the right way to go for
XCOPY to really work and they could make a killing if they set thier
price points correctly. I am a single developer creating custom
applications for some fairly large food processors. No way can I
afford that price. A few hundred dollars and it is tempting. I believe
Jonathan should rethink the possible/probable price/volume curve if he
did price this aggressively...let's see, how many millions of .Net
programmers?...
The price is a little steep for freeware or small software shops, but
there
is a reason for the price.
Although Thinstall is very useful, the vast number of options it affords
the
developer usually means a great deal of hand-holding and one-on-one
development assistance while the developer "learns the ropes". This
support
is not cheap for Jonathan and the only other option is to leave developers
hanging with only written instructions or charge for hourly support (which
most customers won't go for).
Jonathan (like myself) would rather do it right and make every customer a
success story than to have legions of customers that may or may not be
satisfied.
I have to go with Jonathan on this one. Running my own business, I have
learned the hard way that going cheap only causes lots of lost sleep,
upset
customers and a so-so reputation. I abandoned this WalMart approach as
soon
as my customers weren't being taken care of like I would like to be taken
care of (like I am the most important customer the company has - even if
I'm
not).
Jonathan's company (JIT) takes care of you like you are the most important
customer they have. They go far beyond just answering a question or
two....they learn your product and goals and offer suggestions to maximize
your profits. If needed, they will also create small demo applications
specifically for what you need to do - because seeing it done is always
better than hearing how it should be done.
Jonathan takes calls himself and stays in touch with his customer base.
He
is a real "hands on" company president. Not because he has to be, but
because he wants to keep an eye on the quality of their product and
customer
service.
I speak from experience on all of these points. He has helped me
personally
with my projects. He has developed demos personally to help me understand
the possibilities that Thinstall affords developers and how those
Thinstall
capabilities can help me acheive my goals.
Admitedly, I am a fan of Thinstall and the support I have recieved from
Jonathan Clark and the JIT team. I am so because of the product, service
and personal treatment by the JIT team.
If this unabashed endorsement of a product makes you queasy, I apologize.
But, if you try Thinstall, you'll understand why I am such a fan of it and
the JIT team.
Jim Hubbard
Jim Hubbard <re***@groups.please> wrote: That's certainly an option. Of course, it means running all your tests
on both versions unless you're *really* trusting of Thinstall not to
change behaviour at all (which I certainly wouldn't be).
Thinstall doesn't change behavior. Once the EXE is created, it does not
change unless you tell it to update itself or the files it contains.
I meant that you'd have to really trust that Thinstall behaves
*exactly* the same as the normal .NET framework. Given the complexities
of reflection, CAS, dynamically generating code etc, that sounds like a
difficult thing to trust.
Or, of course, you could double your testing effort.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Doesn't mean they can't sell a version without the support, only the
packaged help files. Then forums could be started up for people to help
eachother and it would all work out. They would get much more sales albeit
at a lower price so they could still make a profit and many more people
would be happy. Once you get a few users who can use a program correctly,
then get them to set up a forum you tend to not need all that much tech
support.
"Jim Hubbard" <re***@groups.please> wrote in message
news:94********************@giganews.com...
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:uG**************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:Mc********************@giganews.com...
1 Application License per unit with Basic support $4,000.00
The price is a little steep for freeware or small software shops, but
there is a reason for the price.
Although Thinstall is very useful, the vast number of options it affords
the developer usually means a great deal of hand-holding and one-on-one
development assistance...
But if you price it out of most programmers' reach, it never becomes well
known to the programming community. It may make sales, but it won't make
history.
Thinstall is actually making history. It is the most stable method of
distributing desktop applications in the world.
If it were $99, I'd use it for the demo version of one of my apps, so
that users could download and try it without any awareness of .NET.
Not to minimize your observation, but if it were $99, it wouldn't be the
great product it is today. (It takes more money to build a Mercedes than
a Yugo.)
As a small business myself, I understand the financial constraints that
small businesses must face. However, you also must weigh the benefits of
the product (which are substantial in this case) against the price.
I think it's worth it. It will reduce your installation and maintenance
customer service calls to almost nil. if you write software for a living
or distribute software as a major product, it pays itself in short order.
Jim Hubbard
"Jim Hubbard" <re***@groups.please> wrote in message
news:94********************@giganews.com...
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:uG**************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:Mc********************@giganews.com...
1 Application License per unit with Basic support $4,000.00
The price is a little steep for freeware or small software shops, but
there is a reason for the price.
Although Thinstall is very useful, the vast number of options it affords
the developer usually means a great deal of hand-holding and one-on-one
development assistance...
But if you price it out of most programmers' reach, it never becomes well
known to the programming community. It may make sales, but it won't make
history.
Thinstall is actually making history. It is the most stable method of
distributing desktop applications in the world.
If it were $99, I'd use it for the demo version of one of my apps, so
that users could download and try it without any awareness of .NET.
Not to minimize your observation, but if it were $99, it wouldn't be the
great product it is today. (It takes more money to build a Mercedes than
a Yugo.)
Bad parallel. A Mercedes doesn't require you to stop at the dealership
everyday to find out how to work the radio and air conditioning. For that
fact, neither does a Yugo. Why? User interface.
Brett
> First, you never have your application's files overwritten (i.e. DLL Hell). Second, your users don't need administrative rights to run the
application. Third, your users don't need the .Net framework installed.
Now this does sound useful!
Thinstall even creates a virtual registry on-the-fly that your application
uses so that there are no changes to the users registry.
Even better.
Thinstall is used by a huge host of companies (like Quickbooks),
government agencies and every branch of the armed forces.
I'm not surprised - sounds like a user's dream - don't have to ask IT to get
involved. Of course, IT may take a dim view to running untested code -
rightly in some cases.
Rob.
> I was very excited about Thinstall until I got this pricing from Jonathan:
Me too LOL!
afford that price. A few hundred dollars and it is tempting. I believe
Jonathan should rethink the possible/probable price/volume curve if he
did price this aggressively...let's see, how many millions of .Net
programmers?...
Yes, about the same price as InstallShield maybe.
Rob.
> Yep - it's still pretty bad here in the way of dial-up. Same with cell phones but that's another newsgroup.
Ahh well if you will decide to slightly modify the existing GSM standard,
then what do you expect? :-)
Rob.
Just my two cents...If I had DialUp, I'd rather download a 20mb file once
than a 14mb file for each application. Neither of which do I really want to
download on dialup! Also, the .Net Framework seems to me to be backward
compatible as all of my applications seem to work whenever I replace the .Net
Framwork with the latest version.
"Jim Hubbard" wrote:
"Steve McLellan" <sjm AT fixerlabs DOT com> wrote in message
news:uz**************@TK2MSFTNGP12.phx.gbl... Notepad requires a runtime of sorts, and probably a load of libraries.
Hook a debugger up to it and see how many libraries load. The overhead is
hidden because they're generally already present, as will be the case with
the .NET framework at some point in the future. Things like Thinstall do
definitely have advantages, but if a bug crops up in a .NET component, how
do you patch it? You need to tell your users (it becomes a problem in YOUR
code, rather than the framework) rather than letting them just get updates
via Windows Update etc.
If you product doesn't work, they are going to blame you anyway.
That's how customers are (and should be, if you think about it logically).
Most aren't programmers, or even all that technically literate. If they
click on your program's icon, they expect it to work. If it doesn't, your
product sucks (in their eyes).
They don't care why it doesn't work. And they have been given the
run-around so much (the PC maker blames Windows, Microsoft blames a driver
manufacturer, the diver manufacturer can't be found......the PC user is
still screwed and now just more angry) that they don't want to hear that
it's someone else's fault. They just want it to work.
Cool thing about a Thinstall app is that you can also program it to update
itself. So, if you put a new version on an available server.....you're set.
I've read the pricing concerns above, and I'll talk to Jonathan about it
today.
Jim Hubbard
"Rob Nicholson" <ro***********@nospam-unforgettable.com> wrote in message
news:uE**************@TK2MSFTNGP14.phx.gbl... Yep - it's still pretty bad here in the way of dial-up. Same with cell
phones but that's another newsgroup.
Ahh well if you will decide to slightly modify the existing GSM standard,
then what do you expect? :-)
Rob.
Ok Rob. Sure thing. What do I need an adapter, a different antenna for my
cell phone? Can I pick those up at Radio Shack or Target?
"Jim Hubbard" <re***@groups.please> wrote in message
news:pM********************@giganews.com...
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Brett <no@spam.com> wrote: > The problem is, as soon as you've got a few programs using Thinstall,
> you end up having downloaded more than you would have done if you'd
> got
> the real framework and individual small programs...
You give people the option to download the Framework or stand alone EXE.
Explain the benefit of download the Framework as it applies to future
.NET
apps they may use. If they are on dial-up and still don't have .NET
Framework, chances are they probably won't for a while. In that case,
they'll more than likely choose the stand alone EXE.
That's certainly an option. Of course, it means running all your tests
on both versions unless you're *really* trusting of Thinstall not to
change behaviour at all (which I certainly wouldn't be).
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Thinstall doesn't change behavior. Once the EXE is created, it does not
change unless you tell it to update itself or the files it contains.
Cool thing about this is that when Microsoft issues a Service Pack that
scerws up something, your Thinstall app is not affected.
If you create a Thinstall app that works, it will always work unless
Microsoft goes and changes the way windows works at a core
level......which is unlikely.
Jim Hubbard
Jim, we get the idea. You really love Thinstall. It's the greatest thing
since spit. However, every one here doesn't have $4k to shell out on an
installer. We'd rather make $4k than spend it on something we feel isn't
worth $4k. Also, I doubt any one is going to enjoy staying on the phone
with Thinstall tech support for a lengthy phone sessions of how to do this
and that (As you more or less alluded to earlier).
Your energy would probably be better spend in a marketing campaign to
fortune 500 companies. As for Thinstall changing its behavior, I wouldn't
place all my eggs in one basket. If Thinstall goes under, quite a few
Thinstall customers are going to be left holding the bag. Chances are MS
won't go under before any of my apps retire. I'll place my bets on MS and
the bigger download because at least I know they will always be there. At
least under Longhorn.
No attack on you Jim. You just keep holding this carrot in front of every
one and don't seem to realize it really is out of our reach.
Brett Not to minimize your observation, but if it were $99, it wouldn't be the
great product it is today. (It takes more money to build a Mercedes than
a Yugo.)
Bad parallel. A Mercedes doesn't require you to stop at the dealership
everyday to find out how to work the radio and air conditioning. For that
fact, neither does a Yugo. Why? User interface.
WELL SAID!
"Brett" <no@spam.net> wrote in message
news:OI****************@TK2MSFTNGP09.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:pM********************@giganews.com...
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Brett <no@spam.com> wrote:
> The problem is, as soon as you've got a few programs using Thinstall,
> you end up having downloaded more than you would have done if you'd
> got
> the real framework and individual small programs...
You give people the option to download the Framework or stand alone
EXE.
Explain the benefit of download the Framework as it applies to future
.NET
apps they may use. If they are on dial-up and still don't have .NET
Framework, chances are they probably won't for a while. In that case,
they'll more than likely choose the stand alone EXE.
That's certainly an option. Of course, it means running all your tests
on both versions unless you're *really* trusting of Thinstall not to
change behaviour at all (which I certainly wouldn't be).
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Thinstall doesn't change behavior. Once the EXE is created, it does not
change unless you tell it to update itself or the files it contains.
Cool thing about this is that when Microsoft issues a Service Pack that
scerws up something, your Thinstall app is not affected.
If you create a Thinstall app that works, it will always work unless
Microsoft goes and changes the way windows works at a core
level......which is unlikely.
Jim Hubbard
Jim, we get the idea. You really love Thinstall. It's the greatest thing
since spit. However, every one here doesn't have $4k to shell out on an
installer. We'd rather make $4k than spend it on something we feel isn't
worth $4k. Also, I doubt any one is going to enjoy staying on the phone
with Thinstall tech support for a lengthy phone sessions of how to do this
and that (As you more or less alluded to earlier).
Your energy would probably be better spend in a marketing campaign to
fortune 500 companies. As for Thinstall changing its behavior, I wouldn't
place all my eggs in one basket. If Thinstall goes under, quite a few
Thinstall customers are going to be left holding the bag. Chances are MS
won't go under before any of my apps retire. I'll place my bets on MS and
the bigger download because at least I know they will always be there. At
least under Longhorn.
Taken from http://www.itfacts.biz/index.php?id=P454 ...
--------------------------------
"The study, released this week by technology consultant AssetMetrix, found
that more than 80% of companies still have some machines using Windows 95 or
Windows 98. Of those companies still using the older operating systems, an
average of 39% of desktops were running either Windows 95 or Windows 98. "We
found a significant occurrence of Windows 9x," said Steve O'Halloran,
managing director for the research arm of AssetMetrix. The study looked at
372,129 PCs from 670 companies ranging in size from 10 to 49,000 employees.
The size of the business did not seem to dictate how prevalent the older
operating systems were, with larger companies as likely as smaller ones to
have a high prevalence of older operating systems. In total, Windows 95 made
up 14.7% of operating systems, and Windows 98 made up 12.5%. Windows 2000
was the most common OS, running on slightly more than half of machines,
while its predecessor, Windows NT4, was still used on 13.3% of desktops.
Windows XP, the most current version of Windows, was found on just 6.6% of
the machines. Consumers are also still widely using Windows 98. Google
reported that 29% of searches done in September came from machines running
Windows 98, as compared with 38% from Windows XP-based PCs and 20% from
Windows 2000 machines. "
--------------------------------
When Longhorn fianally appears, this will not change much. There will still
be a large portion of PCs that are not "up-to-date". This is a major reason
to use a product like Thinstall. You can't make everyone upgrade (because
of price and administrative constraints) so you have to work with what they
have.
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.
Administrative issues are more quickly dealt with because they can try a
Thinstall app without fear that it will overwrite another application's DLLs
and because eliminating a Thinstall application is as easy as deleting the
EXE from the user's hard drive.
No attack on you Jim. You just keep holding this carrot in front of every
one and don't seem to realize it really is out of our reach.
I really do understand. I never meant to get into a big discussion about
Thinstall, but when I find something that helps me I like to let other know
about it - whether it's Thinstal or Barts PE or whatever.
I've been helped a lot by people in these newsgroups and I try to give a
little back when I can.
Jim Hubbard
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:21**********************************@microsof t.com... Just my two cents...If I had DialUp, I'd rather download a 20mb file once
than a 14mb file for each application. Neither of which do I really want
to
download on dialup! Also, the .Net Framework seems to me to be backward
compatible as all of my applications seem to work whenever I replace the
.Net
Framwork with the latest version.
When you add a new version of the .Net framework, you are not really
replacing the existing .Net framework. Microsoft created the .Net
frameworks to run side-by-side. That way you can still run 1.0 and 1.1
application on a pc that needs 2.0 for newer applications.
What you may find is that if you re-compile your 1.0 applications with 1.1
or 2.0 you may need to do some code tweaking to adjust for changes in the
framework.
Also keep an eye on the bugs found in the .Net frameworks. It seems 1 or 2
A DAY are coming out, with 1,596 so far in the .Net 1.1 framework
( http://www.kbalertz.com/technology_3.aspx). You can get on a free news
letter at KBAlertz website at http://www.kbalertz.com/default.aspx.
I don't know how anybody develops in .Net successfully without a site like
this.
Jim Hubbard
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:u1**************@TK2MSFTNGP12.phx.gbl...
Not to minimize your observation, but if it were $99, it wouldn't be the
great product it is today. (It takes more money to build a Mercedes
than a Yugo.)
Bad parallel. A Mercedes doesn't require you to stop at the dealership
everyday to find out how to work the radio and air conditioning. For
that fact, neither does a Yugo. Why? User interface.
WELL SAID!
Only if you aren't familiar with the interfaces of a Yugo and a
Mercedes......
The major components like the steering wheel, brake pedal and gas pedal are
similar enough to allow anyone to get the basic functionality out of both
vehicles. However, the Mercedes has many tweaks and added options that the
Yugo does not. In this case, to get the most out of the Mercedes you need
more instruction on it's use.
Thinstall has a very familiar user interface and running the application in
a very basic mode can be done without so much as reading the manual. But,
when your application has it's own special needs you need more specialized
instructions.
While the JIT team has provided several examples and an extensive help
manual, JIT customers are probably not that different than most other
customers and will call tech support before reading the manual. Fortunately
for JIT's customers, they don't just say "Read the &*()^%$ manual" - they
stay with you until you understand how to use the product to accomplish the
special needs unique to your situation - like a good Mercedes dealer will.
If you want to go simple with Thinstall, you can. If you need help, they
are there.
To provide this amount of customer support costs more money than to provide
unsupported applications. And, businesses demand support for their
applications. So, I agree with Jonathan. Charge what it takes to take care
of people in the way that they expect to be cared for as customers -
especially as business customers who have customers of their own.
Businesses CANNOT afford to not have the answers they need right at their
fingertips. With JIT, they have those answers when they need them - not via
some email that makes you wait 72 hours for a reply (which may or may not be
the answer you needed).
If you write software for a living, Thinstall is great. If you write an app
once in a while or just for fun, it probably isn't for you.
Thinstall is a serious application for serious application development. It
is not for everyone.
Jim Hubbard
Jim Hubbard <re***@groups.please> wrote:
<snip> When Longhorn fianally appears, this will not change much. There will still
be a large portion of PCs that are not "up-to-date". This is a major reason
to use a product like Thinstall. You can't make everyone upgrade (because
of price and administrative constraints) so you have to work with what they
have.
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.)
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...
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jim Hubbard <re***@groups.please> wrote:
<snip> Businesses CANNOT afford to not have the answers they need right at their
fingertips. With JIT, they have those answers when they need them - not via
some email that makes you wait 72 hours for a reply (which may or may not be
the answer you needed).
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. 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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi all,
To start with, thank you all this wonderful information. I am actually new
to the concept of newsgroups and other public information services. As
strange as that may seem to the readers of this groups, I have been on the
Microsoft development platform for 5 years and rely at most on Google or
MSDN.
In any case, I have worked with the software ranging from the simplest to
excruciatingly complex, the most common mass-oriented to tailored solutions
on an enterprise level.
I agree with Jim Hubbard in supporting Jonathan's prices as well as the
readers of this newsgroup who think his prices are TOO steep. Allow me to
explain. Being in the development business, I can understand that customer
services can inflate costs. Once a customer starts receiving good support
for a product that increases his profits, there is not much more he can ask
for. As for the ridiculously large number of individual developers and small
startups out there, I'd like to address Jonathan the following. Your concept
is indeed a professional and effective one, I have to give you that.
However, the idea of decreasing costs and increasing sales volumes is not a
new one. If used right, it can benefit people such as yourself as well as
the masses. I don't believe there are any boundaries in business creativity
and the average Joe armed with a modest IQ can step up there if a few things
are in place. I say all this out of personal experience since I have been
working on three cash cows myself. This newsgroup was more than a revelation
making me next in line to offer a "no dependency" deployment solution at a
rate masses can afford. What I will be missing is your dedication to
individual customer satisfaction since I have nor the business mindset, the
academic background, or the patience to support it. But I personally believe
that a vision which inspires from both schools of thought could go as far as
monopolizing an industry. Offer high cost services to customers of
reasonable size but don't shut out the masses. Instead, provide them with a
package that is affordable without the corporate support. I completely agree
with what someone said somewhere in this thread: "Individuals and startups
are desperate enough not to care about major support". I think there is too
much talent out there. Even if a fraction of that turns into success stories
because of our products, we could achieve unmatched sales volumes while
benefiting the masses at the same time.
In conclusion, a geek minus the disability to look beyond the screen can
raise some serious hell. I personally believe that if you can write
versatile code and improvise while maintaining sensible standards, you are
already equipped to take on the software consumer market in a big way.
Like I mentioned before, I am completely oblivious to electronic public
information services given my lack of patience on the internet so the only
place to contact me is via email or phone.
Thank you all again for the helpful information and wish you all the best of
luck!!!
Regards,
Raheel A. Khan ra************@gmail.com
+92 (300) 532-6980
"J L" <jo**@marymonte.com> wrote in message
news:dq********************************@4ax.com... Hi Jim,
I appreciate your enthusiasm for the company and the product. I too
was impressed very much with the Thinstall concept when I first
encountered it over a month ago. In fact we had some threads on it at
that time.
And I have no doubs about Jonathan's integrity and desire to produce a
top-rate product. I only question his business model and pricing
structure. If he can make a go of it without the programming community
who are expressing thier interest here but can not afford his tariff,
then I say...good for him. But if it were me I would seriously look at
the market and reconsider. And if the product is so complicated that
the level of users here is not adequate, then for sure he needs to
review his product design, documentation or both. From what I read on
his site, it did not seem that complicated (at least for most of the
applications I would be creating).
And my last thought is that he has stirred some good interest which
may create strong competitive pressures in the future.
Just my 2cents worth,
John
On Sat, 19 Mar 2005 00:06:23 -0500, "Jim Hubbard"
<re***@groups.please> wrote:
"J L" <jo**@marymonte.com> wrote in message
news:3v********************************@4ax.com.. . Hi Jim,
I was very excited about Thinstall until I got this pricing from
Jonathan:
1 Application License per unit with Basic support $4,000.00
That is outrageous. For those who dont believe it, here is the link he
sent me to get that pricing
https://thinstall.com/store/index.php
He definetly needs to rethink his pricing structure! I do agree with
all you are saying. Thinstall's philosophy is the right way to go for
XCOPY to really work and they could make a killing if they set thier
price points correctly. I am a single developer creating custom
applications for some fairly large food processors. No way can I
afford that price. A few hundred dollars and it is tempting. I believe
Jonathan should rethink the possible/probable price/volume curve if he
did price this aggressively...let's see, how many millions of .Net
programmers?...
The price is a little steep for freeware or small software shops, but
thereis a reason for the price.
Although Thinstall is very useful, the vast number of options it affords
thedeveloper usually means a great deal of hand-holding and one-on-one
development assistance while the developer "learns the ropes". This
supportis not cheap for Jonathan and the only other option is to leave
developershanging with only written instructions or charge for hourly support
(whichmost customers won't go for).
Jonathan (like myself) would rather do it right and make every customer a
success story than to have legions of customers that may or may not be
satisfied.
I have to go with Jonathan on this one. Running my own business, I have
learned the hard way that going cheap only causes lots of lost sleep,
upsetcustomers and a so-so reputation. I abandoned this WalMart approach as
soonas my customers weren't being taken care of like I would like to be taken
care of (like I am the most important customer the company has - even if
I'mnot).
Jonathan's company (JIT) takes care of you like you are the most
importantcustomer they have. They go far beyond just answering a question or
two....they learn your product and goals and offer suggestions to
maximizeyour profits. If needed, they will also create small demo applications
specifically for what you need to do - because seeing it done is always
better than hearing how it should be done.
Jonathan takes calls himself and stays in touch with his customer base.
Heis a real "hands on" company president. Not because he has to be, but
because he wants to keep an eye on the quality of their product and
customerservice.
I speak from experience on all of these points. He has helped me
personallywith my projects. He has developed demos personally to help me
understandthe possibilities that Thinstall affords developers and how those
Thinstallcapabilities can help me acheive my goals.
Admitedly, I am a fan of Thinstall and the support I have recieved from
Jonathan Clark and the JIT team. I am so because of the product, service
and personal treatment by the JIT team.
If this unabashed endorsement of a product makes you queasy, I apologize.
But, if you try Thinstall, you'll understand why I am such a fan of it
andthe JIT team.
Jim Hubbard
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jim Hubbard <re***@groups.please> wrote:
<snip>
When Longhorn fianally appears, this will not change much. There will
still
be a large portion of PCs that are not "up-to-date". This is a major
reason
to use a product like Thinstall. You can't make everyone upgrade
(because
of price and administrative constraints) so you have to work with what
they
have.
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
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jim Hubbard <re***@groups.please> wrote:
<snip>
Businesses CANNOT afford to not have the answers they need right at their
fingertips. With JIT, they have those answers when they need them - not
via
some email that makes you wait 72 hours for a reply (which may or may not
be
the answer you needed).
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
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:uL********************@giganews.com...
As for #1 - As we saw with SP6 for VB6, Microsoft is perfectly capable of
and willing to (not intentionally) send out service packs that break old
functionality. With Thinstall .Net applications, there is no danger of
that happening.
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/archiv.../13/89021.aspx for another view
on this "fix" situation.
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.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:eh**************@tk2msftngp13.phx.gbl... Jim,
The problem comes in when the user tries to install the .Net framework.
Unless you are on a completely clean PC, installing the .Net framework
can be problematic. Then your customers are calling you for support with
a Microsoft product and that just sucks.
I can me not remember that I ever heard about what you wrote above in any
newsgroup I am active in..
Can you give some samples for situations where you have got those.
Cor
Is Delphi planning on continuing as is or is it going to be sucked into the
..Net vacuum as well?
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OW**************@TK2MSFTNGP12.phx.gbl... "Brett" <no@spam.com> schrieb: I still doubt that there are no legal issues with distributing only
parts of the .NET Framework...
If you want to write a shareware app and know most people that are going
to use it are on dial-up, what are your options? 20+ megs is out of the
question in this case.
Use Delphi, VC++, or another programming language that doesn't rely on
separate libraries.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Brett" <no@spam.com> wrote in message
news:ug**************@TK2MSFTNGP15.phx.gbl... 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" <re***@groups.please> wrote in message
news:t9********************@giganews.com... 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
Jim Hubbard <re***@groups.please> wrote: 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.
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.
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.
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 - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jim Hubbard <re***@groups.please> wrote: 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.
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?
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.
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.
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.
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 - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jim Hubbard <re***@groups.please> wrote: 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....tframework.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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jim Hubbard <re***@groups.please> wrote: > 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.
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.
>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.
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.
<snip> 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.
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
Jim Hubbard <re***@groups.please> wrote: 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.
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.
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.
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.
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).
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/?micro...eworklinki.htm) 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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jim Hubbard <re***@groups.please> wrote: > 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.
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.
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.
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.
> 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.
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?
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.
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."
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jim Hubbard <re***@groups.please> wrote: 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....tframework.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
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
Jim Hubbard <re***@groups.please> wrote: 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.
So why haven't they given their official blessing to it?
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.
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.
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.
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. 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.
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 sk***@pobox.com 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 - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jim Hubbard <re***@groups.please> wrote: 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.
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?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
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
Jim Hubbard <re***@groups.please> wrote: 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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jim Hubbard <re***@groups.please> wrote: > 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.
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 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.
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.
Have you called them? Try that. Then get back to me.
> 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.
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.
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 you should not use Thinstall.
>> 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.
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.)
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 sk***@pobox.com 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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: none |
last post by:
Howdy all,
I'm wondering if someone could give some direction on a problem I have
or share their experiences.
I'm wanting to create a little PHP application that will run on a
local machine...
|
by: Todd D. Levy |
last post by:
What do I need to get (from Microsoft I assume) in order to distribute
stand alone Access applications to people who do not (and will not) have
Access installed on their systems?
I have heard...
|
by: David Pendrey |
last post by:
I was wondering if it is at all posible to write a stand alone .EXE program
in Visual Studio .NET. Hopefully in VB.NET but if not another language would
be ok. Thanks for the assistance
|
by: Ulrich Wisser |
last post by:
Hi,
I would like to stop the postmaster every night and run
vacuum
pg_dump
reindex
in the stand alone backend.
|
by: jim-on-linux |
last post by:
py help,
The file below will run as a stand alone file.
It works fine as it is.
But, when I call it from another module it locks
my computer, The off switch is the only
salvation.
This...
|
by: discobay |
last post by:
Is there a way to create a stand alone .exe from VB2005, that does not depend upon the .NET framework being installed on the target machine?
I have followed previous threads on this subject and...
|
by: pg |
last post by:
My old HD crashes, so I had to do a total re-install.
After installer XP, I went to the Micrsoft Update site to get all the
update.
After 5 hours or so ... the update cycle started looping.
...
|
by: newsaboutgod |
last post by:
I need a stand alone database for a VB.Net application on a laptop.
It will have about 15,000 records in it.
Frst off, if there any way to load XML in to a dataset and then run
SQL against it?...
|
by: skneife |
last post by:
I need to create some zones in my asp page, that contains a header and
a body like a webpart.
How can I use a webpart for this designed without any webpart menu or
connection with anything, like a...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
