CmdBkg - use bitmap as background to console window

[misol101]

Hi dudes, there are a way to use transparency 100 without cover the prompt?

No that won’t work, the transparency affects every part of the cmd window, text included.

[AgamSol]

Hello again, where can i get bmp images ?
i tried to convert png image to bmp image but it says "Cmdbkg error: Unable to load bitmap"

will you add other image formats in future ?

[AgamSol]

Why does the title change to kill when i load background ? is it possible to remove ?

[aGerman]

i tried to convert png image to bmp image but it says "Cmdbkg error: Unable to load bitmap"

Can be done using Paint (mspaint.exe). Ships with Windows.
For the current version of CmdBkg make sure the file name doesn't contain spaces or other special characters.

Why does the title change to kill when i load background ? is it possible to remove ?

That's hardcoded. The temporary update of the title is required to make the tool work properly.


@misol101
I'm attaching a slightly updated source code. Feel free to use it for an upcoming version.
Mainly it addresses the following:
- a variable with 64000 bytes of stack memory is critical
- string "_secondRun_" should be inserted into the original command line because surrounding quotes are already removed if it gets rearranged out of the arguments
- a combination of whitespaces is used rather than the word "Kill" and the updated title lasts 3*POLL_INTERVAL which should be more than long enough

Steffen

[misol101]

- a variable with 64000 bytes of stack memory is critical
- string "_secondRun_" should be inserted into the original command line because surrounding quotes are already removed if it gets rearranged out of the arguments
- a combination of whitespaces is used rather than the word "Kill" and the updated title lasts 3*POLL_INTERVAL which should be more than long enough

Thanks Steffen, seems like reasonable changes. By critical I assume you mean safety critical, since 64k is not so much actually, Windows programs are supposed to have a 1Mb stack. Bad form though, I agree, especially since I'm not buffer checking the strcats...oops
Not completely convinced poll*3 is always enough, Windows might be busy with other stuff in the worst case. Anyway, 500ms might not be enough either in extreme cases.

[aGerman]

Windows programs are supposed to have a 1Mb stack.

Yes, thats true. However, I've read recommendations that a stack variable should rather not exceed 1024 bytes to take care of stack frames. Also, Visual Studio complained about this variable when I enabled all warnings.

especially since I'm not buffer checking the strcats...oops

I've not been too concerned about that But I'm always concerned seeing strcat in general. Especially if it is called repeatedly in a loop. "Shlemiel the painter's algorithm" https://www.joelonsoftware.com/2001/12/ ... to-basics/

Anyway, 500ms might not be enough either in extreme cases.

That was my consideration, too. If everything works well, 2*poll is good enough. I've chosen 3* to have a little more buffer. However as you already wrote in your TODOs, it's rather a workaround right now ... Maybe I find some time to work on it.

Steffen

[aGerman]

OK, I come up with a possibility to avoid the title update. I still had to work around the broken process chain because eventually the background window has no existing parent process anymore. I just insert another argument token which contains the console HWND.
Now we can try to find the process where the command line contains " _secondRun_ <hwnd>" (<hwnd> = HEX string representing the console window handle). This is quite unique because a window handle doesn't exist twice at the same time. Then I walk along: PID -> main window handle of the process -> sending WM_CLOSE. Certainly more complicated, but you don't have to compare the title all the time in the polling loop, and I think it's more reliable.

Steffen

[aGerman]

Found a bug. New file above...

[misol101]

Found a bug. New file above...

I don't have much time to look at this at the moment but I like the idea of geting rid of the title polling and seems that it should work well.

I Will make a new release eventually

[aGerman]

I could also offer to extend the supported images formats, at least for for JPEG and GIF. I'm not too experienced with graphics stuff though. That's why I didn't find any working possibility to support PNG yet.

Steffen

//EDIT: Eventually I found a way. Although it's been a mess to figure out how to work with GDI+ in C
//EDIT2: Read the image file only once. (static variable for the HBITMAP)

[aGerman]

Found two regressions:
- if rapidly called subsequently, the prior background process might not have been closed
- the polling loop used more CPU resources as it should
That's been fixed, along with quite a bit of code updates and refactoring.

I don't want to fork the tool. However, for some beta testing you can find the compiled app, files for testing, and the source code in the attached ZIP. Just in case you want to give some feedback of how it works for you. Once Mikael comes up with a new release I'll remove it.
// EDIT Removed as promised.

Steffen

[misol101]

As far as I could tell the new version works as expected.

The archive linked in the first post has now been updated to v1.2.

I did not make any changes to Steffens new version except updated the resource file, updated the credits in code/help (as this is now very much a joint effort), and recompiled.

Pretty neat to have jpg/png/gif support!

List of changes are:

1. In addition to BMP, CmdBkg now also support JPG, PNG, and GIF (non-animated) images.
2. Supports spaces and special characters in file names
3. The window title no longer momentarily changes to "kill" when running CmdBkg

[aGerman]

Thanks Mikael!

There's still one thing bothering me. The exit(0) in the message callback will most likely leak. But I didn't get the thing working for subsequent calls without this shortcut. I'm still about to figure out why. If I can fix this we will be able to just use DefWindowProc again. It seems to be related to some weird behavior of how WMI is getting updated.

Steffen

[aGerman]

Found it
We have to call PostQuitMessage for WM_DESTROY.

My original assumption that WMI could be the culprit made me think about alternatives. And indeed I found a much easier way. Instead of passing the console HWND as additional argument it gets now assigned to the user data of the background window. Less dependencies, smaller code, easier processing, quick executable. It really makes a difference

I swear I leave it alone for a while now

Steffen

[miskox]

I really miss that I don't *speak* 'C' something.... Never had a chance to learn it (I used to program in Cobol, Visual Basic, DCL, lately PureBasic and some in disassembler (Z80 and SC61860)). Now I am too old I guess (some might say 'you are never too old').

Saso