Abd, Thank you for you well written and well considered reply. While I do not agree with all you say, I respect you taking the time to address the issues in such a detailed manner. I have some further replies below.
> >1 - It's no faster than Protel 2.8 PCB and Advanced Schematic 3.0. I would > >have thought that somewhere along the way they would have optimized the > >code and sped it up a bit. Apparently this is not the case. > > The thought was ... naive. Software in general gets slower as it gets more > complex, but the *hardware* gets faster, and hardware is cheap, cheap, > cheap, compared with software costs (for software like Protel). You want > faster Protel, buy a faster computer. In another post, I show how the > faster computer might cost, say, one-tenth as much as the software. Rosy, but not naive. As a software developer, my experience is that it's quite often possible to look at a problem from a different angle and discover that your choice of algorithm was not the best possible one. I certainly agree that new features slow down the program, and that faster hardware will help ameliorate that problem. However, to simply rely on the fact that the hardware gets faster is a bad approach that creates slow software. As a case in point, Kodak developed a program for image processing that is used in the motion picture industry. They developed it on then "fast" hardware using C++ and an attitude that since the machine was so fast, they didn't have to write "optimized" code, they could just let the CPU carry the burden. Besides, the next generation machine would just be faster anyway. Result? A really slow program that took a long time to do the job. Conversely, Adobe developed a similar program (AfterEffects), but they started it back on 68xxx Mac machines. There attitude from the start ewas to make the code that does the hard work be as effiicent as possible since they had a relatively modest platform at best to work on. As machines have skyrocketed in CPU speed, there code has a foundation based on efficiency, thus it blows away the Kodak software. It cost a fraction of the money, and is many times faster. It's my belief that Protel has never really tried to increase the efficiency of the code, figuring that new features were more important that raw speed. However, even today, a fresh set of eyes that isn't afraid to touch the low level code (that no one has messed with for years), could find better algorithms and approaches which would speed up the program overall. I don't believe that Protel cares since they have the same attitude you do which is that fast hardware fixes all slow programs. > Others wrote about this. I've never seen the problem, I think it may indeed > be hardware or driver dependent. I disagree. Others do as well. More below. > >Does anyone at Protel actually use this thing or do they just write the code > >and ponder wistfully about what it's like to actually run the program? > > Altium (nee Protel) has people who do full-time training. They definitely > know how to use the program, and they have to live with how it looks to > users. I don't see them hiding in shame.... I don't see them here either. Nor have I ever received a single reply from any email or letter sent to them regarding problems with the software. I'm not referring to tech support, I'm referring to detailed letters explaining fundamental issues and flaws that have gone unanswered. I have been using the product since PCB 1.0, back when they hadn't completed the schematic program and you had to buy the DOS program for that. They were a small company then, and they still blew me off. Today, forget about it. They apparently can't be bothered. > >I > >remember years ago being told by Protel support that the broken line issue > >was a "driver problem," and that it only happened on some systems. > > It seems they were right. See above. > > Well, I > >have been using Protel with both ATI and NVidia cards of all different > >vintages (and on different OS's - 95, 98, 2K) , and it consistently happens > >on ALL of them. > > ALL RIGHT. Now we have some information. ATI is *famous* for compatibility > problems. Go to the ATI site, you'll find some of the technical notes say, > essentially, it doesn't work and we are not going to fix it. NVidia, I > don't know. But others already addressed this issue. And it is definitely a > fact that the problem does not happen with some hardware. I did as you said. On the ATI site I typed "Protel" into the search box and it came up empty. Apparently. ATI has never heard of Protel or the line issue as far as their search engine is concerned. > > As someone who has programmed GDI stuff on Windows quite a > >bit, I think the problem is simply that the code they wrote at Protel > >suffers from various "off by one" errors, and they are either ignorant or > >complacent when it comes to finding and fixing the problem - possibly both. > > I hope you don't talk about your employees like that, if you have any. They > do what they do, what they are paid to do, pretty much the same as everyone > else. And they are paid mostly for providing better features. Give me a > choice between a better autorouter and fixing all the remaining bugs, I'll > choose the autorouter.... minor bugs I can live with, routing is bread and > butter. No, I don't have any employees. If I had any, and they couldn't find and fix bugs, then I most definitely <would> talk about them like that - then I would sack them. One of the most critical things a CAD program can do is make a quality screen drawing. Protel can't. It hasn't since the day they released the schematic program, and it still can't. Further proof that it isn't a "driver" or "hardware" issue - if the problem didn't lie with Protel, then how come the PCB program has never had the problem but the schematic program does? Same company, but two different code bases that handle drawing lines on the screen. One program screws it up, and the other doesn't. If the problem was in the hardware, then both programs should mess up. On the other hand, if the person(s) who wrote the schematic program messed it up, then the same hardware would have different results. Since the results <are> different, I posit that the Protel code is in error. Even if they problem <were> hardware related, then they should have given the user an option to handle the drawing correctly with a preference option. Again, they know the problem exists, and they can see it. If the hardware is messing up, then they should factor out the error when they make their GDI calls and compensate for whatever problem exists. Software developer work around Windows problems all the time. However, given that I know of <no> other CAD program that suffers from this problem, I can only point out that the burden of proof is on Protel. If everyone tells you that you drive too fast, then perhaps <everyone> is not a jerk but rather you simply drive too fast and should address it. Similarly, if no other CAD program (including Protel's other flagship program) has a drawing problem, then perhaps Protel should fix it. > As far as "bugs that affect everyday use," I'm not really aware of any. > Sure, there may be some, but I learned to avoid them. Frankly, though, I > can't think of one. The software, *on Windows 2000, which has long been the > recommended OS for Protel*, very rarely crashes for me, I can't remember > the last time. Their schematic program can't pan and draw without breaking up the lines on screen. That is a bug that affects me every day. I apologize for harping on it, but it's the most annoying one that springs to mind. > Bottom line, the software is relatively mature and bug-free for everyday use. And beauty is in the eye of the beholder. Thanks, PeterM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *