VM question
Locked
 
|
The VW virtual machine for win32 platform comes in two flavors i.e
single executable -- Visual.exe or executable and library VWnt.exe + vwntoe.dll I vaguely remember some discussion on the advantages of running exe with dll versus single EXE. Can anybody shed a light on the differences and advantages or disadvantages of each ? TIA --Mark |
|
|
The difference is in DLLCC. The .exe/.dll combination works correctly for the OE and UserPrim APIs, the single .exe does not.
On Wed, Feb 20, 2008 at 6:38 PM, Mark Pirogovsky <[hidden email]> wrote: The VW virtual machine for win32 platform comes in two flavors i.e |
|
|
I use DLLCC (mostly for Gemstone) -- I don't have any UserPrim things so far as I know. Eliot Miranda wrote: The difference is in DLLCC. The .exe/.dll combination works correctly for the OE and UserPrim APIs, the single .exe does not. -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@... Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP |
|
|
In reply to this post by Mark Pirogovsky-3
I'm not the expert,
but maybe this is better than nothing, and hopefully basically in the right
direction even if some of the details aren't right:
For production
versions of shrink-wrapped software, I'd say use visual, with the image
compressed and added as a resource with the tools from packaging\win. That gives
a single .exe, which is smallest and easiest for users. Use vwnt when you want
to have C programs make low level calls to the VM (the OE API, which I think
hardly anyone uses), or if you're writing your own user primitives (which at
least earlier involved recompiling the VM), or if you want to have slightly more
information in the event of a VM crash (the symbols, i.e. C function names, are
stripped from visual.exe, so a debugger can't tell you where it crashed other
than a memory location).
Steve
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Dennis smith-4
Dennis Smith wrote:
> Can someone indicate when we should be using vwnt instead of visual then?? > I use DLLCC (mostly for Gemstone) -- I don't have any UserPrim things so > far as I know. I believe that the general rule is to use vwnt unless you absolutely must save a few hundred K of disk space. I'm unaware of any other advantage of the stripped visual.exe. Regards, -Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Mark Pirogovsky-3
Martin's right in that the "general rule" is the advice I've heard too.
But I'd disagree that "15" counts as "a few" :-). visual.exe is 630KB, vwnt.exe + DLL is 2170KB. Simpler deployment is also a plus for visual.exe, in particular with a reshack'ed image. When using ResHacker, Cincom's WindowsPackaging only mentions visual.exe - no doubt because ResHacker reduces the number of files, and imageCompress reduces the size, so they and visual.exe are useful in the same situations. The smaller size of visual.exe also may improve startup times: less to read from the disk. To look at things another way, if you don't need UserPrims or the OE API, I'm unaware of any advantage of vwnt.exe. For no advantage, it's hard to justify adding an extra file and 1.5MB to a product, and possibly slowing it down at startup. Steve > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Martin McClure > Sent: 22. helmikuuta 2008 1:05 > To: Dennis Smith > Cc: [hidden email] > Subject: Re: [vwnc] VM question > > > Dennis Smith wrote: > > Can someone indicate when we should be using vwnt instead of visual > > then?? I use DLLCC (mostly for Gemstone) -- I don't have > any UserPrim > > things so far as I know. > > I believe that the general rule is to use vwnt unless you absolutely > must save a few hundred K of disk space. I'm unaware of any other > advantage of the stripped visual.exe. > > Regards, > > -Martin > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Hello,
For smaller apps and perhaps slightly faster startup times, you may want to try attaching an uncompressed image to visual.exe, and then compressing the file with UPX. http://blogten.blogspot.com/2007/04/tighter-vw-exe-distributions.html For the Smalltalk Solutions 2007 Coding Contest, the resulting .exe file packed with UPX was smaller than a .zip file of the VM and the image. Andres. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Steven Kelly Sent: Thursday, February 21, 2008 4:55 PM To: Dennis Smith Cc: [hidden email] Subject: Re: [vwnc] VM question Martin's right in that the "general rule" is the advice I've heard too. But I'd disagree that "15" counts as "a few" :-). visual.exe is 630KB, vwnt.exe + DLL is 2170KB. Simpler deployment is also a plus for visual.exe, in particular with a reshack'ed image. When using ResHacker, Cincom's WindowsPackaging only mentions visual.exe - no doubt because ResHacker reduces the number of files, and imageCompress reduces the size, so they and visual.exe are useful in the same situations. The smaller size of visual.exe also may improve startup times: less to read from the disk. To look at things another way, if you don't need UserPrims or the OE API, I'm unaware of any advantage of vwnt.exe. For no advantage, it's hard to justify adding an extra file and 1.5MB to a product, and possibly slowing it down at startup. Steve > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Martin McClure > Sent: 22. helmikuuta 2008 1:05 > To: Dennis Smith > Cc: [hidden email] > Subject: Re: [vwnc] VM question > > > Dennis Smith wrote: > > Can someone indicate when we should be using vwnt instead of visual > > then?? I use DLLCC (mostly for Gemstone) -- I don't have > any UserPrim > > things so far as I know. > > I believe that the general rule is to use vwnt unless you absolutely > must save a few hundred K of disk space. I'm unaware of any other > advantage of the stripped visual.exe. > > Regards, > > -Martin > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Steven Kelly
On Thu, Feb 21, 2008 at 4:54 PM, Steven Kelly <[hidden email]> wrote: Martin's right in that the "general rule" is the advice I've heard too. There are two main advantages. 1. vwnt.dll has debug symbols (this is a huge plus when you get bit). 2. there are two .exe's, vwnt.exe and vwntconsole.exe. The latter is a console app and will run in a console window, reading/writing stdin/stdout, and hence enabling scripting Further, vwnt.exe does work (ok, should work) with ResHack. IMO, in these days of DSL and large hard drives visual.exe is an anachronism. Steve _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Mark Pirogovsky-3
Is that still useful
for shrink-wrapped production software? Or only if the user can run a debugger
when the Windows crash dialog appears? When we have VM problems, we switch to
using the debug VM anyway. Fortunately such problems are rare on Windows - I
don't remember any offhand with the 7.4d VMs we're using.
vwntconsole.exe is great, although I think that for Dennis, he'd probably
know already if he needed it :-)
Good to know (ok, would be good to know ;->)
IMHO, it's a
powerful statement against global warming and wasteage of natural resources :-).
Our competitors apparently follow your thinking to the bitter end, and
their download is over 3GB; ours is 20MB. This is only one small factor in
comparing products, admittedly, but I'm grateful that you kept making visual.exe
when I asked, and that Cincom continue to make it.
Steve
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Eliot Miranda-2
Eliot Miranda schrieb:
> IMO, in these days of DSL and large hard drives visual.exe is an > anachronism. Not for shrink-wrapped products. There are good reasons for packing everything in a single executable. Deploying an extra DLL is not an option for downloadable updaters. It also complicates the use of copy protection envelopes that use self-encrypting executables and anti-debugging measures. The executable is only one component of a product. Usually there are many more files and documents that come along with a download, so each component should be a small as possible. My products for example are almost 16MB (zipped), although the main executable is only 600k. The bandwidth and hard disk excuse that comes up frequently is just that: An excuse. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Eliot Miranda-2
These discussions are great for learning things about the product --
and they
even answer the original question too :) Thanks to everyone. Eliot Miranda wrote: The difference is in DLLCC. The .exe/.dll combination works correctly for the OE and UserPrim APIs, the single .exe does not. -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 [hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Andre Schnoor
Thanks for everyone who contributed to this thread.
I have some crazy Idea. About the vwnt.exe and DLL. The big size of the dll was a contention point for many , me included. But there are some distinct advantages of using the DLL. How difficult it is to compile a DLL without the maps and debug symbols ? without those,the size of the EXE +DLL will be just few kB bigger then single visual.EXE. Actually it might give an additional advantage to the downloads and updates. Remember the 7.4 VM ? in the space of 5 month we had 4 releases a,b, c,d. Now if I were to update the single EXE product -- for me it would be 3 downloads of 7 MB for each of the users. if I did deploy as EXE +dll then I probably would had 3 download of 0.7 mb (dll only) - clearly 10 times reduction. Andre Schnoor wrote: > Eliot Miranda schrieb: >> IMO, in these days of DSL and large hard drives visual.exe is an >> anachronism. > > Not for shrink-wrapped products. There are good reasons for packing > everything in a single executable. Deploying an extra DLL is not an > option for downloadable updaters. It also complicates the use of copy > protection envelopes that use self-encrypting executables and > anti-debugging measures. > > The executable is only one component of a product. Usually there are > many more files and documents that come along with a download, so each > component should be a small as possible. My products for example are > almost 16MB (zipped), although the main executable is only 600k. > > The bandwidth and hard disk excuse that comes up frequently is just > that: An excuse. For somebody outside US or Western Europe the size of the downloads is a big problem actually > > Andre > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Andre Schnoor
Thanks for everyone who contributed to this thread.
I have some crazy Idea. About the vwnt.exe and DLL. The big size of the dll was a contention point for many , me included. But there are some distinct advantages of using the DLL. How difficult it is to compile a DLL without the maps and debug symbols ? without those,the size of the EXE +DLL will be just few kB bigger then single visual.EXE. Actually it might give an additional advantage to the downloads and updates. Remember the 7.4 VM ? in the space of 5 month we had 4 releases a,b, c,d. Now if I were to update the single EXE product -- for me it would be 3 downloads of 7 MB for each of the users. if I did deploy as EXE +dll then I probably would had 3 download of 0.7 mb (dll only) - clearly 10 times reduction. Andre Schnoor wrote: > Eliot Miranda schrieb: >> IMO, in these days of DSL and large hard drives visual.exe is an >> anachronism. > > Not for shrink-wrapped products. There are good reasons for packing > everything in a single executable. Deploying an extra DLL is not an > option for downloadable updaters. It also complicates the use of copy > protection envelopes that use self-encrypting executables and > anti-debugging measures. > > The executable is only one component of a product. Usually there are > many more files and documents that come along with a download, so each > component should be a small as possible. My products for example are > almost 16MB (zipped), although the main executable is only 600k. > > The bandwidth and hard disk excuse that comes up frequently is just > that: An excuse. For somebody outside US or Western Europe the size of the downloads is a big problem actually > > Andre > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] VM question
|
|
100 users x 21MB = 2.1GB
2.1GB x $0.18* = $0.39 1,000 users x 21MB = 21GB 21GB x $0.18* = $3.78 100,000 users x 21MB = 2,100GB 2,100GB x $0.18* = $378.00 * http://tinyurl.com/yodrgk ... and this isn't even the cheapest bandwidth around. You could buy 1TB of short-path bandwidth from Media Temple for $20/month. Where is a problem? -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf > Of Mark Pirogovsky > Sent: Friday, February 22, 2008 10:32 AM > Cc: [hidden email] > Subject: Re: [vwnc] VM question > > Thanks for everyone who contributed to this thread. > > I have some crazy Idea. About the vwnt.exe and DLL. The big size of > the dll was a contention point for many , me included. But there are > some distinct advantages of using the DLL. > > How difficult it is to compile a DLL without the maps and debug > ? without those,the size of the EXE +DLL will be just few kB bigger > then single visual.EXE. > > Actually it might give an additional advantage to the downloads and > updates. Remember the 7.4 VM ? in the space of 5 month we had 4 > releases a,b, c,d. Now if I were to update the single EXE product -- for > me it would be 3 downloads of 7 MB for each of the users. if I did > deploy as EXE +dll then I probably would had 3 download of 0.7 mb (dll > only) - clearly 10 times reduction. > > Andre Schnoor wrote: > > Eliot Miranda schrieb: > >> IMO, in these days of DSL and large hard drives visual.exe is an > >> anachronism. > > > > Not for shrink-wrapped products. There are good reasons for packing > > everything in a single executable. Deploying an extra DLL is not an > > option for downloadable updaters. It also complicates the use of > > protection envelopes that use self-encrypting executables and > > anti-debugging measures. > > > > The executable is only one component of a product. Usually there are > > many more files and documents that come along with a download, so each > > component should be a small as possible. My products for example are > > almost 16MB (zipped), although the main executable is only 600k. > > > > The bandwidth and hard disk excuse that comes up frequently is just > > that: An excuse. > > For somebody outside US or Western Europe the size of the downloads is a > big problem actually > > > > > Andre > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Mark Pirogovsky-3
The point isn't whether it matters, it's whether there are people who
think it matters. If our set of potential customers includes those people, we're better off if we can satisfy them (ceteris paribus). Steve > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Boris Popov > Sent: 23. helmikuuta 2008 1:15 > To: [hidden email] > Cc: [hidden email] > Subject: Re: [vwnc] VM question > > > 100 users x 21MB = 2.1GB > 2.1GB x $0.18* = $0.39 > > 1,000 users x 21MB = 21GB > 21GB x $0.18* = $3.78 > > 100,000 users x 21MB = 2,100GB > 2,100GB x $0.18* = $378.00 > > * http://tinyurl.com/yodrgk > > ... and this isn't even the cheapest bandwidth around. You > could buy 1TB of short-path bandwidth from Media Temple for > $20/month. Where is a problem? > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the > message header. Unless otherwise indicated, it contains > information that is private and confidential. If you have > received it in error, please notify the sender and delete the > entire message including any attachments. > > Thank you. > > > -----Original Message----- > > From: [hidden email] [mailto:[hidden email]] On > Behalf > > Of Mark Pirogovsky > > Sent: Friday, February 22, 2008 10:32 AM > > Cc: [hidden email] > > Subject: Re: [vwnc] VM question > > > > Thanks for everyone who contributed to this thread. > > > > I have some crazy Idea. About the vwnt.exe and DLL. The > big size of > > the dll was a contention point for many , me included. But > there are > > some distinct advantages of using the DLL. > > > > How difficult it is to compile a DLL without the maps and debug > symbols > > ? without those,the size of the EXE +DLL will be just few > kB bigger > > then single visual.EXE. > > > > Actually it might give an additional advantage to the downloads and > > updates. Remember the 7.4 VM ? in the space of 5 month we had 4 > > releases a,b, c,d. Now if I were to update the single EXE product -- > for > > me it would be 3 downloads of 7 MB for each of the users. if I did > > deploy as EXE +dll then I probably would had 3 download of > 0.7 mb (dll > > only) - clearly 10 times reduction. > > > > Andre Schnoor wrote: > > > Eliot Miranda schrieb: > > >> IMO, in these days of DSL and large hard drives visual.exe is an > > >> anachronism. > > > > > > Not for shrink-wrapped products. There are good reasons > for packing > > > everything in a single executable. Deploying an extra DLL > is not an > > > option for downloadable updaters. It also complicates the use of > copy > > > protection envelopes that use self-encrypting executables and > > > anti-debugging measures. > > > > > > The executable is only one component of a product. > Usually there are > > > many more files and documents that come along with a download, so > each > > > component should be a small as possible. My products for > example are > > > almost 16MB (zipped), although the main executable is only 600k. > > > > > > The bandwidth and hard disk excuse that comes up > frequently is just > > > that: An excuse. > > > > For somebody outside US or Western Europe the size of the > downloads is > a > > big problem actually > > > > > > > > Andre > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Steven Kelly wrote: Its not just cincom clients who matter, its cincom's clients' clients.The point isn't whether it matters, it's whether there are people who think it matters. If our set of potential customers includes those people, we're better off if we can satisfy them (ceteris paribus). Being a S/W provider we often run into strange issues. People who would rather pay us and/or system support companies many$ when adding a bit of memory or disk for much less$ would solve the problem. So yes, although we don't have this specific issue, I can see how it can matter. We just had a prospective client show wanted to save $3000 on a linux server (for gemstone) and was willing to pay us to change our standard requirements, pay an unspecified amount -- he should have gone with the fixed $3000! Steve-----Original Message----- From: [hidden email] [[hidden email]] On Behalf Of Boris Popov Sent: 23. helmikuuta 2008 1:15 To: [hidden email] Cc: [hidden email] Subject: Re: [vwnc] VM question 100 users x 21MB = 2.1GB 2.1GB x $0.18* = $0.39 1,000 users x 21MB = 21GB 21GB x $0.18* = $3.78 100,000 users x 21MB = 2,100GB 2,100GB x $0.18* = $378.00 * http://tinyurl.com/yodrgk ... and this isn't even the cheapest bandwidth around. You could buy 1TB of short-path bandwidth from Media Temple for $20/month. Where is a problem? -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you.-----Original Message----- From: [hidden email] [[hidden email]] On -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 [hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] VM question
|
|
In reply to this post by Mark Pirogovsky-3
Let me put it this way, people who update software on their machines are used to constantly downloading 10s of megabytes of stuff without really thinking about it, so why is it that we seem to be coming back to this issue every once in a while? I don't think I have had a single complaint from an end user about the size of the updates in my whole career. Think about the last adobe acrobat update you installed, it was probably more than 20 megs, now think of windows updates, mac os patches and such and decide if you'd rather have cincom spend their cycles on improving the product than on making it marginally smaller. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
On Feb 23, 2008, at 12:15 AM, Boris Popov wrote: > You could buy 1TB > of short-path bandwidth from Media Temple for $20/month. Where is a > problem? In Africa. R - > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] VM question
|
|
In reply to this post by Mark Pirogovsky-3
Oh don't go all philosophical on me now ;) _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
Boris,
You may not get any complaints, but I do. It definitely does matter in some markets. Many people are very sensitive to the size of software, and in the case of my own customers they get very critical of large distributables. People in the BASIC and C, and Pascal, etc. programming (ie. static compiler) traditions expect small code to produce small distributables. Smalltalk does not seem able to do this, and so no matter how cool it is it will not be accepted by some markets. I don't mind the large size of things too much, but my customers (and potential customers) care a great deal. Smalltalk should not strive for marginally smaller. It should be able to produce very small apps when the code is very small. Why else would Spoon be an interesting project? Cincom might even consider trying to hire Craig Latta to see if he can Spoonify VisualWorks. Me? I personally don't care if VisualWorks cannot produce a 50K runtime. A couple of MB would be good enough for my needs. When I told my customers that the next version of Liberty BASIC might be 5MB or more, you might be surprised at how many people said they wouldn't be upgrading. There is also the perception that there is either something wrong with Smalltalk or with the engineering staff at Cincom if they cannot produce a well partitioned and easily deployed system that contains only what is needed. After all, compiler vendors have been producing dynamic linkers for decades. I mean, get with the program Smalltalkers! is the attitude. Also, maybe it doesn't matter for your application how large your Seaside images are. Some people are really going to care about this because they are going to compare the memory consumption for different web tools. Well, that's my 2 cents (again). -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com ----- Original Message ----- From: "Boris Popov" <[hidden email]> To: <[hidden email]> Cc: <[hidden email]> Sent: Friday, February 22, 2008 7:38 PM Subject: Re: [vwnc] VM question > Let me put it this way, people who update software on their machines are > used to constantly downloading 10s of megabytes of stuff without really > thinking about it, so why is it that we seem to be coming back to this > issue every once in a while? I don't think I have had a single complaint > from an end user about the size of the updates in my whole career. Think > about the last adobe acrobat update you installed, it was probably more > than 20 megs, now think of windows updates, mac os patches and such and > decide if you'd rather have cincom spend their cycles on improving the > product than on making it marginally smaller. > > Cheers! > > -Boris (via BlackBerry) > > ----- Original Message ----- > From: [hidden email] <[hidden email]> > Cc: [hidden email] <[hidden email]> > Sent: Fri Feb 22 16:28:47 2008 > Subject: Re: [vwnc] VM question > > > > Steven Kelly wrote: > > The point isn't whether it matters, it's whether there are people who > think it matters. If our set of potential customers includes those > people, we're better off if we can satisfy them (ceteris paribus). > > > Its not just cincom clients who matter, its cincom's clients' clients. > > Being a S/W provider we often run into strange issues. People who would > rather pay us and/or > system support companies many$ when adding a bit of memory or disk > for much less$ would solve the problem. > > So yes, although we don't have this specific issue, I can see how it can > matter. > We just had a prospective client show wanted to save $3000 on a linux > server > (for gemstone) and was willing to pay us to change our standard > requirements, > pay an unspecified amount -- he should have gone with the fixed $3000! > > > > > Steve > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Boris Popov > Sent: 23. helmikuuta 2008 1:15 > To: [hidden email] > Cc: [hidden email] > Subject: Re: [vwnc] VM question > > > 100 users x 21MB = 2.1GB > 2.1GB x $0.18* = $0.39 > > 1,000 users x 21MB = 21GB > 21GB x $0.18* = $3.78 > > 100,000 users x 21MB = 2,100GB > 2,100GB x $0.18* = $378.00 > > * http://tinyurl.com/yodrgk > > ... and this isn't even the cheapest bandwidth around. You > could buy 1TB of short-path bandwidth from Media Temple for > $20/month. Where is a problem? > > -Boris > > -- > +1.604.689.0322 > DeepCove Labs Ltd. > 4th floor 595 Howe Street > Vancouver, Canada V6C 2T5 > http://tinyurl.com/r7uw4 > > [hidden email] > > CONFIDENTIALITY NOTICE > > This email is intended only for the persons named in the > message header. Unless otherwise indicated, it contains > information that is private and confidential. If you have > received it in error, please notify the sender and delete the > entire message including any attachments. > > Thank you. > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > > > Behalf > > > Of Mark Pirogovsky > Sent: Friday, February 22, 2008 10:32 AM > Cc: [hidden email] > Subject: Re: [vwnc] VM question > > Thanks for everyone who contributed to this thread. > > I have some crazy Idea. About the vwnt.exe and DLL. The > > > big size of > > > the dll was a contention point for many , me included. But > > > there are > > > some distinct advantages of using the DLL. > > How difficult it is to compile a DLL without the maps and debug > > > symbols > > > ? without those,the size of the EXE +DLL will be just few > > > kB bigger > > > then single visual.EXE. > > Actually it might give an additional advantage to the downloads and > updates. Remember the 7.4 VM ? in the space of 5 month we had 4 > releases a,b, c,d. Now if I were to update the single EXE product -- > > > for > > > me it would be 3 downloads of 7 MB for each of the users. if I did > deploy as EXE +dll then I probably would had 3 download of > > > 0.7 mb (dll > > > only) - clearly 10 times reduction. > > Andre Schnoor wrote: > > > Eliot Miranda schrieb: > > > IMO, in these days of DSL and large hard drives visual.exe is an > anachronism. > > > Not for shrink-wrapped products. There are good reasons > > > for packing > > > everything in a single executable. Deploying an extra DLL > > > is not an > > > option for downloadable updaters. It also complicates the use of > > > copy > > > protection envelopes that use self-encrypting executables and > anti-debugging measures. > > The executable is only one component of a product. > > > Usually there are > > > many more files and documents that come along with a download, so > > > each > > > component should be a small as possible. My products for > > > example are > > > almost 16MB (zipped), although the main executable is only 600k. > > The bandwidth and hard disk excuse that comes up > > > frequently is just > > > that: An excuse. > > > For somebody outside US or Western Europe the size of the > > > downloads is > a > > > big problem actually > > > > Andre > > _______________________________________________ > vwnc mailing list > [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > -- > Dennis Smith +1 416.798.7948 > Cherniak Software Development Corporation Fax: +1 416.798.0948 > 509-2001 Sheppard Avenue East [hidden email] > Toronto, ON M2J 4Z8 sip:[hidden email] > Canada http://www.CherniakSoftware.com > Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP > -------------------------------------------------------------------------------- > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |