Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Message-ID: Newsgroups: comp.sys.amiga.programmer Subject: Re: 2.0 Compatibility Distribution: world References: <913.28202b13@vger.nsu.edu> <91126.101931DXB132@psuvm.psu.edu> Date: 11 May 91 16:34:28 PST Organization: Not an Organization In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >> ... >> 12 bits/pixel now would be a relatively easy extension to increase. >> >> So why don't the PC app writers use the supposed VGA and driver >> standard for VGA and other cards? Because they are slow, buggy, and >> vary too much across card manufacturers. Oh, and by the way, other >> resolutions use entirely different 'standards' that are also slow, >> buggy, and vary too much between card manufacturers. >> > >Don't expect better from Commodore. They have fewer people in house than >IBM, Microsoft, Intel, Compaq and the rest. They have fewer people than >Apple. How about R&D? Compaq alone just spent like $200 million on >SGI stock and R&D, and this was pocket change to them and would certainly >be considered an outstanding net profit for CBM. Interesting statement, but past experience proves you wrong. I see nothing from Microsoft to justify the money they have spent... nothing from the IBM world at all. So far I see Windows 3.0, which I could easily write from scratch in 6 months by simply ignoring MSDOS compatibility, and OS 2.0 which I could easily write in another 6 months, or less. That's me, alone, writing something of equivalent functionality and power. So why does it take *them* so long and so much money? Commodore does a better job with fewer people in less time because those a *smart* people over there. Microsoft, IBM, and Apple have so much corporate red tape and overhead that what good programmers they have don't get to do much. Apple's the best of the lot but early design decisions show a basic failure in their control structure... somebody wasn't looking ahead far enough, and in the past 4 years they have really bogged down and gotten greedy. Bryce was multitasking PET-BASIC years before the Amiga was even a thought. >>>This can't be true because of the extreme degree of compatibility that >>>Amax-II exhibits. Certainly not true if you count Amiga games. :-) >> >> ?? >> > >Translation: If Mac programs go directly to the hardware, they wouldn't >work on the Amiga running AMax. So far, I've only found a couple of PD >terminal programs that DON'T work. Amiga games that use the OS are in >for serious problems. I think you have mixed up my words a bit. Just because the Amiga's OS PROVIDES resource control for direct hardware interface does mean that most programs USE that capability. In fact, very few do. The same goes with the Mac. The original argument that started all of this was somebody mentioning that Apple tries very hard to keep programmers from going to hardware. The original answer was that yes, they try, just as Commodore requests people not to go to hardware, but that doesn't mean that all programs written stay away from the hardware. Some don't, on BOTH machines. The skewing occurs due to the fact that you see many more high performance games available for the Amiga than you do for the Mac, mainly due to the Amiga's capabilities. If you ignore these custom built games for both machines what you see is that almost none of the remaining applications go to hardware -- on both machines. >> It seems to me that you have gotten in the habit of refuting everything >> I say even if you have to resort to lying to do it. I don't suppose >> you've ever *programmed* for 2.0, eh? 2.0 is solid compared to 1.3, >> Commodore is certainly not backing away from necessary changes. Every >> aspect of the OS is easily extensible owing to the dynamic nature >> of shared libraries, something no other operating system has exploited >> except, perhaps, UNIX. > >How about OS/9? OS/9 isn't a bad deal considering its goals, but I like 2.0 better, or a real UNIX (i.e. with firewalls & security which is the only major difference between Amiga OS 2.0 and UNIX). >Come on Matt, you don't have to get frustrated if people don't see eye to >eye with you. Everyone who reads this group loves the Amiga just as much >as you. Is yours the only valid view of things? How is Dan's joke above >refuting anything you are saying (your response appears as if you think >it does). Looks to me like if he's refuting anything, it's your refuting :) > >And 1.3 has almost 6 years of work behind it while 2.0 has a lot less. I've >seen more bugs in 2.0 than I ever saw in 1.3, especially when running >1.3 applications (NOT GAMES). I would disagree with you there ... 2.0 is almost bug free compared to 1.3 . Certainly early alphas and betas of 2.0 were buggy, that is to be expected. But the last 4 or 5 near-release (gammas?) have been almost entirely bug free, an order of magnitude more reliable than 1.3 ever was. >It's been my opinion for years that Microsoft should have built Windows >around Xenix. But Dan makes a joke and you ramble on about issues that >belong in .advocacy (AMiga is better than IBM and so is Unix...). Huh? I was talking about Windows as it is, not as it might have been. Frankly, I think Windows should never have been written and microsoft should have gone ahead and ported BSD or SVR4 to the IBM, but they didn't, and now its too late (?). >>>Why not support any resolution? Hard-coding 768x480 is not any better >>> >>>-- Dan Babcock >> >> Dan, you really don't know anything about the Amiga, do you? Nobody >> but game programmers hardcode screen resolutions any more, but you can > >Dan knows more about the Amiga than you give him credit for. He must actually >use commercial Amiga applications because what he sees is absolutely correct. >What I see is too many APPLICATIONS making STUPID ASSUMPTIONS (in your words) >about the size of the screen. PowerWindows alone is probably used by soooo Then perhaps I misinterpreted his point... I was under the impression that he said the Amiga did not support arbitrary resolutions when, in fact, it does right down to the hardware level. >many developers, and its use under 1.3 encourages poor quality 2.0 programs. >How many programs can you name that actually specify a screen font or look >at the default screen resolution and deal with it properly? I can name 2: >CygnusEd (has no problems with menus when running on the Workbench) and >DPaint III (which doesn't let me use a 320x200 screen when I want to if >my defaults are bigger than 640x400 or 640x200). > >I got PowerWindows 1.0, 2.0, and 2.5. Nowhere along the way did they >anticipate the problems that the 2.0 ROMs have brought. Apparently, >their customers (i.e. applications developers) never bothered to point >out to them the error of their ways (like generating a NULL default font >for screens). If you want to be compatible with all these applications, you can set your screen and workbench fonts to Topaz 8, or simply open a PUBLIC SCREEN WITH ITS FONT SET TO TOPAZ 8. Poof, instant compatibility. An earlier point I had made was that while many developers, myself included, did not handle fonts correctly, the amount of time required to FIX these problems is minimal... a couple of minutes for me to fix DME. It just isn't a problem. You are looking for new OS revisions that are 100% compatible with previous ones... this is NOT realistic. The whole reason for having a new revision is that somebody thought of something they didn't think of before, and integrating that into an operating system is not always straight forward. Even UNIX isn't 100% compatible with previous versions... When BSD UNIX switched to 'long' file names they broke: (1) all the filesystems ... you had to dump, reformat, and restore (2) 90% of the utility programs (3) Many, Many application programs When people began to map out page 0 to catch NULL pointer indirections they broke a LOT of software. Obviously the software was buggy, it just had never shown up. Who is at fault here? >> Hardcoding screen resolutions in applications went out of style 2+ >> years ago on the Amiga. > >So as Dan would say, the programming rules changed 2+ years ago? I don't >agree with you (sorry) because 99% of the APPLICATIONS I bought over the >last 2+ years do indeed open hard coded sized screens. Looks like you made some bad choices at applications. Besides, they still work eh? Compatibility is one thing, forcing programs to use new features that didn't exist when they were originally written is something else. You can't honestly expect programs that were written before new features existed to utilitize those new features. After all, the programs you indicate that open hard coded screens still work, eh? >> Under 1.3 you can ask intuition about basic screen dimension maximums >> and intuit available modes from graphics.library flags. >> > >One can, but few did. Did you? Yes. Most developers did/do. Actually, my programs open on the workbench screen in general.... take DME for example. Under 1.3 I wrote a program called MWB which worked much like public screens work today... it would force windows to open on custom specifiable screens. This is a much better solution than writing programs that open their own custom screens because in many cases the user wants several programs to run on the same screen for ease of use. >> Under 2.0 you can ask intuition about available screen modes and >> resolutions in a general fashion, then open the one you want. >> > >If people bother to (which I hope they do). I give people more credit than that. You can't FORCE a programmer to abide by the new rules, so complaining about his programs doesn't really make any difference to Commodore -- THEY can't do anything about it. Better to complain to the programmer who wrote the program in the first place. -Matt >-- >**************************************************** >* I want games that look like Shadow of the Beast * >* but play like Leisure Suit Larry. * >**************************************************** -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA