Does CompactFramework function in PC based Windows environment?

[Timothy Casey]

1. Does CompactFramework work on PC? IE Can I use the compactframework in
place of the standard framework to allow my packages to be more accessible
to PC users whoe download them via dialup?

2. Does Compact Framework ship with VB7 .NET 2003 "Standard" or is there a
patch/download I can get from Microsoft?

3. If yes to all of the above, what are the pros and cons of migrating
software development from VB6 to VB7 under the .NET compactframework?

Thanks in Advance...

 

[Stephany Young]

1: No

2 & 3: Reddundant because of 1 (above)

 

[Jim Cooper]

1: No

Although you can run a CF app on a PC if .NET is installed. Looks pretty
weird though.

Timothy, the idea of writing the same app for both a CF device and a PC
is flawed as a concept. A PDA or phone is a completely different sort of
device than a PC, and has different appropriate uses, different usage
patterns, restrictions because of size and difficulty of data entry,
different metaphors for manipulating the UI,...

Write two applications. You can share the business logic if you need to.


Cheers,
Jim Cooper

__________________________________________

Jim Cooper (e-mail address removed)
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
__________________________________________

 

[Timothy Casey]

Although you can run a CF app on a PC if .NET is installed. Looks pretty
weird though.

Timothy, the idea of writing the same app for both a CF device and a PC
is flawed as a concept. A PDA or phone is a completely different sort of
device than a PC, and has different appropriate uses, different usage
patterns, restrictions because of size and difficulty of data entry,
different metaphors for manipulating the UI,...

Write two applications. You can share the business logic if you need to.

Thanks Jim,

I agree that PDAs & PCs have entirely different requirements. If I was to
use the compactframework to create an application for PC, I'd still be
writing a separate and different application for PDA if the PDA option were
profitable/practical. If you think that the compactframework can be used
effectively for PC-only applications, it would be great if I could get some
pointers from you with respect to VB7.NET 2003 Standard Edition...

However, the standard 30Mb .NET framework binary is way too large for
shareware developers targeting the Windows PC market.

Does the .NET framework ship with Windows XP or one of its service packs?

If so, then I can happily migrate to .NET in 2007 because few people under
such circumstances, will need to have the .NET framework bundled with the
shareware.NET they download...

The problems of .NET for shareware developers interms of business logic is
as follows:

1. Costs
Bandwidth = Money: Both in terms of what shareware customers pay their ISP
as well as developers paying for hosting. Shareware.NET requires ten times
the bandwidth of shareware compiled with VB6. To give you some idea, the
typical hosting package in Australia does not provide even enough space for
a SINGLE shareware.NET download, much less the 450Gb monthly bandwidth
necessary just to bring in enough money to cover the capital interest on the
cost of development (100 downloads/sale * 5 mean sales/day * 365/12
days/month * mean download size). Even the big commercial hosting packages
do not anticipate the shear scale of shareware.NET bandwidth use for a
single product - all assuming that there is not another way with .NET

2. Markets
Software is all about making life simpler and not more complicated.
So it is too much to ask the punters (Australian for "customer") if they
don't have the .NET framework to please spend hours downloading it when the
punters really want simplicity, and they want it yesterday!

Thus from the perspective of a shareware developer, a migration to .NET
could undermine both my market share AND the opportunity to operate
profitably at all; IF the issue of overhead cannot be addressed...

Thanks in Advance for any suggestions or answers...

 

[Daniel Moth]

To run any .NET application on the PC you need the .NET Framework and the
runtime with the distribution costs/size/etc that you mention. The Compact
Framework *cannot* help you with that at all.

As for your other points on the merits/pitfalls/shortcomings of developing
for the .NET platform, allow me to abstain. They do not belong in this group
and have been discussed many times over the past few years in the
newsgroups/forums on .NET (not applicable to the CF).

Cheers
Daniel

 

[Guest]

I'll take the bait....

