FiveTech Software tech support forums

Enrico and others,

This concept is quite simple and common for all operating systems:

An application can not put in risk the stability of the operating system. Specially for those operating systems designed to run multiple applications simultaneously.

This concept is fundamental for the stability and security of an operating system. In other words: if this simple concept fails, then the entire operating system could crash due to an application activity. So the operating system protects itself against these potential problems.

On next msgs we are going to check this concept with some simple examples.

1. Lets try to block the system:

On this example I try to block Windows, calling a recursive C function. Please run this test and see how Windows detects the problem and blocks the application:

Code: Select all  Expand view

function Main()

  CrashTheSystem()

return nil

#pragma BEGINDUMP

#include <hbapi.h>

void CrashIt( void )
{
   CrashIt();
}

HB_FUNC( CRASHTHESYSTEM )
{
   CrashIt();
}

#pragma ENDDUMP   


2. In this example we are going to create a crazy amount of brushes without releasing them. Please open the task manager and check the physical memory used: You will notice that it remains the same after the application execution:

Code: Select all  Expand view

function Main()

   CreateLotsOfBrushes()
   
return nil

#pragma BEGINDUMP

#include <hbapi.h>
#include <windows.h>

HB_FUNC( CREATELOTSOFBRUSHES )
{
   LONG l;
   LOGBRUSH lb;
   
   lb.lbStyle = BS_SOLID;
   lb.lbColor = RGB( 255, 255, 255 );
   lb.lbHatch = HS_CROSS;
   
   for( l = 0; l < 10000000; l++ )
      CreateBrushIndirect( &lb );
}

#pragma ENDDUMP       


3. In this example we are going to try a direct attack to the operating system: We request a huge global memory, so Windows will not know if such memory has to be released, so the entire system can get in danger. But again, Windows properly protects itself. Please check physical memory from the task manager:

Code: Select all  Expand view

function Main()

   SystemAttack()
   
return nil

#pragma BEGINDUMP

#include <hbapi.h>
#include <windows.h>

HB_FUNC( SYSTEMATTACK )
{
   LONG l;
   
   for( l = 0; l < 10000000; l++ )
      GlobalAlloc( GMEM_FIXED, 10000000 );
}

#pragma ENDDUMP


Great! Thank you for the samples.

EMG

On which Windows versions did you try the samples?

EMG

Enrico,

Vista Ultimate 32 bits

I wonder if it's the same on older Windows versions...

EMG

Enrico,

Probably not.

Then better properly release resources.

EMG

Enrico,

Yes, of course. Nobody is saying the opposite.

FiveWin properly releases the ones used by the windows, dialogs and controls. If the programmer creates some more, besides those, then he is responsable for releasing them.

Though FiveWin will automatically release them at the exit of the application, in the case that the programmer didn't do it properly, and Windows itself will clean the whole application workspace finally.

Hi,

New Harbour 1.00 RC 2 creates a file, hb_out.txt, indicating which objets are not release from memory.

Moises,

We are talking about Windows GDI objects here.

Anyhow, thanks for your info. Though I guess its Harbour responsability to release all created objects from Classes, as a result of its garbage collector activity.