Re: how do i do in Linux what i do so well in Windoze?

["Robert G. Brown" <bob@xxxxxxx>]

"Steve Poling" <sdp@iserv.net> wrote:
>Here's a question that came up at work today concerning Linux vs Windows.
>You know that Windows has this thing called OLE that allows an application
>to share data with other programs and also to expose its functionality to a
>scripting language such as VBA.
VBA is a very much simplified environment for doing this stuff. What you really
want to look at (let's be fair! :) Is the MS DDE/OLE SDK's and DDK for this 
kind of thing. Most of this is C/C++, but language, per se, is not the issue 
here.

OLE, DDE and other bit of alphabet soup are incarnations of a very old idea,
which I shall refer to generically as Inter-Process Communication (or IPC...
when I give some answers, I get the right to make up my OWN alphabet soup!:)

>...And on the Amiga, there was this wonderful scripting language called AREXX 
>and what AREXX did was pretty close to what OLE does.
The Amiga was one slick box, mostly because of the architecture, not nessesarily
the software.  One of the NICE things about doing this on the Amiga was the
68000 CPU architecture, which (years ahead of everyone else) provided hardware
mapping and memory protection, so you didn't have to write that into software.

Microsoft OLE/DDE/DCOM/CORBA are fairly slow, partially in the name of increased
portability (at least that's the claim MS makes). I can see their point (but
I can't agree until I see their source code, and Bill hasn't invited me to 
look just yet), because they cannot rely on hardware protections. I don't know 
buckets about Win9x internals, but I do suspect that implementing this slows 
the
NT HAL-Microkernel a bit, even on simple machine checks. AmigaDOS knew what 
hardware they were on, and there's just a lot of exploits they could use to 
speed this up.

UNIX provides more ways to do IPC, I don't know for sure if they are all 
available in Linux, since I haven't looked. Linux has many of the same
portability issues NT has in this regard, but perhaps different choices
were made. Proprietary UNIX systems (I'm most familiar with Solaris) have
really glitzy features for IPC, like shared memory. This can be REALLY NICE
for some things, but then so is a flamethrower. You need to be convinced that
the folks wielding such devices keep track of what's going on; even a momentary
lapse can result in disaster. There are other tools, such as sockets and pipes,
as well as toolkits which asbstract ALL of these methods (SUN did one, called
"ToolTalk", that allows for some really SLICK network apps).

>Now, my knowledge of Unix will fit into a thimble, tho i have a pretty good
>grasp of generic systems architecture jive. But for the life of me, I can't
>think of a Linux equivalent to OLE or an AREXX port.
Stop thinking about LINUX for a minute, and go back to general principles. The
notion behind IPC is that we can share data, but with a lot of protections. I
want to allow you access to this value, and not those. I want to make sure you
read the value before I set it again, or maybe I want you to set it before I
read it again.  How do we denote these things? A lot of these questions had to
be solved before timesharing systems could be built, and that's what some people
at IBM did back in the early 60's.

>Sockets? Files & pipes?
Overall, I've been building to sockets as (at least) a mental model for IPC.
I have written a few socket apps, in C++ (under Win32 and several Unices)
and APL (in Win32), and the level of abstraction, along with the overall
capabilities, allow you to do anything the MS IPC methods can do, and more.
You have the flexibility of creating your own IPC protocols, and callbacks
in the client can do what OLE does, only better, because it will almost surely
be faster (good design and coding skills required).

>anybody got any opinions on the subject? Like what's the official Linux
>answer to the "integration" capabilities of the M$ Office applications?
First of all, there's no "official Linux answer" to this. There IS a general
answer that you will get from anyone who has done non-simple apps in any of
the UNIX environments. I think I've provided a reasonable representation of
this, at least from the standpoint of a software engineer with opinions derived
from experience.

>is this a really obvious question and i'm like clueless?
No. The implications are not obvious. OLE privides reasonable lightweight 
support on the same box. Sockets provide general, flexible support for
anything you can imagine, on the same box or across the net. Which is better?
You tell me.

One point you did not mention was whether you are asking this question as a 
software developer or as a user.

Adam Williams <awilliam@whitemice.org> wrote: 
>I think CORBA may be more what your looking for,  several ports of it exist for
>Linux.  But I think (maybe unfortunately) that pipes and sockets are sometimes
>used in an "attempt" at the same thing.  ODBC is out there too for integration
>will all them database engines.  I don't what if any of the major apps support
>CORBA, or anything like it.  Which would be too bad.
CORBA and ODBC are both open standards, in fact ODBC is one of the BEST things 
Microsoft ever released and popularized of ANY open standard.

There's a CORBA product from SAP, I think, but I have not written much to do
with CORBA. I would certainly hope that CORBA and ODBC compliant products 
become available for Linux, and those that are already here continue to improve.
I would not want to do CORBA or ODBC in pipes n'sockets myself. The standards 
are too detailed for me to do an economical job of it; I can buy/download the
right software more easily, even at Microsoft prices.

Adam Williams <awilliam@whitemice.org> wrote: 
>What integration?  M$ Office apps come in the same package and are made by the
>same company,  I'm not impressed.  They don't "integrate" so nicely with most
>other windows programs.  That would be impressive.  The apps in the Star Office
>and Applixware suites all integrate with each other.  So did all the apps in my
>"office" suite I had for my Commodore 64 back in the 80's.  In fact,  that is
>still one of the best suites I have yet seen, and all in 64K and very fast.
I'd like to know what you mean by "integration".  MY idea of integration is that
I am mucking around with some data in Excel, and, having graphed it, I want to 
export it to an MS Word document. DDE lets me export it very nicely, but it's
static. OLE allows me to embed the graph in my Word Documet, AND IT WILL CHANGE
WHEN SPREADSHEET VALUES DO. This is not merely cool, it's a critical facility.

When office-type applications have that kind of functionality built in, they
have reached a level of integration that turns them into building blocks for 
applications, and that's more significxant than being a bunch of compatible,
but actually seperate applications.

Now, I don't know if StarOffice or Applix has something analogous to the sort
of dynamic functionality I've described in conjunction with OLE, but I do know
that it's surely possible.
                                                            ---> RGB <---