Stop it…

[Yzöwl]

I'm probably alone here, but stop it…You're, making HFSLIP into bloatware.

Do you intend to continue with the idea of ini files and adding functionality to allow everything possible to be included in the CD-ROM.

Since the turn of the year, in my opinion, this project seems to have become too much!

Can you produce a version of the script for just slipstreaming hotfixes and service packs!

Edited May 10, 2006 by Yzöwl

[x-pert]

I'm with Yzöwl - just make one more oldschool HFSLIP

[Tomcat76]

TommyP is the boss so I won't speak on his behalf.

If you want my opinion... I'm gonna say the same thing the Opera browser devs reply to comments about Opera turning into "bloatware"...

1) We're talking of a ~140kb text file

2) When you include just hotfixes and a service pack, HFSLIP still just processes those and nothing else; the added functionality doesn't slow everything down when it's not used

[Camarade_Tux]

If HFSlip was becoming bloatware, I would probably leave it.

But IMO it is far from that.

That's true I only started playing with HFSlip recently but I don't see the bloat : you don't have a button corresponding to features you don't use, HFSlip is not slower...

Also, I think features such as HFCleanup, HFAnswer, ... do not need thousands of line of code; they are not preventing updates for MS updates.

[Super-Magician]

I'm with Tomcat on this one!

Windows takes almost no time at all parsing a few thousand lines of script. It does not slow does the process.

I guess you could make an old-school HFSLIP and one with additional functionality, but then you'd have to update both of them, and it's probably too much work.

[Delprat]

Why not using CalmiraXP instead of HFSLIP ?

[Kramy]

I like where HFSLIP is going. It's almost a totally viable alternative to nLite, and it this rate it will be within a few months.

I googled CalmiraXP...first result: Computing.Net - CalmiraXP ARGH!!!

[tommyp]

Around this time last year, I was calling the script "slipstreamer". I emailed FDV out of the blue asking if he could host the file. I figured it was a perfect -and- ironic mix. It was a script where the user had the choice of either slipstreaming IE6 -or- removing IE all together. It was a strange request, but FDV liked the idea. He asked for some catchy name. I thought about it over a smoke, and said HFSLIP, as in HotFixSLIPstreamer. All I wanted was a lightweight hotfix slipstreamer. Once NLITE didn't honor some requests that I had for about a year, I came up with HFCLEANUP to reduce my source. This fit all my needs. As we all see, over the past year, it does far more than intended. I am nearing the opinion that it is getting a bit bloated too, and I prefer that no additional features get added. It's getting waaaaaay beyond the scope of the project. As a surprise to many of the readers, I'm on Yzowl's side on this one.

Lately, I've been thinking. Some of my dislikes the past few months.

1. Alternate expand utility. This brought me over the top. It was like Coca Cola changing their recipe after 100 years. The main dislike I have now after viewing the code is useage of the alternate windows expand file. I see absolutely no reason why to use the alternate version. Right now, the script looks awefully messy with all the %expand% variables, and I would prefer to see it the way HFSLIP was intended, using as many built in windows applications as possible. If the end user of hfslip is knowledgeable enough to use an alternate expand utility, they should be smart enough to put the file in their win\sys32 directory. Heck, you could even make hfslip copy the file from hftools to the sys32 folder! However, if the masses (not one or two people) prefer the alternate expand utility, then I'll have to rethink my opinion. Hopefully TC will adjust this accordingly. I just would like a clean script.

2. Application Add Ons.

I know lots of people love them and some dwell on them. I hate them. I knew from the start that they would be bad news. You are entrusting people with preparing and hosting error-free add-ons. If there was any error in the add-ons, then the installation just-won't-work. As evident in the past two months or so, some of the fixes is due to modifying the script to accept these addons. However, a majority of the posts in the hfslip forum seem to be because of faulty addons. This isn't HFSLIP's fault. If I were an outsider trying to make a decision on whether or not to use hfslip, I'd read horror stories about these addons and get instantly turned off. I don't want to turn off new users. Maybe the add-on script can be removed and placed into the HFTOOLS as a separate entity? Maybe make a specific hfslip-aao integrator subforum? I don't know.

3. Worthless Windows Updates.

It astounds me why people are gung ho that equate "recommended updates" with critical updates. These recommended updates typically add files to your installation CD. If there are crazy files to add, then the script needs code inserted. It drives me crazy when I see posts about this. Case in point, the latest round of updates. People download the file and don't bother reading the KB article. The article says something along the lines that if you have both flash 6 is installed AND Adobe installed, then you should apply the update. Sometimes reading things helps, people have been reading for centuries. This leads to the next item...

5. Reading directions. For some reason or another, people are brain dead sitting in front of PCs. They don't read and they expect things to be served on a silver platter. Sounds great, but unfortunately, I'm a pleb and have no platters to pass out. True the general instructions aren't up to snuff now, but 95% of the problems are from people who don't RTFM. They are prompted on the screen on what to do if something happens, what goes where. Usually I feel like a skipping record asking for log files when people report issues. Thanks to super magician, I don't have to do this now. (Thanks super, you're a lifesaver!) Would you know that most of the fixes last year was to id*** proof the script. I may have missed stuff though. BTW, if anyone reads the script code, you'll notice a variable called AHTEST. I won't say what the total meaning is behind it, but all I'll say is the 2nd word is HOLE. So you could see my frustration waay back then too.

On a sidenote, I've been running the standard HFSLIP, with hotfixes, ie6 integration, directx, codecs, hfcleaup and a slew of regedits. I steer clear of the obnoxious and unpredictable add-ons and other worthless programs. Results? I've been error-free.

