🚀 go-pugleaf

In article <384@ttidca.UUCP> dewey@ttidca.UUCP (William Dewey) writes:
>
>The point of this is, if you are listening Microsoft, is why your bad
>attitude towards the users of your products, and why, oh why, do your
>manuals completely leave out information which is needed to use other
>commands which you do document?
>
	We ran into a similar problem with Microsoft WINDOWS.  If you
	talk to the people at tech support about file access, they tell
	you that standard (buffered) IO is a no-no and that you should
	also not use open/read/write/close (but can't really give you a
	reason).  They tell you that there is a header file distributed
	with their development kit which "fully" defines the use and
	existence of _l*  versions of those same routines (_lopen, _lclose,
	etc.) which are supposed to do file IO the "correct" way.  The
	conversations we had with them invariably ended with them saying 
	that these routines were unsupported but that they were the only
	RIGHT way to do file IO.  Worse still, all the header does is
	give you the forward declarations for the routines.  The flags
	are mostly undocumented and are NOT the same as their counterparts.

	The newest version of the documentation for the development kit
	now has a big disclaimer in some sample code that _lopen/_close
	are left for the user to write...and still their tech people
	say to use them exclusively.

	Come on Microsoft - make up your mind.  We expect to have functions
	like file IO in our libraries and we expect documentation.  Make
	up your mind please!

	As an aside for anyone else who has run into the same problem,
	open/read/write/lseek/close really do work in windows applications
	and "libraries" - so much for tech support!

	David Purks
	...!seismo!hadron!dkp