Console vs. Windows Executable format

Just starting out? Need help? Post your questions and find answers here.
Splondike
New User
New User
Posts: 6
Joined: Mon Aug 01, 2005 1:47 pm

Console vs. Windows Executable format

Post by Splondike »

I'm a new user to PB, and running version 3.30 (full), which I got off the cover of some magazine. It's rapidly convincing me into buying the full version, i'm very impressed :).

My question is regarding the use of the console executable format as opposed to windows. It would seem to me, that there would never be any reason to use the latter format, you can still make windows, be invisible etc., yet it seems that there is a saving to be made in the amount of memory a 'console' application uses -using windows task manager-.

Another intresting thing i've noticed, is that minimising the console window seems to reduce this memory usage even more! This would seem to be more than simply from loading/unloading the console display, as after a few routines (when the memory usage begins to climb) a quick restore/minimize reduces the overhead again.

I'm sure there's some excellant reasons for using the windows executable type, and for why i'm not really saving anything by using a console window. If anyone has a link to some article about this topic,or can quickly enlighten me, i'd appreciate it :wink:.
PB
PureBasic Expert
PureBasic Expert
Posts: 7581
Joined: Fri Apr 25, 2003 5:24 pm

Re: Console vs. Windows Executable format

Post by PB »

Console vs Window mode depends on the app, I guess. I just compiled my
major app that I'm writing, and the Console version uses slightly more RAM
than the Window version. Also, the Console version opens an ugly DOS box
which must remain open for my app to run -- closing it kills my app as well.

Minimising both versions didn't reduce the amount of RAM that Task Manager
reported for them, so again, I guess it all depends on the app.

Since you're new to PureBasic, my guess is you did some tiny tests with
small apps? My app's source is currently 174 KB (not huge either, I know)
and compiles to a 261 KB executable (with some included graphics etc),
and Console vs Window versions of it definitely show no real advantage to
either one.
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
Splondike
New User
New User
Posts: 6
Joined: Mon Aug 01, 2005 1:47 pm

Post by Splondike »

Hmm, maybe it's something they've 'fixed' subsequently; I am running an older version. You're right, I have only tested this on small GUI-less applications, but if there's no particular reason not to, I guess i'll keep doing it where it works :).

To get rid of the console window I just use the old GetForegroundWindow_(), and ShowWindow_() to minimise and then hide it.
PB
PureBasic Expert
PureBasic Expert
Posts: 7581
Joined: Fri Apr 25, 2003 5:24 pm

Post by PB »

> I am running an older version

True, I didn't consider that when doing my test. :)
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
freak
PureBasic Team
PureBasic Team
Posts: 5940
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Post by freak »

The difference between a "Console" or "Windows" Program can only be seen when executing it from the command prompt.
A Console executable has a default console, which when started from command prompt is
the current console window.
A Windows executable always opens a new console window when you call OpenConsole()

See this example:

Code: Select all

OpenConsole()
PrintN("Press Enter...")
Input()
CloseConsole()
End
When you execute it by doubleclicking on the executable or from the IDE, they look the same. (windows & console)
When you execute the executable from the command prompt, you will see
that the "windows" executable opens a new console window for the text,
where the "console" one prints to the command promt console.

So the console mode is for programs that are intended to be tools to
be executed from the commandline, or batch files or something (for the redirection of output for example)

btw, in 3.93 for Linux/Mac you will notice a Console mode too. This however
makes no difference whatsoever to the final executable. The only difference
there is that the IDE will execute such programs in a gui terminal so
you can see any console output, which you normally can't when running
from the IDE on these systems.

I hope that makes it clear.

Timo
quidquid Latine dictum sit altum videtur
Sub-Routine
User
User
Posts: 82
Joined: Tue May 03, 2005 2:51 am
Location: Wheeling, Illinois, USA
Contact:

Post by Sub-Routine »

I am about three months into PureBasic, but isn't the difference between a Console and a Window the limitied input/output of a Console and the addition of Gadgets to a Window?

I wrote my first programs using Console, but with the more complex program I am working on now I find that creating a Window and Gadgets allows the user to modify the inputs in a more intuative manner and the output can be better formatted.


Console is text in / text out. The inputs are requsted in one order.

Window is mouse or tab through the input gadgets (strings, spins, trackbars...) to change one or more and view the results in output gadgets (text, listviews, trees...)

Correct?

Rand
Splondike
New User
New User
Posts: 6
Joined: Mon Aug 01, 2005 1:47 pm

Post by Splondike »

Yeah, i'm familiar with the different methods of user interraction :wink:. What I was talking about was the apparent difference in the amount of memory each uses.

Take a look at this application -you'll have to terminate it with task manager-:

Code: Select all

OpenWindow(1, 100, 100, 100, 100, 0, "Test")
While 1
Delay (20)
Wend
Try running it under console and windows formats. Initially, the console will appear to use more memory, which makes sense; it has both the console and the window open. Now minimise the console window and take another look at the memory usage. Tell me again, why I should EVER use the windows compilation type :wink:. It is true though PB, I have only tried this on reasonably small applications -my biggest has been a trojan-y type controller for remote control between my home PCs-.
Post Reply