Recent

Author Topic: Maximize WinApi usage  (Read 9128 times)

flasher86

  • New Member
  • *
  • Posts: 15
Maximize WinApi usage
« on: August 29, 2010, 05:32:43 pm »
Hi. I am new at Lazarus programming, but I need to learn how to program in it FAST.

I am old Delphi programmer, but now I must take LEGAL way of creating programs.

So, what I noticed so far, is that programs created in Lazarus very rarely use WinApi natively, which concerns me.

For example, when I use MessageBox, it looks and behaves differently from Delphi version (different button look and no error sound in MB_ICONERROR option).

I assume, that it's taken care by it's own library which acts like native MessageBox winapi function but it's different.

Also I assume, that if my application is supposed to work only in WIN32 then, it will be the best to use as much WinApi functions as possible (performance). Am I right?

So is there any way to maximize usage of Winapi NATIVELY? I can link my MessageBox to winapi manually but I don't want to do this with every little thing.

Please help.

EDIT: oh and btw, why I get sometimes error when I quit from my application?
I get external SIGSEGV error, but it's visible only in debugging mode. If I run the exe manually nothing appears. But It's disturbing.
« Last Edit: August 29, 2010, 06:02:10 pm by flasher86 »

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2584
Re: Maximize WinApi usage
« Reply #1 on: August 29, 2010, 07:17:27 pm »
Hi. I am new at Lazarus programming, but I need to learn how to program in it FAST.

I am old Delphi programmer, but now I must take LEGAL way of creating programs.

So, what I noticed so far, is that programs created in Lazarus very rarely use WinApi natively, which concerns me.

why worries ? Being crossplatform, the LCL doesn't use the winapi directly. The win32 widgetset however does.
If you need the portable version of winapi, the use lclintf. This is a crossplatform  replacement for the most used winapi calls.

Quote
For example, when I use MessageBox, it looks and behaves differently from Delphi version (different button look and no error sound in MB_ICONERROR option).

I assume, that it's taken care by it's own library which acts like native MessageBox winapi function but it's different.

Under the hood on win32 the same function is used. However keep in mind that all functions are tested till XP. Not all new features are yet passed through.

Quote
Also I assume, that if my application is supposed to work only in WIN32 then, it will be the best to use as much WinApi functions as possible (performance). Am I right?

Depends on your app. Most times the winapi is not the bottleneck. If there is a minimal chance that you will run your app on linux, osx or wince (or port your app to 64bit), I would stay far away from using winapi


Quote
So is there any way to maximize usage of Winapi NATIVELY? I can link my MessageBox to winapi manually but I don't want to do this with every little thing.

Don't use Messagebox, but use the dialog unit. IIRC MessageDlg is the one you're looking for.

Quote
Please help.

EDIT: oh and btw, why I get sometimes error when I quit from my application?
I get external SIGSEGV error, but it's visible only in debugging mode. If I run the exe manually nothing appears. But It's disturbing.

I don't know your app, but maybe you're doing somthing wrong when you close your app.


//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

flasher86

  • New Member
  • *
  • Posts: 15
Re: Maximize WinApi usage
« Reply #2 on: August 29, 2010, 08:39:13 pm »
Thanks for reply

I've just started this program, and I have only IdHTTP and 2 buttons on the form. And a couple of functions regarding XML decoding.

No events corresponding to the form (onclose, onqueryclose... nothing).

But still, I got the raise exception.

My application will be running in a medium-size company. All of the computers have Windows distributions.
All of the computers have WinXP or Win98 - yeah its ancient history but their software for accessing bills and company stuff is a dos based program. (that's quite bizarre that most of such company programs are dos-based - at least in Poland where I live)

In the company I am the only one who is advanced in managing computers therefore I really can't ask them to use Linux or any other operating system. They know how to handle Windows at the beginner and necessary level only.

If only I had Delphi7 license I would with no hesitation stick to it, but I don't have and can't afford such an amount of money.

My program will be managing database of the products, and in hidden mode logging into other's companies database to play the best price in comparison with their prices. At the end I am planning to make the bill system so they will be able to migrate from old damn Windows 98.

BTW. I assume that logging into other's companies database by my own software and using it (simulating http browser) is illegal, so in case of inspection they won't find anything weird in my binaries?

AND THE MOST IMPORTANT QUESTION:
Will sticking to the WINAPI increase the performance of the whole software? I need to know that, as I tend to create insufficiently slow programs - at least this would boost it.
« Last Edit: August 29, 2010, 08:42:38 pm by flasher86 »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11452
  • FPC developer.
Re: Maximize WinApi usage
« Reply #3 on: August 29, 2010, 08:49:03 pm »

AND THE MOST IMPORTANT QUESTION:
Will sticking to the WINAPI increase the performance of the whole software? I need to know that, as I tend to create insufficiently slow programs - at least this would boost it.

Then don't worry, the answer is no. On Windows the LCL layer is fairly thin, and nearly free. This is because the LCL mimics the VCL which was designed to run on top of winapi.  The overhead is so low it is probably not even measurable (because the average windows message used in the GUI is already slower)

krexon

  • Jr. Member
  • **
  • Posts: 80
Re: Maximize WinApi usage
« Reply #4 on: August 29, 2010, 09:39:31 pm »
I get external SIGSEGV error, but it's visible only in debugging mode. If I run the exe manually nothing appears. But It's disturbing.

I have the same problem :) I have not found explanation for this.

OpenLieroXor

  • New Member
  • *
  • Posts: 38
Re: Maximize WinApi usage
« Reply #5 on: August 29, 2010, 09:50:09 pm »
oh and btw, why I get sometimes error when I quit from my application?
I get external SIGSEGV error, but it's visible only in debugging mode. If I run the exe manually nothing appears. But It's disturbing.
It seems to be a bug in GNU debugger on Windows, or a conflict with some firewalls or other security programs. The only solution I know is disabling the debugger (go to Enviroment|Options|Debugger and in debugger type field select (none)).

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11452
  • FPC developer.
Re: Maximize WinApi usage
« Reply #6 on: August 29, 2010, 10:10:53 pm »
Note that in general programs in debuggers sometimes behave differently as exactly the same program outside. This has to do with the fact that sometimes the debugger initializes the program's memory in a different way than the OS would. >:D

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2584
Re: Maximize WinApi usage
« Reply #7 on: August 30, 2010, 12:08:52 am »
oh eh, about the SIGSEGV, are you happen to run a comodo firewall ?
if so search this forum on comodo
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

flasher86

  • New Member
  • *
  • Posts: 15
Re: Maximize WinApi usage
« Reply #8 on: August 30, 2010, 10:37:08 am »
I am using ESET Smart Secuirty. But this may also be the reason.

I noticed that when I use IdHTTP as a component on the form this error occurs, but when I create IdHTTP at runtime procedure it's ok. Perhaps it is caused by inappropriate freeing memory for IdHTTP by the application. The same error occurs when I try to free memory from a component that hasn't been created yet, so maybe it's a bug that an app tries to free the memory twice or something like that.

 

TinyPortal © 2005-2018