dkp@hadron.UUCP (03/25/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
rice@pilchuck.UUCP (03/26/87)
I've tried to use Microsoft's Customer Support several times over the last few months (for their C compiler). They've never managed to answer any of my questions. I'd hoped that they would have more information than I do, but the response is always, "Let's look it up in the manual together." If I'd been able to find it in the manual, I wouldn't have called. The last time I called, I hit an extremely annoying automated telephone- answering system. I had to work through about six levels of a tree-structured sequence, pushing keys on my phone to select branches to reach the C experts. When I finally thought I'd found the lowest level, I got a message that they'd all be in a meeting and to call back in two hours. I was so mad I just about drove over to Microsoft to chuck my question through a window tied to a rock. I doubt that I'll ever try again. Too bad. Ken Rice
rick@beowulf.UUCP (03/27/87)
In article <620@pilchuck.Data-IO.COM> rice@pilchuck.UUCP (Ken Rice) writes: ... >The last time I called, I hit an extremely annoying automated telephone- >answering system. I had to work through about six levels of a tree-structured >sequence, pushing keys on my phone to select branches to reach the C experts. >When I finally thought I'd found the lowest level, I got a message that they'd >all be in a meeting and to call back in two hours. I was so mad I just about >drove over to Microsoft to chuck my question through a window tied to a rock. ... I appreciate your frustration, but actually I prefer this "phone-menu" approach to getting put on hold indefinitely -- or worse cut off after being on hold indefinitely -- while a set of receptionists try to route my call. I suppose it saves time and money too, and you get as close to the person you want to talk to before any human intervention (but your own) is called for. If the tree is well-designed, it sounds like reasonably intelligent automation... Also, consider that if you want to call the same desk multiple times, the sequence can go very fast after the first time (assuming you write down and save the numbers) -- if the system works like the one at Orchid, you don't have to wait to hear the recording at each node of the tree. Rick Randall EECS Department University of California, San Diego decvax\ rick@sdcsvax.ucsd.edu ihnp4 >---> sdcsvax ---> rick ucbvax/ rick@sdcsvax.uucp
cjdb@sphinx.UUCP (04/04/87)
In article <2910@sdcsvax.UCSD.EDU> rick@beowulf.UUCP (Rick Randall) writes: >... >I appreciate your frustration, but actually I prefer this "phone-menu" >approach to getting put on hold indefinitely ... >Also, consider that if you want to >call the same desk multiple times, the sequence can go very fast after >the first time (assuming you write down and save the numbers) -- if the >system works like the one at Orchid, you don't have to wait to hear the >recording at each node of the tree. This is true. For C and MASM questions, the sequence is 1 2 2 1; no waiting. They say 4 0 1 is the escape to the top level of help, but I've never tried it. Last time I called I asked why Codeview seemed to hang my AT at will (so badly that I have to cold boot it). They couldn't help me ("Do you know of any bugs in Codeview?" No. No bugs. Hmmmm.) The darn thing will even hang after doing an Alt-S. Sheesh. But's still, it's a _lot_ better than nothing. -- "... every form of refuge has its price." ..!ihnp4!gargoyle!sphinx!cjdb -- The Eagles PMRCJDB@UCHIMVS1.Bitnet
davidr@hplsla.HP.COM ( David M. Reed) (04/19/87)
On the subject of MicroSoft... First, one positive note: I like the new phone system for reasons like those mentioned in the preceeding couple of notes. Second: they do seem to have some difficulties coming up with authoritative answers if the question is not a simple one. Third (MAJOR GRIPE): The seem to be the RULE MAKERS, and yet violate those rules (or is it change the rules in the middle of the game?) more than anyone else (like they have special rights?). I have read several times of their comments as to why they are having such difficulty coming out with a DOS for the 2/386 (protected mode and all). It seems that they were complaining how there were to many "ill-behaved" programs that directly addressed hardware instead of using the operating system (or at least the BIOS) and that made for great problems in trying to control more than one program operating at the same time. Yet, for example, MSWord has caused more system problems and interference than most any other program I have ever dealt with. A simple example was using a keyboard with separate cursor keys and numeric keypad before IBM came out with their "enhanced" keyboard. If I happen to start WORD with the NUM LOCK on (such as having just used 123), then my cursor keys became number keys until I re-booted the computer. Of course, MicroSoft feels it is my fault for using a computer that is not 100% IBM HARDWARE compatible, but the problem (and others I experience) would not happen if they didn't "take over the keyboard" (as claimed via Customer Service). But would we not have had a new operating system exploiting the 80286 capabilities by now if they didn't have to deal with programs written by themselves? Of course, I could go on extensively. But I let others add their stories.