go@orstcs.UUCP (01/31/87)
Oh I do hope this gets out without being eaten... I recently had an "experience" with Microsoft that I wondered if any of you might have some insite in a way to "fix". Recently I purchased a PC "clone" system (you know, a little from here, a little from there...) and needed to buy a legitemate copy of MS-DOS to make it go. Lots of folks just copy a friend's disk, but not me. So, after I had traded for and acquired all the pieces to make a real computer, I trotted down to my local software shack and purchased a copy of (Shrink-wrapped by Microsoft) MS-DOS 3.2. I knew I could buy it cheaper from the back of Byte, but I have this thing about support... I can read schematics and fix the hardware if I have to, but I would rather have the authors support the software. Anyway, come about two months later and, what do you know? I found a bug. It seems that the date sometimes (most times) doesn't increment at midnight when the time overflows. Seems like a simple problem, so I called by local computer store. They tell me that they don't have any info from Microsoft about the bug, so why don't I call the Tech support hot-line. So I did. I encountered a most rude individual who told me in no uncertain terms "we don't support MS-DOS". I had to call the dealer from whom I bought the hardware. Well, since I got most of my hardware by trading and swapping, that was going to be rather difficult. He also told me that they knew of the bug, and didn't have a patch to fix it and even if they did they wouldn't tell me! Now that's the Microsoft I have grown to know... Several years ago I bought a copy of M80 from Microsoft and when I encountered a bug and called them I was met with an almost idiotic response -- "you must go to the store that sold it to you to get info and updates." Well I *bought* it from Microsoft. They wouldn't listen. I vowed never to buy software from them again. But today with their C and MS-DOS what choice do you have? (I Love their C, by the way.) Any ideas? Microsoft, are you listening? Is this a way to treat a customer. I can understand being hardhanded with dealers, but if it wasn't for us "end users" you wouldn't *HAVE* customers! By the way, the local store is working on the problem, but Microsoft doesn't seem to talk to them either. Gary Oliver ...!hp-pcd!orstcs!go
dewey@ttidca.UUCP (02/04/87)
I, too, decided to become a legitimate licensee of Microsoft MS-DOS 3.2 and
had a similar experience with lack of support. In my case I decided to use
the 'subst' command listed in the 3.2 manual which alluded to the use of
drive letters hight than 'f'. When I entered the command, letter for letter
from the manual, it didn't work. Upon calling Microsoft I got the same
'we don't support it' routine, they claimed that all support is to be
handled by the dealer who sold the software. On top of that, they claimed
that the software should only be sold bundled with hardware. I then called
the company that I purchased most of the software from and found that I
needed to include the 'lastdrive=' command in CONFIG.SYS. Luckily they were
looking at a PC-DOS manual.
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?
For any of you who have similar problems, try to check with friends who
may have a PC-DOS manual or the manual printed by Leading Edge. In both
cases they have done a much better job than the folks at Microsoft.
Bill Dewey
{trwrb,psivax,philabs,csun}ttidca!dewey
dewey@TTI.COMmvolo@ecsvax.UUCP (02/06/87)
William Dewey (dewey@ttidca.UUCP) criticizes Microsoft's lack of support of MSDOS at the user level In contrast with this, of all the DOS books I've tried, Van Wolverton's books published by Microsoft Press, Running MS-DOS and Supercharging MS-DOS are the best I've tried, and do answer many of this type of question, much better than the MS-DOS/PC-DOS manuals, and cheaper than the DOS technical reference manual. --Michael Volow, Durham VA Medical Center, Durham, NC --mvolo@ecsvax.UUCP
dkp@hadron.UUCP (02/13/87)
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