da Silva, Joe wrote:
>
> You see SHARE as a problem - I see SHARE as a warning
> that applications are doing something stupid! <g>
Not really. I don't see SHARE as a problem because I don't use it
and I don't know anything about it. <G> I said it was a POSSIBLE
problem for the same reason.
If it allows sharing of files, (see? I don't know) then it MUST be
a disaster waiting to happen. IMHO this should never be permitted
on a non-network box. Just a personal preference.
> Without delving back into the various side-effects of
> file sharing violations (they depend on many factors),
> you seem to have missed the point about "closing
> standard output" ... When standard output is not
> being redirected, it matters not whether an application
> specifically "closes" standard output (certainly, once
> it has no further need for writing to it ...) - it is a device,
> not a disk file, after all. However, when standard output
> is redirected, it is no longer the 'console' device, but
> an actual disk file, just as if the application itself had
> explicitly opened a disk file.
Ah yes. I had DEFINITELY missed the point !
> In summary, standard output is a normal disk file ^can
>be^
> when redirected, and an application needs to keep
> this in mind - ie. if the application is going to "go
> resident", it needs to "close" standard output when
> it has finished with it ...
As you say, this can be a problem with TSRs that produce standard
output if the user choses to re-direct it to a file.
I guess that means TSRs should always send their "Hello" messages to the
console via a handle cuz there isn't any way to close the "potential"
file otherwise. Bummer.
A good lesson there.
I wouldn't normally think about closing that file, because
I still use the DOS character functions for text. (me bad) <g>
So does David. I've got the source. <G>
Looks like a major re-write.
- Clarence Verge
--
- Help stamp out FATWARE. As a start visit: http://home.arachne.cz/
--
