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
> >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

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
> 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
> >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
> >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
> >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
> 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
> I hope you don't talk about your employees like that, if you have any.
> do what they do, what they are paid to do, pretty much the same as
> 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
> 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

And beauty is in the eye of the beholder.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
* Contact the list manager:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to