Path: utzoo!attcan!uunet!wuarchive!usc!blars!blarson From: blarson@blars Newsgroups: comp.os.os9 Subject: osk 2.3, various woes, usenet for osk, and so forth... Message-ID: <112@blars> Date: 10 Oct 90 17:03:55 GMT Sender: news@usc.edu Lines: 86 Nntp-Posting-Host: dianne.usc.edu Originator: blarson@dianne.usc.edu I finally upgraded my qt20x to osk 2.3. If I'd known it would cure so many of my outstanding problems, I wouldn't have hesitated so long. The few new bugs are so minor in comparison.... (Note: the motherboard still has residual crud that won't come off due to a broken pipe in the apartment above. I had attributed most of my supposed hardware problem to this.) Fixed: nasty C compiler bugs dealing with "string"[0] and sizeof("string"). My system actually keeps the correct time rather than loosing several hours a day. I though this was a hardware problem. My Newburry data disk drive now works. I'd heard that SCSI support was better at 2.3, so this wasn't a total surprise. It's nice not haveing to look for something else to delete every few days. (Usenet promises to use as much disk space as I let it, however. 300 meg isn't infinite.) The tape drive Frank Hogg sold me to go with the system now works. Since Frank claimed not to have problems with them, I was wondering if this was a hardware problem too. Now I can even back up my disk drive. Broken: The "dir -e" format has inexplicably changed by one column. This broke mg, which parses the output from "dir -e". "." is apperently no longer included in the default include file search rules in the C compiler. Adding "-v=." to a make file fixed this. (This only applies to compiling files out of subdirectories.) There doesn't seem to be a way to write an ANSI-like OFFSETOF macro under the new C compiler. The new C compiler seems to think: (((char *)(&((struct foo *)0)->bar)) - ((char *)(struct foo*)0)) is a pointer-valued expression. (Don't ask me what it thinks it points to.) The other semi-portable offsetof definition produces the correct type, but very wrong values. The age coumn of procs now accumulates. This is wrong and useless. I can't boot off my Newburry. I get endless "error 215" messages. Still broken: My batery-backup clock still doesn't battery backup. Replacing the batter did not cure the problem. Occasional disk hangs requiring reboot. Usually occur durring the r68 phase of a make. There is some improvement: it now gives error 68:254 and returns to the shell. Further access of /h0 doesn't work. Flopies can be accessed. Has anybody else experienced this problem? (Since the hard drive and cable have been replaced, those arn't the problem.) Usenet: This is the second article I've let escape from my qt20x running cnews and rn. Mail and uucp are the main requirements besides testing and documentation before I release it on the world. The C compiler bug fixes let me back out some nasty changes I had had to make to cnews. So fourth: Microware should worry about fixing the bugs and making their compiler ANSI compatable before seriously considering changes like register use on argument passing. The compiler produces such poor code that a few extra instructions here or there won't make any real difference. Passing arguments in registers will be a real win if the compiler ever does optimize. The vast majority of the programs I wait for are disk bound, implementing a caching rbf would make orders of magnatude more difference. [apologies for the double signature, it's due to the backdoor way I currently transfer news to and from my qt20x.] -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.