In closing being a cmd script, there aren't many additional utilities required for the script to run, so it still is relatively lightweight. But like I said, the script is getting way beyond the scope of the project. My vote is to keep it lightweight and request no more additions. KISS is the name of the game with this project.

(sorry if I offended anyone)

[Tomcat76]

Thanks for the info.

A quick note on #1...

HFSLIP actually only accepts the default EXPAND.EXE that comes with Windows. The "fix" you see is NOT to accept alternate versions of EXPAND.EXE.

There are people who have "updated" the EXPAND.EXE file with another (non-Microsoft) version that doesn't understand the switches we use. Since we're into replacing files ourselves (just look at the long list on FDV's page), I figured it would be nice to accept the fact that people replace it and to offer them a way around it without the need to put the Microsoft EXPAND.EXE in its original location (overwriting the alternate version). At first, HFSLIP only looked for it in the HFTOOLS folder but now these people can place it anywhere they like (provided they enter the correct path in the answer file).

In other words, the only thing that changed is that HFSLIP allows people to have the NORMAL version of EXPAND.EXE in a different place than the default.

On the rest...

It's doable to turn some things into external "addons"... Hehe. But if I have to choose between having people download 20 HFSLIP plugins into the HFTOOLS folder on the one hand and having a second, "lightweight" version on the other hand... I'd pick the latter.

[Yzöwl]

tommyp, you've practically read my mind, I decided not to say a lot of what you said, for fear of specifically upsetting you; I thank you for your honesty.

I still think that the script does a super job, and definitely know of nothing better, for performing it's original tasks.

As most of you probably know I love batch scripts, I've re-written this one many times in order to attempt to keep it relatively 'modular', and suit my specific uses but even for my version it is starting to get out of hand.

I know there are people who need everything given to them on a plate, for them though there is nLite, HFSLIP was unbloated, most knowledgeable non-scripters were capable of altering it sufficiently to perform their custom required tasks. Now it has become bloated, when I say bloated I don't mean the number of lines of code; that has, with the help of others improved where needed. It is including specialist items, taking our choices away from us. Without choices we may as well have a compiled executable with many options, just like nLite.

Most of us preferred HFSLIP over nLite because we wanted to have some control, I personally want to keep a degree of control.

What I would like to see, is the project to keep updating the script with slight improvements and any pertinent changes due to new hotfixes etc. I would also like to see maybe a sub-project, for those who want all the bells and whistles added, maybe a call to a new script, but using the original as the core would work better for all.

[tommyp]

Methinks Yzowl and I are on the same page. I kind of prefer the external add-ons too. TC - how hard is it to move the add-ons to run from the hftools instead?

[Tomcat76]

I don't think it would be difficult but I'd suggest a different folder (eg, HFext). That would allow people to write their own CMD plugins and give them the power to name the files as they please. Or, if the HFTOOLS folder really needs to be used, a standard naming convention such as HFSLIP*.CMD should be maintained so they can be easily filtered out. We could maybe "expand" it with a way to let people integrate plugins at three stages: beginning, mid & end... if that would be of any use.

[Super-Magician]

Usually I feel like a skipping record asking for log files when people report issues. Thanks to super magician, I don't have to do this now. (Thanks super, you're a lifesaver!)

You're welcome ! By the way, you missed a #4.

What I would like to see, is the project to keep updating the script with slight improvements and any pertinent changes due to new hotfixes etc. I would also like to see maybe a sub-project, for those who want all the bells and whistles added, maybe a call to a new script, but using the original as the core would work better for all.

I like this idea. Now that I've read tommyp's list of info and yours, I'm starting to lean the other way. The script does seem to have become a little bit bloated lately, with addition after addition (not that I don't appreciate your work, of course, Tomcat !). Edited May 11, 2006 by Super-Magician

[Kramy]

Hey tommyp, why did you skip #4?

As for #2, this may interest you... http://www.msfn.org/board/index.php?showtopic=73008&st=0

I say keep HFAAO, since I have some scanner drivers in a compressed exe that I'm unable to unpack.

Now, for this bloat...I don't think it's bad, since I'm able to make modifications where needed. A plugin script system seems even more bloatish, but since I'm a fan of Azureus you won't get any complaints from me. If it hasn't been done already, you could shuffle some of the core code around I suppose, though I can't offer suggestions on how that would make it more manageable.

What I do suggest is putting a commented index of everything that happens at the top of the file, in order of it happening, with indents if things depend on other things. This would allow anyone with a half-decent text editor(which most of us have) to find relevant parts rapidly, while having no prior knowledge of where anything is. It would also be easily updatable, and any of us could check it when opening a new version to see that HFCLEANUP's execution point was moved, etc..

[fdv]

FDV peeks out from behind the scenes

I used to have fantasies that one day, the documentation would be largely unchanged

Feature-Creep has been the bane of my reading this forum of late. Skip one day and it seems like you miss both mention of a new feature as well as how it works... so I long for some stability, but for different reasons.

I know from using Linux that documentation can sometimes make or break projects. Good documentation is what attracts new people and allows the vets to double-check everything, and we were starting to get out of balance. I want to thank tommyp for giving me a proofreading every now and again and sending me a markup with changes. Documentation's really the gateway to using HFSLIP.

BTW, for the curious, tommyp's paragraph #4 was a description of the process of creating HFSLIP. Tomcat76 uploads the code and TP and I watch it scroll on a 10 foot by 15 foot monitor in the HFSLIP Lab. It's usually late on our end, like 11pm, so while we're smoking cigars dipped in Cognac, TC is completely toasted at 4am several timezones away... With a lampshade over his head, some bimbo in the background bugging him about "die Musik bitte ändern, dieses bildet mich verrückt!" Ah, good times, good times. We never get much done though with all that bourbon around.