> The fact that you can now get COM on Linux is not going to convince me its a
> good standard. We already had the full DCE RPC standard that worked cross
> platform and CORBA that provided a much nicer environment at greater speed.
> That Microsoft weighted in with COM as an 'inductry standard' does not make
> it a holy thing.
I agree - DCOM is a dog - by COM I'm really just referring to using as DLL
withthe basic three AddRef, Release, QueryInterface methods combined with the
lowest common
denominator of the basic data types that are allowed - it's possible to achieve
a similar
effect using DLLs. It's just a convenient interface on the Windows desktop at
the
moment to interface different languages.
It certainly not the worlds most brilliant standard - but quite useful as a
bridge
between different languages - the speed isn't important for what we use it for
which is
just a means of talking to Delphi.
> So was FORTRAN and COBOL and they are now religated to small corners of the
> industry. I've been tracking C++ every since it poked its head up as cfront,
> and while I can agree with some of the design I have very serious
> reservations about much of the language. In any case a 'long time' in this
> industry is about 10 years, try and remeber what you were writing on and
> with 10 years ago 8-)
Proprietary Acorn BBC Basic and ARM assembler - C was around then though...
C++ has definitely got its warts - it would be nice if it had a decent linker
structure like
Delphi or Ada - and templates got a little out of hand - but it's so widespread.
Strategically its well located in relation to all the important future OSs. C
is the
foundation language of Windows NT and Linux - there are excellent new tools and
class
libraries coming out for it under Linux.
There are loads of different compilers, lots of commercial and freeware tools
and an
enormous literature describing how to use it well. Even Java is implemented in
C and can
call native C methods.
> Concider that when Prophet was written we were targetting machines 20MHz 286
> boxes with 1Meg of RAM plus some EMS or XMS if we were lucky. We're talking
> the glory days of 1984 here. MSDOS has just made it to version 3, and the
> tools available for the platform were not that good. LML required a tool
> that could support a large application with upto 2MB of executable code. In
> those dfays that ment that we had to use overlay technology to quish all
> that code into the available RAM.
>
> Profax's DOS product was developed about the time that DOS tools started to
> mature and the market was starting to debate the merits of building code for
> Windows 3.0.
>
> In environments like above become very difficult to worry about things like
> UI/data seperation when you have much more serious problems in geting your
> code to fit into the small amout of memory available at all!
I think you've got a good point here - the limitations of DOS were
prettyextreme. You did the best that you could at the time.
But I would argue that today's modern
operating systems are converging to identical facilities
- open 32 bit memory models make functional code
under Unix and Win32 fairly similar - it's not to hard to wrap the variations
such as threading and file APIs.(we had a library which did that at CS too) 64
bit
OSs won't really change things too much from a practical perspective - can't
think of too many business apps which require that much memory.
The details about TCP/IP is a bit of red herring - for an accounting
system like you say, you don't need it - but I my argument is that there are
huge
benefits in keeping your application layered. Business logic, network logic
and
presentation logic should be separated for a serious application.
C++ is a good language for doing networking and business logic layers because
it's so flexible and well supported - it's a complete product - it has support
for
everything in terms of OS's, profilers, memory leak checkers, decent container
classes etc.
Delphi is a great tool for doing presentation logic because it such an easy
to use environment under Windows currently. But it only supported by one
company, one OS - there is no decent profiler available for it (the only one
I've seen didn't look that great and was only available for Delphi 3 last time
I looked) The lack of templates seriously limits it functionality
for applications processing large amounts of data when collection classes
come into their own. It doesn't have the richness of libraries
etc. that C++ has.
By keeping your business code in C++ you will be able to achieve better
performance (because of profilers)
and much greater flexibility to respond to changes in the marketplace. You
could switch
to providing a Linux server with a web-interface for checking inventories etc. -
if that became
a selling point - not today maybe - but who knows what the future holds. With
Delphi
you're stuck to one company and one platform and that makes you vulnerable.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
