Interference between code in memory

[norbert doerre]

I'm quite shure that a few weeks ago I read in this forum a hint about how to avoid interference between DLLs using same INC files. This is the first time that such a noticable bug occurs with my code during the last years.
In my special case, I notice a phenomene with rubberbanding. In my CAD programm, I use vector based rubberbanding with either a line or a continuous line or any other primary entity. I don't use any Windows API based rubberbanding. My program is quite large and works with one EXE and about 120 more or less small DLLs. So, bugs could be handled quickly - normally. But there exist two DLLs with completely different tools, one using a continuous line for rubberbanding as closed polygon, the other as an open polygon. After the first DLL code with the closed Polygon is executed and the second one afterwards, invoking the second DLL after the first one shows just the last state of the closed rubberbandig polygon instead of starting with the new open polygon. There is nothing left from rubberbanding objects after a DLL's code was executed. Sorry for the long explanation, but I think that there are parts of old code still resident in memory and addressed by the new DLL.
So my question is if anyone could tell me where to find the PB code i read about to avoid such interference.

[Michael Mattias]

but I think that there are parts of old code still resident in memory and addressed by the new DLL.
So my question is if anyone could tell me where to find the PB code i read about to avoid such interference

*.INC files have nothing to do with runtime behavior, except to the extent they may contain programming errors. Properly-loaded DLLs do not execute "old" or "leftover" code, ever (should give immediate GPF).

Such "Interference" is a programming error; except possibly when using GDI functions (code not shown) on Windows 9x (operating system not shown), since Win9x GDI is that 'hybrid' 16/32 bit with shared objects. I can guarantee you from experience that making a mistake doing this can cause all kinds of "very weird" things to occur.

[norbert doerre]

Any idea from anybody else?

Michael,
I'm shure this materia is nothing for this forum. As always, I would be glad if anybody here had an idea how to explain this mysterious rubberbanding.
I know that there exists a coding errror, but not according to GDI or Windows because I'm using all libs up to date.
Again, I cannot send sample code because it uses as alway functions in my own cad library DLLs, and you would not be able to follow any operations inside the DLLs. On the other hand, the contents are barely windows relative. The whole cad program runs without throughing any error at any time, and I'm proud of this. The malfunction consists only of a kind of a lost ghost graphic from the previously executed function. The first DLL code uses a rubberbanding parallelogram entity for cutting a hole out of any bunch of objects, the other uses an open polygon rubberbanding to draw a continuous tangential sequence of arcs (arc spline). So, both DLLs have nothing to do with each other, and both are well functioning. I can call any function insíde any other DLL in any mixed mode one after the other without any ghost rubberbanding. Only if the above sequence of functions is invoked, then that faulty parallelogram rubberbanding occurs just with the 'arc spline' function at it's first step. All following steps, however, show a correct continuous line rubberbanding. If the cad program is restarted, the ghost rubberbanding disappears. I can exclude cad from being the cause of this, because all entities of the cad drawing world are handled and audited, including the rubberbands. The ghost parallelogram is in fact NOT part of the cad database. But where could it come from???

[norbert doerre]

Handle problem found.

As far as i could evaluate now, the graphical GDI parallelogram object handle is not or no more released from GDI when the routine ends. In the cad database it is deleted, however. It seems that this is a very new phenomene only with multiple polygons, perhaps related to XPSP3 or Win7, because only polygons stay in memory as multiple objects and remain accessable via their handle. When I start another function needing a GDI continuous line for screen preview, then the new rubberbanding gets the next free handle. Always, if a new function is invoked needing a continuous line rubberbanding, then it is in fact generated from GDI for the needs of this function and gets the next free handle, whereas the GDI function itself uses the first created one in the first step. So this seems to be the reason why it appears as a paralelogram ghost whereas from the cad library routine it should be a continuous line. It's a handle problem, and I have to see how to manage it.....

[Chris Boss]

Different versions of Windows may tolerate errors more readily than others.

For example, if you write code and compile on Windows XP which has some API errors, it may run on your development machine but than do something strange on say a Vista or a WIn ME machine.

This is why one must be very careful not to let any errors be left in API code, especially GDI code.

With the GDI you are using DC's plus a number of resources like fonts, brushs, bitmaps, etc. When browsing the PB forums, I quite often seen errors in some graphic code dealing with things like failing to restore a DC to its previous state or failing to unselect objects properly and the like.

Some of the errors may be tolerated by some versions of Windows they are developing on, but it may cause problems on others.

DLL's don't leave behind code as was mentioned already.

But they can leave behind problems, if they modify some state in Windows which your program does not expect later. Using different DLL's for drawing different things, is a perfect candidate for such problems, especially if they are all working in the same DC which is left open and shared between them.

If I open a DC to draw into and then ask one DLL to draw one thing and another DLL to draw another, the first DLL code may leave behind some bad conditions within the DC, which causes problems for the second DLL code which draws into the same DC.

GDI (or any graphic) errors can be pain to find. You need to track down the problem DLL and the problem routine and then go through the code carefull and see if there are any errors in dealing with the state of the DC and the resources used.

A very important error to look for is failing to free GDI objects created, when no longer needed (ie. a brush).

Many do not appreciate the damage caused by failing to free resources, particularly when the are created over and over again, but not freed. It can literally bring Windows to "its needs" and Windows can do some very strange things.

Simply put.

You have a bug in your code.

[Chris Boss]

