Gupta TD 3.1 PFT4 crashes using apd and class-variables - part 2

[ajghor]

 Posted by:  ajghor 

Dave,

Go for it.
I have always had an eye on dynalibs, but as many others, never had time to
investigate them in deep.
One of our apps is growing fast, and it seems to me that the only solution
for keeping it modular are the dynalibs. But there where just too many
issues with dynalibs that kept us from using them. Actually, we do use
them, but that are just few isolated cases.
The main problem is: we heavily use classes, from business logic to window
classes, and it seems to me that dynalibs have issues with classes, or am I
wrong?

Igor

[Dave Rabelink]

 Posted by:  Dave Rabelink 

There are issues with classes, but if you follow a set of rules while
using dynalibs there should be no problems. I only found one issue
which is fundamental but if i'm right Gupta has made a businesscase
for it and hopefully it wil be resolved.

The largest project here uses mainly dynalibs. It is a (gui) feature
rich application where the main executable is only a few hundred KB
which offers only a MDI to the end user. All functionality and GUI's
are placed in dozens of dynalibs calling eachother and giving a
structured way to developers to add new modules.

This application was originally build in 16 bits SqlWindows (even
running on os/2 windows emulator) but was eventually getting too large
to handle. Compiling did take forever and release management was a
nightmare. When TD came up with dynalibs, we ported and redesigned the
application into clear functional modules which are fitted together.
All modules are around 1Mb in size and contains only code for the
functionality of that module, we designed them to be completely
blackboxes from outside. This has increased the development
productivity, increased performance and stability for the end users
and the source code is clearly seperated into functional blocks.
Some modules contain heavily use of ActiveX (COM), large domain layers
(all kinds of classes), standard and custom GUI components, WinAPI
functionalities (eg memory maps, kernel and shell stuff), database
access to SqlBase, DB2. Reading/writing XML messages and connections
to COBOL mainframe services. I think when all is considerated, we
really push the limits of what TD can do to it's limits, and all put
into dynalibs.

When a new subproject for this application is started which needs new
functionality for a new kind of enduser, mostly we only need to place
the new module into the application and use some editors to link
transactions to the new module in the database without having to
change any of the other parts of the application. This has also
increased the speeds of releases customers ask us to do. If the
framework is right, developers only have to worry about the module and
not about the whole of the application.

Today i'm going on holiday, but when i'm back in town i will start
writing an detailed article about dynalibs in general and explain a
possible implementation for a framework and also detailed information
about the issues found with dynalibs, the workarounds and to 'do and
donts'.

Dave

On Thu, 23 Feb 2006 07:59:12 +0100, ajghor

[Ingo Pohl]

 Posted by:  Ingo Pohl 

Dave,

it would be really great if you could give that little introduction to
dynalibs...
As our Program grows and grows we need to find a way to keep it fast to
compile and the only thing i know about dynalibs is, that they behave like
dll's...

[RainerE]

 Posted by:  Rainer Ebert 

Jim,

some years ago at a developers conference in Munich, Chuck Stevenson told
that we should log every bug we find using Log-A-Bug. But the problem with
that is, that using Log-A-Bug normally does not result in bug fixes. So I
don't understand what's Log-A-Bug for? I've reported >> 30 bugs the last
years and most of them aren't fixed until now. So why should I use
Log-A-Bug? Should I open a support case instead?

Rainer

[RainerE]

 Posted by:  Rainer Ebert 

Note that dynalibs may lead to problems, if your app is running on e.g.
asian operation systems. In former times, we used dynalibs. With a newer TD
version, they worked on german and englisch Windows after a change to go
around a bug. The program was tested at the customer side in an englisch
test system and worked well. But on a japanese Windows, the program did not
work any more. So be sure, to test your app on every os language, your
customers will use.

An other note: If you have large function and class libraries which are
included in all of your program modules, they will be compiled into each
dynalib. In our case this grew up the total compiled size of the app and all
it's dynalibs by 100%. This may vary by the number of dynalibs and the
number of class libraries included in each dynalib.

And note, that at the customers side you have only a small benefit of
changing modules (dynalibs) without having all users to exit the
application. This is only possible for dynalibs, which have not been called
by any of the running programs. If a dynalib is called once, it will not be
released until the application exits (or has this changed in the meantime?).

Rainer

[Jim McNamara]

 Posted by:  Jim McNamara 

IMHO - You log the bug & get an acknowledgement.

The, if there is a business case to accelerate the priority, follow up by
opening a support case. If there is an acknowledged bug with 5 open support
cases it will certainly get more attention than an acknowledged bug & no
open support cases. If the bug creates a critical enough business issue,
they have been known to open support cases for customers with nothing higher
than license maintenance.

[RainerE]

 Posted by:  Rainer Ebert 

Jim,

I do not need an acknowledgment for bugs, I need fixes.

Rainer

[Gregor]

 Posted by:  Gregor 

Some news to this bug: Gupta answered, that the bug is reported to Version
3.1. It is not reported to Version 2005.* - in Germany we call this
"salami-taktik" :wink:

Gregor