I think chm is better than hlp format,can you make masm32.chm
instead of masm32.hlp?
Posted on 2002-04-27 21:16:38 by purefiring
In short, no, CHM are larger files that load slower, would increase the size of the distribution and offer no technical advantage.


Posted on 2002-04-27 23:47:25 by hutch--
So I guess distributing all the help documents as uncompressed screen-capture bitmaps is out of the question...
Posted on 2002-04-28 00:11:14 by iblis
I'd prefer if they were first printed (on a color printer), and then scanned at a resolution of at least 38400 DPI. ;)

As file format, something like BMP (uncompressed). :grin:
Posted on 2002-04-28 04:29:05 by Maverick
Interestingly enough, if you save bmp images in SHG format for the help file, the size comes down noticably. You can also create links to other parts of the file if you use the SHED.EXE SHG editor that comes with the sdk.


Posted on 2002-04-28 04:42:52 by hutch--
The thing I find most annoying with those old help formats is they dont support the mouse wheel.
Posted on 2002-04-28 04:44:24 by NaN
Nor does it support a text search in the current topic.

I did a quick test and the htmlhelp version of it was 100kb without full text search, but 150 with full text search. However the conversion was not done very well, colors were missing and there was an empty line between every two lines.

I agree they load a little slower but imho they have a lot of advantages.

Posted on 2002-04-28 04:55:49 by Thomas
size matters with the current state of masm32, don't forget that :|
Posted on 2002-04-28 05:59:38 by Hiroshimator

size matters with the current state of masm32, don't forget that :|

Yes, correct. I run the mirror in Germany for masm32 package and got 1095 MB traffic since it's offical (~1 week). We must have a great number of ASM coders now :)
Posted on 2002-04-28 06:30:34 by bazik
Without mentioning any names, another contributor to this thread went on record as saying that his GF thinks the size DOES matter but I guess that in the context of help file size that the criterion is perhaps different.

I have always been aware of the problems of size with the distribution of MASM32 and now that the demand is so great with people learning assembler, the problem has become multifold.

I can think of a few ways to decrease the size some but I don't want to end up in the situation where a new user cannot find a single coherant package that they can install and get running without major problems.

My main problem at the moment is how to introduce the next service pack as there is a reasonable amount of stuff that has been written by various people that needs to be made available, I have to upgrade Prostart because it has a small error in it, a collection of different library modules and I am working on a new code wizard for dialogs at the moment that is coming along OK.


Posted on 2002-04-29 00:54:17 by hutch--
Size does matter but performance does too...
HLP files were *plain fun* in good old win3.1 days, but now, I think it is useless to be stuck with old standards (especially when, as NaN mentionned it, these "standards" do not support the mouse wheel, which is essential to browse a help file efficently...)

Well, Platform SDK comes in CHM... some of us still use an outdated win32.hlp file, which is somewhat slow compared to chm...

A simple to use help is a something useful in a programming package and inefficient/outdated format is not really the solution to encourage beginners to read the docs...

Just my two ?.
Posted on 2002-04-29 01:08:36 by JCP
CHM... What he did for Icz tutes made it even more fun to read over AGAIN and AGAIN... one more ounce can't hurt.

Year 2002

Posted on 2002-04-29 01:37:17 by cmax

TXT files kick ***... you can search they, open they in any OS, to everything you want.

and soon, with all these fancy file format thingies, they will be smaller, even uncompressed, than the others formats :)

Posted on 2002-04-29 07:50:22 by ancev
At this very moment I'm more inclined to follow ancev's point of view then go towards .chm format. Due to the package size and the unexpected number of users (which is very nice for hutch :) ) the size of the package is starting to become a big problem bandwidth wise.
Imagine having 3000 downloads a month (in reality it's more) and multiplying that with the size of the package (5MB), that alone gives you 15G of already compressed binary data. (and remember in reality it's more).
So you see that we have to think of a good way to shave of some wheight (the more the better) without loosing functionality :|
Posted on 2002-04-29 10:55:24 by Hiroshimator
Maybe MASM32 should be fragmented with a more dynamic installation engine. :)
Posted on 2002-04-29 11:00:28 by bitRAKE

All I need at the moment is a less than easy installation that results in being mailbombed with installation inquiries. The earlier versions were partly manual installation and it generated an enormous amount of email with enquiries about how to make the package work properly.

As long as it comes as one coherant package, the installation errors are almost negligible which keeps most 1st time users happy and keeps my email down to a reasonable level.

The biggest single component of the package is the libraries and I have been tempted to edit which ones are used in the package to save the download size as many do not contain any API functions at all and they are usually the biggest ones.



PS : Hiro, last I knew it was about 60 gig a month and climbing so on the upside of the bandwidth problem, it seems we have many more assembler programmers in the making.
Posted on 2002-04-29 17:45:00 by hutch--
have you heard of vdat?!
it was a project maintained by a single guy to provide the most if not all the important articles about the virus scene ..
insted of making the masm32 pakage contains everything someone could maintain the docs and tutorials and all that is worth in a single package thus cutting the size of the masm32 package and in the same time gives the opertunity to include more docs ...
hutch doesn't need to make a huge package ... his work is great and we should help him keep up the good work ... it would be better if someone else takes the resposiblitly of all the documetation and help files in hutch's package and provide them as another downloadable package ... this package can then be a chm file or anything else ... I would love to help with this but I'm still a newbie ...:tongue:
PS: keep up the good work guys ... you are a source of insperation ...:alright:
Posted on 2002-04-30 01:43:22 by code1101
Perhaps the (import) libraries could be generated dynamically from
text files (that would compress better)? I think lcc-win32 does this,
perhaps jacob's tool to do it can be borrowed :).
Posted on 2002-04-30 04:50:31 by f0dder
I say up the standards, and impose a little on the various mods/users around here. Its been quite obvious that we are willing to provide web space to mirror Iczelion's site, as well as mirror the Masm32 package.

My sugestion is to break the package down into compressed fragments, and distribute the fragments on different sites.
At hutch's page, simply host a 'download' utility that will retrieve the various package pieces from different sites.

This will distribute the Bandwidth, as well allow the user to decide what 'parts' he may want, ie) masm32 bin directory has been pretty static over the last few releases. etc. etc.

Just an 'oustide the box' type idea. Doesnt mean its correct in anyway. ;)

Posted on 2002-05-02 18:00:20 by NaN
Hutch can maintain his package anyway he wants.

It's up to the users to decide, for additional support materials. Maybe Que will do a book on MASM32.

Then provide as an option, additional support materials, that don't necessarily need to be in the release package.

Just a thought, P1
Posted on 2002-05-03 10:28:01 by Pone