gregb@tau-ceti.ISCS.COM (Greg Baker) (02/27/88)
I called MWC today and was told the upgrade would be available in approx six weeks (cards will be sent out to registered owners of earlier versions. The cost was quoted as $39.95 US which includes the csd. Seems like a great buy.
sreeb@pnet01.cts.com (Ed Beers) (02/29/88)
They told me that with their pricing stratagy it will be cheaper to version
2.x now and upgrade than to buy 3.0 and csd (sold separately). They also said
6 weeks which I think means that they are slipping their schedual a little.
UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!sreeb
ARPA: crash!pnet01!sreeb@nosc.mil
INET: sreeb@pnet01.cts.comdavid@bdt.UUCP (David Beckemeyer) (03/03/88)
In article <2600@crash.cts.com> sreeb@pnet01.cts.com (Ed Beers) writes: >They told me that with their pricing stratagy it will be cheaper to version >2.x now and upgrade than to buy 3.0 and csd (sold separately). They also said >6 weeks which I think means that they are slipping their schedual a little. This sounds like an excellent policy to me. Very fair, and it avoids the "I'll wait for the new version" problem. It is always nice to see companies support their customers. I personally think it is a good idea for MW to hold off the release if they have to. I'd rather have a well-tested version that is 100% compatible and bug-free, than get a new version that breaks things and needs another update 3-weeks later. I know that the slipage (if there really is any) is not due to a "vaporware" situation, like we have seen from others so many times before. The software is all real; and I like the fact that MW is doing extensive Beta testing before release. You flame them for being late, and you flame them if it's not perfect when it ships. What can one do? -- David Beckemeyer | "To understand ranch lingo all yuh Beckemeyer Development Tools | have to do is to know in advance what 478 Santa Clara Ave, Oakland, CA 94610 | the other feller means an' then pay UUCP: ...!ihnp4!hoptoad!bdt!david | no attention to what he says"
ajw@littlei.UUCP (ajw) (03/08/88)
In article <162@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: >I personally think it is a good idea for MW to hold off the release if >they have to. I'd rather have a well-tested version that is 100% >compatible and bug-free, than get a new version that breaks things >and needs another update 3-weeks later. > >You flame them for being late, and you flame them if it's not perfect >when it ships. What can one do? Now that Mr. Beckemeyer (a good guy) has made this extremely valid point about Mark Williams Company (also pretty much good guys), maybe some readers of this group will pause for the odd nanosecond before flaming Atari (hiss the villain!!) for not having shoved "fixes" out of the door while they were still warm on the coding pad.
pes@ux63.bath.ac.uk (Smee) (03/09/88)
In article <236@gandalf.littlei.UUCP> ajw@.UUCP (Waldock) writes: >Now that Mr. Beckemeyer (a good guy) has made this extremely valid point >about Mark Williams Company (also pretty much good guys), maybe some >readers of this group will pause for the odd nanosecond before flaming >Atari (hiss the villain!!) for not having shoved "fixes" out of the >door while they were still warm on the coding pad. David Beckemeyer's point is valid, of course. And, of course, it also applies to Atari. However, we've been hearing from Atari about the things they're going to fix for some time now. Over a year, in some cases. There thus seems to be reasonable cause to suspect that they have fallen, or are in danger of falling, into the mirror-image of this issue. To wit, the 'continual fiddling' syndrome -- I'm sure we all know programmers who suffer from it. (I certainly know some, and indeed I am aware that I personally am prone to it and so have to conciously avoid it.) You know the one, don't you? 'Well, I've fixed bugs A, B, and C, but in the process I realized that D could use a little bit of poking with, so I need another week...' And then, 'Well, while I was poking D, I noticed that E is a bit suboptimal...' And so on. There does come a time when you've got to bite the bullet, freeze a version, and get it out the door -- resigning yourself to the fact that you're NOT going to be able to find and fix everything. Of course, Mark Williams have a bit of an edge, as they are dealing in software (discs) rather than hardware (ROMs) -- but even so...
Unknown@cvl.umd.edu (Unknown) (05/11/88)
# # # (darn line eaters!) # (append to last message). Called MW earlier this week, said shipping in receipt order, ordered about 6 weeks ago, said would receive in 3 weeks.
gregb@tau-ceti.ISCS.COM (Greg Baker) (05/19/88)
Does MWC support in-line assembler code like some of the other 'C' packages i've seem (i.e. asm(move.l 0,0x40C)).
hase@netmbx.UUCP (Hartmut Semken) (05/24/88)
In article <159@tau-ceti.ISCS.COM> gregb@tau-ceti.UUCP (Greg Baker) writes: > > Does MWC support in-line assembler code like some of the other >'C' packages i've seem (i.e. asm(move.l 0,0x40C)). No. There is an "full featured" assembler in the package (but I don't like it :-) and something like "move.l 0,0x40c" (steprate, right?) can be done with "poke()". C is almost, but not quite, entirely unlike BASIC... hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP I think, you may be right in what I think you're thinking. (Douglas Adams)