This is a good thread to comment on this experience:

I found that when I called the printer to print something, that when certain printer drivers were used, it cause terrible problems with my app crashing. Only certain printers caused this problem.

This is an example of a driver leaving behind something nasty.

It turned out that certain printer drivers, which were written using Borland compilers (ie. C) would modify the state of the FPU (floating point math unit in CPU) and not restore them to the previous state. This wreaked havoc in PB code, which used floating point math, since the PB code expected the FPU to be in a certain state and it wasn't.

This was not caused by PB.

This was caused by the Borland compilers changing the FPU state (which ended up in the printer drivers many people used) and not restoring the FPU to its previous state when done.

I did a lot of research on the web to find this one.

The solution was for me to reset the FPU using inline assembler, every time I called the printer driver (using the open printer common dialog). It just occurs during the initialization of the printer and not afterwards.

The point of the story, is that even DLL's or drivers not written by us, can leave behind a headache if they modify something in the system, but do not return them to their previous state when done.

The moral:

When writing code for DLL's, which can be loaded by multiple applications whether our own or others, make sure one always returns the state of things (ie. a DC, CPU flags if you do assembler, etc.) back to its previous state when your code is done, otherwise you create errors which are very hard to track down.

[Michael Mattias]

DLL's don't leave behind code as was mentioned already.
But they can leave behind problems...

Um, wouldn't that second sentence be a bit be more accurate were it to state, "But neither do they automatically clean up any problems the programmer leaves behind?"

BTW, very good point about different versions of Windows being more/less forgiving.

MCM

[norbert doerre]

driver's disease

Chris,

what You write corresponds to my own experience, even these mysterious bugs with printers. I'm using registered messaging with my cad program. I think that the cause of ghost rubberbanding comes from a faulty message sequence or a faulty timing deep inside the code of my exe. But this will also be repaired. Above all, it's interesting to read Your nice experiences with printer drivers. Your words could be my words as well. With my cad program, i even deliver a detailed installation instruction explaining the most common difficulties which could occor with printers/plotters, and I'm adding advices how to handle and possibly correct a lot of these problems.
The crashes You write about are also common to me. I usually read all printer data from the printer device just to get comparable data. In most cases of a crash, for ex. the scale value becomes a huge long integer leading to an overflow in the driver. All drivers published in the Windows list do their work w/o problems. Most bugs with drivers can be eliminated with using in the following (simplyfied) code:

Select Case wParam
     Case 2406, 2411 '<Print>, <Change Printer> (Events sent by cad engine)
           Local Count As Long
           If PrinterCount > 0 Then 'Anzahl der installierten Drucker.
                'Simplified principle code, handling all printer drivers at once
                lRet = RegDelKey(%HKEY_CURRENT_USER, "Printers\DevModePerUser")
                lRet = RegDelKey(%HKEY_CURRENT_USER, "Printers\DevModes2")
           Else 'no printer installed
                RegSetVal(%HKEY_CURRENT_USER, "Software\I B D\MechaniCAD\Main\Print Settings", "Device", "")
           End If

I found out that for instance missing a preview as image is commonly caused by a timing problem with the printer driver, when software itself generates an EMF spool file which is simply overrun by some printer drivers and cannot be sent to the preview DC, recognizable by a garbage of EMF spoolfiles left back in the spool directory.(hope You understand)
In this PBWin forum it is the first time I could find a programmer suffering from the same driver's disease. Thank You!

[Chris Boss]

I can't find the original web pages I read about the FPU problem, but a quick google search found this which at least touches on the subject:

http://rave-notes.blogspot.com/2008/01/rave-reports-and-problems-with-hp.html

[norbert doerre]

FPU exceptions

Another link to avoiding floating point exceptions at CERT:

https://www.securecoding.cert.org/confluence/display/seccode/VOID+FLP02-A.+Understand+the+caveats+of+floating+point+exceptions

The problem is however to write appropriate code for usage with PB.

[Walt Thompson]

Rubberbanding

I would be glad if anybody here had an idea how to explain this mysterious rubberbanding.

FWIW: Rubberbanding is PCB CAD feature that when the user to repositions an IC or discrete component will automatically re-route the traces associated with device. The name Rubbebanding comes from the fact that the traces associated with the IC or component remain attached and stretch or shrink as the IC or component is moved around the work area.

[norbert doerre]

I think I got it.

Walter,
i cannot understand what you mean. My cad prog has nothing to do with the PCB handling you write about, even though you could do that with mine, too. My rubberbanding can be built from any cad entity in the cad database (circle, arc, bezier, spline...). The cad entity currently to be constructed is continuously drawn, but invisible. It becomes a temporary member of the cad database just to be able to snap it with high precision to other entities. At the same time gdi follows the contour of this entitiy to show it on screen. The cad entity is not visible as long as it is really placed by user. If it is cancelled, the cad database entry of the entity is purged as well as the gdi one. What happens with my prog is simply that the last used gdi image of only a continuous line gdi entity is shown again with exactly the last contour when the next to be placed entity is also a cad continuous line, even if the next contour is totally different. If the next cad contour consists of several steps, the ghost image only shows at the first step. All following steps show a standard gdi continuous line rubberbanding. The construction, however, has always the same high precision, independently from what is shown by gdi. I'm already very near to repair this problem. Only a closed cad and thus a closed gdi polygon causes this behavior. The latter one is not purged from memory after a closed polygon cad entity was sucessfully placed.