Re: Beware wildcards in Kill

From: Hapticz (hapticz_at_Unspm.email.msn.com)
Date: 04/10/04 

Date: Sat, 10 Apr 2004 10:42:22 -0400

he he he, detail details details.....

as we "float" up into the sphere of advanced programming, the base constructs of what all is created from gets lost in the fog of
rapid deployment and hastened revisions. heck, who has the time, need, desire to make sure that each app has fully handled errors
and beta tests? who will pay for it? surely not the average shmuck drifting thru the aisles trolling for bargains at bestBuy,
Staples, or OfficeMax!

with most apps having a "lifetime" of less than 1-2 years and hardware making strides that eventually force rewrites anyhow, i
submit that we have fallen into the realm of "antiquarians" ;-))

i say we should stop all this nonsense (and start planting our soybeans instead). ooooohh my achin back! 

--
Best regards,
Hapticz
STOP STOP STOP STOP STOP STOP STOP STOP STOP
<>><<>><<><>><<><>><<>><<><>><<>><<>><<>><<>><<>
"Russ Holsclaw" <russ@holsclaw.nyet> wrote in message news:#ZE1LsYHEHA.1944@TK2MSFTNGP11.phx.gbl...
>
> "Tony Proctor" <tony_proctor@aimtechnology_NOSPAM.com> wrote
> in message
> > Interesting reply Russ. The fact that the short names are
> effectively padded
> > to a fixed length would explain why '?' appears to match
> 0-or-1 characters
> > rather than any-single character.
> >
> > However, the file specification I'm using is a long one,
> not a short one.
> > Are you therefore saying that the wildcarding is
> internally applied to the
> > hidden short name, even when you're accessing a long name
> in your code? If
> > so then that would be horrendous.
>
> The name in your example "xyz????.dat" looks short to me.
> Both old DOS-style and new-style name-matching rules are
> always in effect. The "short name" may be hidden from the
> end-user by the Windows shell, but they're just as "visible"
> to file system operations as the "long" ones are. The
> operating system code doesn't know or care what your
> intentions are, nor is it sensitive to your moral outrage.
> It would also be "horrendous" for old code that worked for
> years under DOS to quit working.
>
> Sadly, Microsoft doesn't do a very good job of maintaining
> documentation on functionality that exists to maintain
> downward compatibility. They erroneously feel that it's
> irrelevant for people writing new code, even if it can reach
> out and bite you. IMHO, this is probably due to the fact
> that documentation is often written by "technical writers"
> who lack any real technical depth, so they don't realize
> what's important.
>
> Back in the golden years of my youth, software API
> documentation was written by actual programmers, who hated
> having to do it, but generally did it reasonably well. The
> niggling little details that might bite you generally got
> spelled out in rigorous detail. They even carefully listed
> all of the error codes that might get returned, and what
> conditions caused each one. If you were careful enough, you
> could write a correct program based entirely on the system
> documentation, and it would work. And if it didn't work, it
> was almost always your own fault.
>
> Today, programming has become an exercise in
> trial-and-error, and Microsoft (and others, including the
> "Open source" freaks, who don't document their *** either,
> much less comment their code), seem to have no sympathy for
> anyone who's gotten bit by undocumented behavior.
>
> The only reason I happen to know the stuff I just told you
> is because I grew up with a lot of this stuff, including the
> earlier systems, like CP/M, from which it was derived.
>
> Now that you know the ugly truth, you have little choice but
> to deal with it.
>
Quantcast