1. The CF cannot run under full Windows. Would be nice if it could
(especially for XPe environments.
2. The "size of the framework" will become a non-issue as time progresses.
XPSP2 and Server 03 ship with the framework. Every future version of
Windows will also. This really is no different than frameworks of the past
that started shipping with the versions of windows that came out after the
framework.
3. No idea whatyou're talking about with "size of .NET apps". I've found
managed apps to often be smaller binaries that comparable unmanaged
applications.
4. VB6 also required a runtime (albeit a hell of a lot smaller)
5. No idea about "bandwidth required is 10x higher for .NET". Non-networked
apps don't use bandwidth at all, and as far as size, see #3.
6. I've done my share of VB6 enterprise DCOM solution rollouts. Simplicity
is not a word that comes to mind. I find managed solutions easier to deploy
and far less customer support needed for installation issues.
7. As Daniel said, the merits have been discussed and there are many on both
sides of the issue. If you want a persuasive argument for either side, you
can find it with Google.

-Chris

 

[Jim Cooper]

I agree that PDAs & PCs have entirely different requirements. If I was to
use the compactframework to create an application for PC, I'd still be
writing a separate and different application for PDA if the PDA option were
profitable/practical.

Then just use the normal .NET framework for the PC app.

If you think that the compactframework can be used
effectively for PC-only applications

I don't. You can run CF apps on a PC with the full framework installed,
but you would usually only do that if you had no other way to debug the
CF app. AFAIK it wouldn't work to just have the CF, since the CF doesn't
have the right JITter for the PC

However, the standard 30Mb .NET framework binary is way too large for
shareware developers targeting the Windows PC market.

It is very common to already have the .NET framework installed through
some other means these days.

Does the .NET framework ship with Windows XP or one of its service packs?

I don't know, sorry.

Bandwidth = Money:

To give you some idea, the typical hosting package in Australia does
not provide even enough space for a SINGLE shareware.NET download

You should not host the .NET framework yourself (I'm not certain if
you're allowed to). Just link to MS. Since the framework only has to be
installed once, not once per application that uses it, not everyone will
need the extra download.

So it is too much to ask the punters (Australian for "customer")

The odds are that I've been speaking Australian longer than you,
actually

Thanks in Advance for any suggestions or answers...

What sort of shareware apps are you intending to write? If you're going
to write tools for .NET developers, then the whole issue goes away. If
you're writing something for very non-technical users, it is going to be
a problem. .NET performance might be an issue for certain types of
applications.

Cheers,
Jim Cooper

__________________________________________

Jim Cooper (e-mail address removed)
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
__________________________________________

 

[Dick Grier]

Hi,
Does the .NET framework ship with Windows XP or one of its service packs?
<<

Yes. SP2

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.

 

[Timothy Casey]

Hi,

Does the .NET framework ship with Windows XP or one of its service packs?
<<

Yes. SP2

Thank you.

So if I package shareware for XP SP2 & above without the framework, are
there any guidlines on what can I leave out of the packages?

 

[Timothy Casey]

What sort of shareware apps are you intending to write? If you're going
to write tools for .NET developers, then the whole issue goes away. If
you're writing something for very non-technical users, it is going to be
a problem. .NET performance might be an issue for certain types of
applications.

It's all for the non-technical public. I maintain a
range of packages covering various activities including:
Web Menus
Speed Reading
IQ Testing
Browser Security
Background Management
Blackjack simulation & system testing
Postcode Surveys

Most of the people going for these would not know
what a .NET Framework is, nor would they be
remotely interested in finding out.

Developers aren't a source of large specialty markets
so unless I have developed an app for myself and just
happen to have the time to iron out the kinks I know
how to avoid, I try to focus on larger specialty markets.

So perhaps I am headed for hot water... :^)

 

[Timothy Casey]

Thank you for your response...

I'll take the bait....

1. The CF cannot run under full Windows. Would be nice if it could
(especially for XPe environments.
2. The "size of the framework" will become a non-issue as time progresses.

This could be a long time, however;

XPSP2 and Server 03 ship with the framework. Every future version of
Windows will also. This really is no different than frameworks of the past
that started shipping with the versions of windows that came out after the
framework.

It seems that maybe not so long after all. Based on this information, and
failing all other options, a migration around mid 2008 could be practical
for me.

3. No idea whatyou're talking about with "size of .NET apps". I've found
managed apps to often be smaller binaries that comparable unmanaged
applications.
4. VB6 also required a runtime (albeit a hell of a lot smaller)
5. No idea about "bandwidth required is 10x higher for .NET". Non-networked
apps don't use bandwidth at all, and as far as size, see #3.

There is lots of material about the 30Mb framework that must ship with
installed .NET apps if they are to work, and the scary part is that this
makes the average .NET setup package ten times larger than the average VB6
setup package. A ten times increase in mean shareware package size is equal
to a ten times increase in bandwidth use for sites hosting the shareware.

6. I've done my share of VB6 enterprise DCOM solution rollouts. Simplicity
is not a word that comes to mind. I find managed solutions easier to deploy
and far less customer support needed for installation issues.

I've found that some "features" are more complex than building from
scratch - in my case it seems easier to build a better binary database
system from scratch than mess around with somebody-else's ever-changing
assumptions (that usually deviate wildly from what I or my customers expect)
about database requirments (Eg. DAO, ADO, to "Data Environments",
grumble-grouch-gripe-etc! :^). The thing in this case is, I have a
solution so I just apply it and everything is fine. What I need is a
practical solution for making .NET packages as compact as VB6 packages...

7. As Daniel said, the merits have been discussed and there are many on both
sides of the issue. If you want a persuasive argument for either side, you
can find it with Google.

I am not so keen on being persuaded, as on finding a solution. I know that
without a fairly substantial push (say something the size of the moon on a
collision course with earth at a differential speed half that of light
:^), Microsoft are intent on the .NET framework path that they have chosen.
Thus .NET appears to be the only future there is and that's it. In this
light, I need to find a way to keep doing what I am doing, without having
all my products broken by the proverbial next Microsoft operating system. So
the burning question is whether there is any way at all of manipulating .NET
to this end without killing my existing market or increasing my bandwidth
costs?

 

[Timothy Casey]

I'll take the bait.... [SNIP]
3. No idea whatyou're talking about with "size of .NET apps". I've found
managed apps to often be smaller binaries that comparable unmanaged
applications.

[SNIP]

So there are ways to make the total size of the "runtime" dependency files
that ship with an application packaged by .NET smaller?

Please, could you fill me in on the details?

Thanks in Advance...

 

[Guest]

You don't distribute the framework with your apps. Not everyone needs it,
so forciong them to download 80MB when they only need your 10k app is kind
of rude. Just provide a download for your app, then set up a link that
points to the MS download site, or tell them to use the Windows Update
feature available in the OS to download and install it. While not
ubiquitous, I think you'll find the framework is more prevalent on machines
that you appear to think it is.

-Chris

I'll take the bait.... [SNIP]
3. No idea whatyou're talking about with "size of .NET apps". I've found
managed apps to often be smaller binaries that comparable unmanaged
applications.

[SNIP]

So there are ways to make the total size of the "runtime" dependency files
that ship with an application packaged by .NET smaller?

Please, could you fill me in on the details?

Thanks in Advance...

--
Timothy Casey GPEMC! >> 11950 is the (e-mail address removed) 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover the most advanced speed comprehension application at:
www.fieldcraft.biz/shop <BRef http://www.fieldcraft.biz/ki.htm >

 

[Guest]

Most of the people going for these would not know

what a .NET Framework is, nor would they be
remotely interested in finding out.

But if your site said "this application requires that you also install
Software Package X available from Microsoft" and gave them a link they'd
understand that. It doesn't take too much to understand a prerequisite.

So perhaps I am headed for hot water... :^)

No, I think that a lot of developers are running into this same issue. For
now your users will have to live with the possible prerequisite download or
you'll have to use another development environment. True, it's not ideal,
but there aren't a lot of other options. Since you offer CDs as well as
downloads maybe you can provide the framework in that distribution.

-Chris

 

[Guest]

So if I package shareware for XP SP2 & above without the framework, are

there any guidlines on what can I leave out of the packages?

Just deploy your app and any DLLs you made or referenced that wasn't part of
the framework. Like I said before these will be small - often smaller than
functionally comparable apps in another language. You'll find that your new
install packages for those customers will be much smaller than for VB.

 

[Jim Cooper]

It's all for the non-technical public.

OK, so you have a challenge. Either use .NET and make it easy for them
to install the framework, should they need it, or don't use .NET now,
but bite the bullet later when you need to migrate your software over.

You could write in a language that supports both native Windows and
..NET. That can make the migration easier (Delphi allows this, for
example, and migration can be fairly painless if you don't use too many
third-party components).

So perhaps I am headed for hot water... :^)

You need to make a decision, yes Maybe someone else has more
details, but I would have thought it was more likely for people with
more recent Windows OSes to already have .NET installed. If you have any
idea from browser stats who your customers are, that might help guide
your thinking.


Cheers,
Jim Cooper

__________________________________________

Jim Cooper (e-mail address removed)
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
__________________________________________