"Ritchie" <(E-Mail Removed)> wrote in message
news:blja8c$ct9ph$(E-Mail Removed)...
> "Bill Stewart" <(E-Mail Removed)_spam.com> wrote in message
news:u4B$(E-Mail Removed)...
> > > the guard spammer wrote:
> > >
> > > > We do not have a record of your licensing any of our products.
>
> Hey Evelyn, or whatever your name is, you sent me ntlib.cmd via
> email about a year ago.
>
> After I loaded it, I typed:-
>
> set ""
>
> Are now going to accuse me of reverse engineering? <g>
LOL!
> > I still think it's funny that they're selling batch files.
>
> If you think that's funny, how about the idea of someone actually buying
> them?
Actually, I think it rather a shame. But hey, I have some .txt files I will
gladly sell to anyone with a couple of bucks to spare.
> > broken PATH (how many times does the "how come I get 'bad command or
file
> > name' after typing commands?" question get asked in this group) is
another.
>
> I see what you're getting at, but it's not really relevant here. If a
> machine is broken you can't assume it's more likely to succeed running
> a script that relies on TPU's that a script that relies on built-in
> utils.
In fact, one can assume anything, but then one reserves the right to be
wrong.
> > machines because they're research scientists or programmers. To use the
> > "net config server" example, it would have problems on machines where
> > file/printer sharing isn't installed, wouldn't it? My point is primarily
>
> Did I say 'net config svr'? Make that 'net config work' <g> That seems
> to work very well indeed, even without F&P.
>
> > that Mr. Spammer's batch files would likely have a fairly significant
> > failure rate in these kinds of environments, and potential users need to
be
> > aware of these kinds of possibilities.
>
> That's right, where on earth do you start to debug such an obfuscated
> batch file that is uncommented and uses undocumented features.
In fact, I think they rely somewhat heavily on Alchemy for some of the core
functions...
> > That's the whole reason I wrote the osver.exe freeware tool. Quick,
easy,
> > even runs on Windows 9x. Plus, it's much faster than parsing textual
output
> > from another command.
>
> I've nothing against TPU, I use them every day and even write my own from
> time to time. Unfortunately it's just not always possible to install or
make
> these utils available to all machines, especially if the network belongs
to
> someone else, and understandably so.
>
> In these situations it's handy to have at hand scripts that only rely on
> built-in utils, blah blah...
Certainly sounds safer than having at hand scripts that rely on *OTHER*
scripts that themselves only rely on built-in utils, especially when you
cannot feasibly read them to verify this fact, but must take the word of a
spammer.
> IMHO, just one of the major shortcomings of the spammers product is that
> a script now relies on a 'loaded library' which is akin to relying a on
> TPU. And by definition of the spammers own admission, his product doesn't
> do anything that can't already be done using the built-in tools.
Exactly. Of course, I believe he would claim that he has done the difficult
parts *for* his customers.
Mind you, when it comes time for that customer to write what would, for most
people, be a simple five-line batch script, seems to me he is likely to wind
up with a five line script that loads ntlib and then calls some of it. Might
be OK for some, but those would be the people who run spellchecker on
EVERYTHING they type, and possibly everything they receive.
/Al
|