Orcad Viewer doesn't work

TCP/IP is just "a stream" so you end up writing a custom protocol every time, and the parser and buffering end up making such an approach at least an order of magnitude slower than COM's "direct call" interface...

Granted, these days CPUs are often fast enough the raw speed doesn't matter -- with COM you never know if what you're calling was written in assembly, C++, Python, Visual BASIC, or any other language --, but having to parse the data in a TCP/IP stream (even if you already have a nice library to do this) is kinda klunky, IMO.

---Joel

Pretty sure they won't release that, just like Coca Cola won't release their recipe ;-)

you

Visual

mean,

I would be interested if the FILE format information for ORCAD files were available somewhere.

I could most likely make a nice viewer if given such information :)

And supplied your own leather seals...

Yeah, but on unix you get free multi-machine operation, same protocol ;) Sockets within the one machine is fast, multiuser in sense of multiple access to server resources, I've made a server does that, in perl for the sockets, and gawk or shell scripts to access the server, works well.

Besides there SHMEM and friends. Though less used, direct interface via shared memory, semaphores and stuff. But sockets (tcp/ip) are somewhat more common and easier in unix.

Sockets are good for multiple access to server resources, I've not done that under windows to make a comparison though. Last time I programmed for windows was with Delphi, almost like VB. And the mechanics of how things communicated seemed more vague.

Main things is what you're comfortable with? Productive, I don't try to get hung up on the technology, just get the job done.

More adjustable, adaptable? I dunno, I'm not a production programmer, except for assembler on underpowered controllers ;) I prefer not to write for windows, but I'm retired. Some things I have to be paid to do, writing windows code is now one of them, too difficult, compared to unix. Each to 'is own :)

Grant.

Hi Grant,

That's a good point. Microsoft has something called DCOM (distributed COM), where the idea is that it works across multiple machines, although in practice people don't seem to use it; I wouldn't be surprised if using it is enough extra work that you might as well just go to straight sockets.

Agreed, multi-process support for semaphores, message queues, shared memory, etc. is quite impressive in *NIX -- particularly given that it was already all in there more than three decades ago now.

And of course much more cross-platform; trying to port a *NIX program that uses shared memory to Windows is usually quite a chore.

From a programmer's point of view, yeah, I agree. But I think there's a real benefit in Microsoft's standardization on COM for "automation" of applications in that your end users (well, the "power users" -- those who are going to write a script or two) aren't constantly being faced with "similar but slightly different" protocols as seems to happen in the *NIX world; I think there's a real (if small) productivity benefit there.

As others point out much more elegantly than I can, this lack of standardization -- not just for application automation but for the desktop and many other parts of *NIX -- is both its greatest strength and greatest weakness.

---Joel

Did you ever analyze that 'direct call'? Just look up 'marshalling'.

COM does the same thing but in a very complex way.

OK, but there's plenty of marshalling to get between a user-mode application and a TCP/IP buffer as well. But the TCP/IP stack still has so much protocol overhead associated with it we'll still talking an order of magnitude slower performance, I would expect, even within the same machine.

---Joel