Nan, the problem is that this imposement would be huge. I've thought about co-hosting the package here but after I heard of its bandwidth requirements I quickly dismissed that idea. It would shutdown the site in about 2 weeks or leave me with a very unpleasant bill :/

Paid sites have more bandwidth then free ones and juggling the package around various free sites will be a major pain :(
Posted on 2002-05-03 10:37:11 by Hiroshimator
I provided the German mirror for the masm32 package on 14.04.02.

Stats since upload of package:
Total connections to 1,276
Total bytes transfered: 1,539,338,772

I got 46 connections with 140 MB traffic only TODAY :)

But I have unlimited bandwith, so who cares :)
Posted on 2002-05-03 11:36:48 by bazik
I see your point, but i had in mind ~ 200kb ish packets or so per site.

As well some management would be needed for sure. Perhaps a master index for 'non maxed' freebee sites would reside on hutches page as well (which the download tool would use).

A second tool can be easily written to 'test' each site in the index to see if its bandwidth is up for the month, and then change the master index to point to the next (currently untouched and anonomous) site that hosts the same packet.

Place the packet on two sites, and i would guess it would make it thru a month...?

This is alot of work to get set up, i realize, but it would be a one every year type thing, (or until a site goes down) and the packet is moved to a new one. You get the idea.

Again just ideas... I would help, set up this, but im networking illiterate :rolleyes: .

BTW: Im not suggesting this elaborate scheme just to allow us to use .chm's, but rather so we can add more example stuff to the packages with less worry. (perhaps do this for the example's only and leave the 'static' stuff static on Hutch/Bazik's sites ?? )

Posted on 2002-05-03 15:19:37 by NaN
At hutch's page, simply host a 'download' utility that will retrieve the various package pieces from different sites.

Like what Cygwin does, right? That means the distribution schemes suggested above are being done already. So, just like some of the things asm programmers do, we are just trying to reinvent the wheel (and a better one, i hope). My point is, let's learn how the Cygwin compiler package does it and try to implement it.

Posted on 2002-05-03 22:41:05 by pixelwise
i would like to thank the various member for their suggestions but I am faced with presenting a single coherant package and fragmenting the package would be a serious mistake.

I have a number of modifications that i will do on the current MASM32 distribution package that will get its size down by about 1 meg which is a 20% bandwidth saving for no functional loss to the package but it means rewriting the distribution again to do it. (mutter)

Its not that the requests for different bits go unheard but when packages like Delphi, VC++, .NET, VB etc .... are often the size of a CD, there is a real difference in the size available to present the contents of the package.

A collection of CHM help file together with all the crap that goes with them would be bigger than the current distribution so I just don't have the luxury to do stuff that needs a CD to fit it on.

Posted on 2002-05-04 00:10:19 by hutch--
pixelwise, I didn't really like the cygwin installer all too much.
It's a good idea, but not very well implemented, and I fear that it
might be a bit too techie for "normal" users. Assembly coders ought
to be able to use something like it, but let's face it - even if hutch
has a warning on his site that assembly is for 'advanced programmers'
(or something to that effect), there *are* a lot of newbies using masm32.
Nope, I don't really see this as something wrong (it merely amuses me),
but it does mean the masm32 installer has to be easy to use.

Hutch, it should be possible to write a better and more advanced
installer... something like cygwin/platformsdk/whatever that downloads
only the bits&pieces you need. Of course this would have to be done
in a very well planned way, to make sure everybody can figure out how
to use it (and keep you from getting flooded with a zillion mails from
clueless users). It would be pretty neat if users could choose the parts
they need to download (I'm sure dialup users would appreciate this),
and even people on DSL probably would too (I'm only really interested in
the header files, as I have newer binaries&libs, and use other editors).

Now, if done well, the *really* neat thing about a better installer would
be only downloading the parts of the package that have changed. As already
mentioned before, the binaries have been pretty static during the last couple
releases, and while more examples have been included, the old examples haven't
been changed (well, at least not what I know of). So, on each new masm32
release, there'd be a "monolithic zip" (for new users), and a series of patches
for old users (the patches ought to go all the way back to the first "smart
release", so people could upgrade "smartly" even if they miss a couple of

Another advantage of a "smart installer" would be the ability to distribute
the load between multiple servers - keeping server load down, and possibly
enabled (very ;)) high bandwith users to download the package quickly.

Yes, this would have to be planned very well, programmed very well, designed
very well. But it can be done, and in the end would make life easier for
everyone (well, if done correctly ;)), and reduce bandwith and stuff.

As for

A collection of CHM help file together with all the crap that goes with them
would be bigger than the current distribution so I just don't have the luxury to
do stuff that needs a CD to fit it on.

... have you tried putting the exact same stuff in a .chm as in a .hlp?
Nobody says you have to put in tons of images, Active-X objects, (yadda
yadda) just because you can. Is there really a big size difference between
the hlp and chm formats? Both should be compressed, so... I guess somebody
ought to test.
Posted on 2002-05-04 01:25:19 by f0dder
I do respect Hutch's oppinions, but i have to say, f0dder said it better than i ;) . I too think it would be a better solution to fragment. Weather or not the all the fragments get distributed or remain on just Hutch's site is of less concern and can be left towards what Hutch's finds confortable.

Posted on 2002-05-04 19:40:00 by NaN