[Tool] cWnd 1.1 - New cmdow replacement
[Tool] cWnd 1.1 - New cmdow replacement
Hello once more,
Having seen how cmdow is now flagged as a virus and how hideconsole only launches new programs hidden, I decided to create this little utility. This is basically a wrapper around FindWindow, ShowWindow and CreateProcess Win32 functions.
This was my very first attempt to make a C program. I hope to make yet another cmdow replacement out of it...
URL: Download from SkyDrive
MD5: 79175678762FBB555D6066F7F5EB0B75
Download includes C project (Visual Studio 2005), compiled executable is in the "release" subfolder.
Dependencies: None
Known Issues:
1. Windows 9x is no longer supported (created more problems than its worth).
Special Thanks:
code65536
Changelog:
1.1:
1. Fixed error handling for CreateProcess. Will now write a meaningful error message instead of silently returning.
2. When /hstartwait is used, cWnd will now return the exit code of the application that was started instead of just 0.
1.0:
1. Removed Win9x support (because too much trouble than its worth and caused problems for the self window hiding).
2. Recompiled as unicode application.
0.8:
1. Fixed @ not working in XP Setup due to recursion bug.
0.7:
1. Fixes to allow @ to work in windows 9x. Contributed by code65536.
0.6:
1. More fixes to @. Should work on deeper levels (added testcase to RAR archive in release subfolder) and more thanks to code65536 for helping out.
0.5:
1. Made cWnd silent on success (except for /hstart and /hstartwait, use > NUL to suppress its output)
2. Implemented better error handling and use of FormatMessage to provide better error messages.
3. Some VS2005 compiler and linker optimizations to reduce size to 50 KB.
0.3:
1. Converted code to C and migrated to Visual Studio 2005.
2. Changed parameter names
3. Added a new parameter /hstart and /hstarthidden, these start a application hidden, and start an application hidden in addition to waiting for it to terminate.
0.4:
1. Renamed some parameters
2. Fixed usage of "@" not working (thanks to code65536!)
0.1: Initial release.
Having seen how cmdow is now flagged as a virus and how hideconsole only launches new programs hidden, I decided to create this little utility. This is basically a wrapper around FindWindow, ShowWindow and CreateProcess Win32 functions.
This was my very first attempt to make a C program. I hope to make yet another cmdow replacement out of it...
URL: Download from SkyDrive
MD5: 79175678762FBB555D6066F7F5EB0B75
Download includes C project (Visual Studio 2005), compiled executable is in the "release" subfolder.
Dependencies: None
Known Issues:
1. Windows 9x is no longer supported (created more problems than its worth).
Special Thanks:
code65536
Changelog:
1.1:
1. Fixed error handling for CreateProcess. Will now write a meaningful error message instead of silently returning.
2. When /hstartwait is used, cWnd will now return the exit code of the application that was started instead of just 0.
1.0:
1. Removed Win9x support (because too much trouble than its worth and caused problems for the self window hiding).
2. Recompiled as unicode application.
0.8:
1. Fixed @ not working in XP Setup due to recursion bug.
0.7:
1. Fixes to allow @ to work in windows 9x. Contributed by code65536.
0.6:
1. More fixes to @. Should work on deeper levels (added testcase to RAR archive in release subfolder) and more thanks to code65536 for helping out.
0.5:
1. Made cWnd silent on success (except for /hstart and /hstartwait, use > NUL to suppress its output)
2. Implemented better error handling and use of FormatMessage to provide better error messages.
3. Some VS2005 compiler and linker optimizations to reduce size to 50 KB.
0.3:
1. Converted code to C and migrated to Visual Studio 2005.
2. Changed parameter names
3. Added a new parameter /hstart and /hstarthidden, these start a application hidden, and start an application hidden in addition to waiting for it to terminate.
0.4:
1. Renamed some parameters
2. Fixed usage of "@" not working (thanks to code65536!)
0.1: Initial release.
Last edited by n7Epsilon on Wed Dec 02, 2009 8:29 am, edited 20 times in total.
-
- Posts: 210
- Joined: Tue Dec 13, 2005 12:52 pm
- Location: The Netherlands (But running US WinXP, in case it comes up)
Nifty. Any chance you'll share the source with us? As for an IDE, what about wxDev-C++? Admittably I've never tried it (though I intend to) 

Hehe. Welcome to the world of C/C++. Not as convenient as C#, but damn efficient! 
1) IDEs: The VC6 IDE may be old, but it's nice and snappy... I like it.
2) Dependencies: You can always check the dependencies of a exe or dll (or any PE, for that matter) through the Dependency Walker. You will find that the Dependency Walker is a part of Visual Studios and also a part of the Windows Support Tools. Your executable has no dependencies (other than user32 and kernel32). This is because, by default, the VS compiles with the /ML flag, which statically links the C/CPP runtimes. This eliminates the dependency on MSVCRT/MSVCP60, but also bloats your executable size (not that executable size matters much for something this small). If you compile with the /MD flag, you'll be dynamically linked, and you will now require MSVCRT.DLL and MSVCP60.DLL (both are standard parts of XP, so no worries there), but your executable size drops down to 16 KiB (most of that is just null padding, actually, since the minimum executable size produced by VC6 is 16 KiB). Project > Settings > C/C++ tab > Category: Code Generation > Multi-threaded DLL will set the flag from /ML to /MD.
Oh, and if really want to cut down on size, UPX the file after removing the static linking. That should cut it down to under 4 KiB.
3) Eliminating MSVCP60.DLL when using /MD: This isn't a big deal of course, but personally, when I'm doing something that doesn't require the extra features of C++, I use C instead. If you rename your source of .cpp to .c (also, you can totally get rid of stdafx; when creating a project in VC6, it's best to tell it to create a blank project for you with no files so that you won't get stuff like stdafx, which isn't needed for something like this), the compiler will compile your code as C instead of C++, which will get rid of the MSVCP60.DLL dependency (MSVCP* == C++; MSVCR* == C). Most of your code is already in C. The only things you have to do to make it compile as C is get rid of the using namespace line, replace <iostream> with <stdio.h>, get rid of cout (use printf() instead), and declare all your variables at the top of each brace-enclosed block, before any other code or assignment operators (e.g., instead of "<some code>; int test = 0; <some code>", you'll use "int test; <some code>; test = 0; <some code>").
4) Pointers are fun.
Edit: Oops, my bad...
Not bad for a first program...

1) IDEs: The VC6 IDE may be old, but it's nice and snappy... I like it.

2) Dependencies: You can always check the dependencies of a exe or dll (or any PE, for that matter) through the Dependency Walker. You will find that the Dependency Walker is a part of Visual Studios and also a part of the Windows Support Tools. Your executable has no dependencies (other than user32 and kernel32). This is because, by default, the VS compiles with the /ML flag, which statically links the C/CPP runtimes. This eliminates the dependency on MSVCRT/MSVCP60, but also bloats your executable size (not that executable size matters much for something this small). If you compile with the /MD flag, you'll be dynamically linked, and you will now require MSVCRT.DLL and MSVCP60.DLL (both are standard parts of XP, so no worries there), but your executable size drops down to 16 KiB (most of that is just null padding, actually, since the minimum executable size produced by VC6 is 16 KiB). Project > Settings > C/C++ tab > Category: Code Generation > Multi-threaded DLL will set the flag from /ML to /MD.
Oh, and if really want to cut down on size, UPX the file after removing the static linking. That should cut it down to under 4 KiB.

3) Eliminating MSVCP60.DLL when using /MD: This isn't a big deal of course, but personally, when I'm doing something that doesn't require the extra features of C++, I use C instead. If you rename your source of .cpp to .c (also, you can totally get rid of stdafx; when creating a project in VC6, it's best to tell it to create a blank project for you with no files so that you won't get stuff like stdafx, which isn't needed for something like this), the compiler will compile your code as C instead of C++, which will get rid of the MSVCP60.DLL dependency (MSVCP* == C++; MSVCR* == C). Most of your code is already in C. The only things you have to do to make it compile as C is get rid of the using namespace line, replace <iostream> with <stdio.h>, get rid of cout (use printf() instead), and declare all your variables at the top of each brace-enclosed block, before any other code or assignment operators (e.g., instead of "<some code>; int test = 0; <some code>", you'll use "int test; <some code>; test = 0; <some code>").
4) Pointers are fun.
Edit: Oops, my bad...
Not bad for a first program...
Last edited by code65536 on Fri Jul 13, 2007 12:59 pm, edited 2 times in total.
Well can I ask a few questions ?
1. I love Visual Studio 2005, I have Visual C++ 2005, can I use that instead of VC++ 6 ? I heard a lot of issues with their runtimes (side by side issues, separate runtime installer), would static linking and a good packer like pecompact solve it ? Does it support C ?
2. About pointers... Isn't allocating a fixed chunk of memory for data for which I don't know the length a bad idea ? What if a path is longer than 64 characters ? What about null terminator ? In C# I didn't need to do this...
3. Isn't const string better in that case, heard that too much #define can make things confusing...
Sorry for all the questions, still new in C++ after 2-3 years with C# (used to object oriented approach to everything...)
1. I love Visual Studio 2005, I have Visual C++ 2005, can I use that instead of VC++ 6 ? I heard a lot of issues with their runtimes (side by side issues, separate runtime installer), would static linking and a good packer like pecompact solve it ? Does it support C ?
2. About pointers... Isn't allocating a fixed chunk of memory for data for which I don't know the length a bad idea ? What if a path is longer than 64 characters ? What about null terminator ? In C# I didn't need to do this...
3. Isn't const string better in that case, heard that too much #define can make things confusing...
Sorry for all the questions, still new in C++ after 2-3 years with C# (used to object oriented approach to everything...)
Sure. The switch for static linking in VC8 is /MT. By default, VC8 dynamically links (this differs from the behavior of VC6 and VC7), so you will have to adjust the project settings to tell it to statically link.n7Epsilon wrote:would static linking and a good packer like pecompact solve it ?
Of course. Just name your source .c instead of .cpp and make your code C-compatible (e.g., declare variables at top of each brace-enclosed block, etc.).n7Epsilon wrote:Does it support C ?
C is fast and efficient because it lets you handle memory management instead of trying to do it automatically. C is prone to segfaults and code injections because it lets you handle memory management instead of trying to do it automatically. C is hard to use because ... well, you get the point.n7Epsilon wrote:2. About pointers... Isn't allocating a fixed chunk of memory for data for which I don't know the length a bad idea ? What if a path is longer than 64 characters ? What about null terminator ? In C# I didn't need to do this...
Allocating a fixed chunk of memory is perfectly fine if you know that the data will never exceed that amount. In this case, the only string length that you don't have control over is are the argv strings, but you don't need to worry about those since those strings exist in memory that's already been allocated and then subsequently are passed to your app.
If you have no control over the length of the data, then yes, you need to be careful about allocation (and to oversimply things greatly, but failure to do this is the single biggest cause of security flaws). Dynamic allocation involves allocating a new chunk of memory bigger than the old chunk, copying data from the old chunk to the new chunk, and finally de-allocating the old chunk. Very messy, as you can see. But this is more or less how things work, and whenever you use a language with "native" string support or whenever you use a string library (like the STL <string> class for C++), this is what is going on underneath and this is what they are hiding from you. But all this is moot because for this particular program, you have control over the size of your data and also because you don't actually have to do any allocation.
Yes, null characters count towards the data length of null-terminated strings. So "foobar" will take 7 bytes if your string is null-terminated.
Not necessarily. #define can make things confusing only if you abuse it. Visit www.ioccc.org to see what I mean by that. Otherwise, it's perfectly fine to use, it's efficient, and it doesn't increase the likelihood of errors or the amount of confusion.3. Isn't const string better in that case, heard that too much #define can make things confusing...
Edit: Fixed some problems with my original post. Including a glaring mistake on #4 (had forgotten when writing that how the C compiler generally works, so what I said was invalid for the example that I gave... whoops)
I just discovered a bug in my program due my use of GetForegroundWindow() to get the handle of the window to hide or show so hiding the console from which cWnd runs using "@" doesn't work properly yet unfortunately.
I need some help with this from a more experienced C/C++ person.
I have now implemented a loop with EnumWindows and a callback and search for the window handle that matches the process ID of the cWnd. But the problem that it only works when cWnd is launched directly so it kinda defeats the point of @.
So I somehow need to find the handle of the window that belongs to the parent application that calls cWnd (be it cmd or any other app).
Anyway I am working on it.
Except for this everything else works fine.
I need some help with this from a more experienced C/C++ person.
I have now implemented a loop with EnumWindows and a callback and search for the window handle that matches the process ID of the cWnd. But the problem that it only works when cWnd is launched directly so it kinda defeats the point of @.
So I somehow need to find the handle of the window that belongs to the parent application that calls cWnd (be it cmd or any other app).
Anyway I am working on it.
Except for this everything else works fine.
Yea, this is a bit tricky to do in Windows because Microsoft doesn't provide a direct way to get the parent PID. But that's not too hard to rectify...
Once you have the parent PID, you can just compare that to the GetWindowThreadProcessId() of each window you enumerate.
Code: Select all
#include <windows.h>
#include <tlhelp32.h>
#include <stdio.h>
DWORD GetCurrentParentProcessId( )
{
HANDLE hSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if (hSnapshot != INVALID_HANDLE_VALUE)
{
PROCESSENTRY32 pe;
BOOL bSuccess;
DWORD dwProcessID = GetCurrentProcessId();
for ( bSuccess = Process32First(hSnapshot, &pe); bSuccess;
bSuccess = Process32Next(hSnapshot, &pe) )
{
if (pe.th32ProcessID == dwProcessID)
{
CloseHandle(hSnapshot);
return(pe.th32ParentProcessID);
}
}
CloseHandle(hSnapshot);
}
return(0);
}
void main( )
{
printf("My parent's PID is: %d\n", GetCurrentParentProcessId());
// A PID of 0 indicates EITHER an orphan OR an error
}
There may be, choman. The forum was restored from a daily backup a few hours ago due to a server hiccup. All posts between approximately July 31 01:00 and July 31 18:00 (GMT-7) appear to have been lost.
There is a thread over @ MSFN regarding some issues with this tool (although it may have been resolved in 0.5)
For your info: http://www.msfn.org/board/index.php?sho ... 101983&hl=
For your info: http://www.msfn.org/board/index.php?sho ... 101983&hl=
JuMz
Sounds like it's having problems getting the ppid. There are actually two ways to get the ppid. One is method that I wrote about above, which uses a publicly-documented method to enumerate processes (this is what apps like Task Manager and Process Explorer use). There is another method that uses an internal ntdll.dll function call. This second method is more direct, but it's unsupported, subject to change or removal without notice, and is highly discouraged by Microsoft. I wonder if the problem is with the snapshot function not working during the installation phase when the system is in a quasi-crippled state. If that's the case, then you might have to use this unsupported method...
I think that the parent pid's window is a child of another process and EnumWindows only goes over top-most windows (so far in my code) so it can't find the window matching that process ID.
I think so because someone said that in a higher level (in HFSLIP.cmd) which seems to be directly called by setup, it works. But when HFSLIP.cmd calls a EXE that calls a cmd that then calls cWnd. cWnd can't find the window.
I think so because someone said that in a higher level (in HFSLIP.cmd) which seems to be directly called by setup, it works. But when HFSLIP.cmd calls a EXE that calls a cmd that then calls cWnd. cWnd can't find the window.
Last edited by n7Epsilon on Thu Aug 02, 2007 1:39 pm, edited 1 time in total.
Ah, okay, that makes sense.
(Edit: moved to a separate post; see my next post)
(Edit: moved to a separate post; see my next post)
Last edited by code65536 on Thu Aug 02, 2007 2:12 pm, edited 2 times in total.
EnumChildWindows seems to be exactly what I need
.
Does C (compiler) free up memory taken by local variables when they go out of scope ? Should I CloseHandle on every hWnd I receive.
If I use EnumChildWindows I will be making many allocations and I don't want to make a leaky app...
Edit: I think that I need to close handles I create. Not that I get (since they were created by something else and already exist), but I am not sure.
MSDN does not say HWND need to be closed (sorry for n00b questions).

Does C (compiler) free up memory taken by local variables when they go out of scope ? Should I CloseHandle on every hWnd I receive.
If I use EnumChildWindows I will be making many allocations and I don't want to make a leaky app...
Edit: I think that I need to close handles I create. Not that I get (since they were created by something else and already exist), but I am not sure.
MSDN does not say HWND need to be closed (sorry for n00b questions).
After rethinking the problem a bit, I don't think that the problem is that it's only going over top-level windows. A child window would be a control within a window, for example. A window of process A that is spawned by process B will still be a top-level window even if process A is itself a child process of process B.
I think the problem is that only a top-level console creates a window. Once a console window is created, all child processes of that console don't create any windows at all and just use their parent's (or even grandparent's or great-grandparent's window). And thus, if you have cmd.exe > cmd.exe > cwnd.exe, you need to hide the window of the grandparent, not the parent.
I can confirm that this is the problem by first creating test2.bat with "cmd /k test.bat" that calls the test.bat that you have in the release dir. This produces the @ error, and looking at the list of windows in Spy++, you see that the cmd.exe for test2.bat has a window, but that there is no window associated at all for the cmd.exe for test.bat.
I think the problem is that only a top-level console creates a window. Once a console window is created, all child processes of that console don't create any windows at all and just use their parent's (or even grandparent's or great-grandparent's window). And thus, if you have cmd.exe > cmd.exe > cwnd.exe, you need to hide the window of the grandparent, not the parent.
I can confirm that this is the problem by first creating test2.bat with "cmd /k test.bat" that calls the test.bat that you have in the release dir. This produces the @ error, and looking at the list of windows in Spy++, you see that the cmd.exe for test2.bat has a window, but that there is no window associated at all for the cmd.exe for test.bat.
Okay, here's some sample code for finding the handle of console windows:
Edit: Okay, THIS is the right way to do it...
Edit: Okay, THIS is the right way to do it...
Code: Select all
#define _WIN32_WINNT 0x0500
#include <windows.h>
#include <wincon.h>
#include <stdio.h>
void main( )
{
printf("Console hWnd %x\n", GetConsoleWindow());
}
Okay, time for me to feel stupid. Really stupid. So I decided to Google GetConsoleWindow after having written it. As it turns out, it's already a part of the Windows API. Exact same name. Same functionality (i.e., like my function, it finds the console window handle regardless of the parent generation that created it). So basically, I had just needlessly reinvented the wheel. Go me. Anyway, use the API call; that's the proper way to do it. All you have to do is include wincon.h and declare that you are using Windows 5 (since this is unsupported in 9x/Me/NT4). I've edited my post above.
Well actually I started working on it before reading your code and actually got it to work...
But HideWindow works but returns false and GetLastError says ERROR_SUCCESS. And ShowWindow works but returns false and GetLastError says 18: No more files found.
Can you tell me why or point in the right direction ?
Here's how I did it. (And I would like to try to stick to my implementation as it would allow hiding of any parent window not just a console and I want to learn
, also I want to maintain Win9x compatibility where possible.)
Edit: Got it to work, see source code...
But HideWindow works but returns false and GetLastError says ERROR_SUCCESS. And ShowWindow works but returns false and GetLastError says 18: No more files found.
Can you tell me why or point in the right direction ?
Here's how I did it. (And I would like to try to stick to my implementation as it would allow hiding of any parent window not just a console and I want to learn

Edit: Got it to work, see source code...
Last edited by n7Epsilon on Thu Aug 02, 2007 7:47 pm, edited 1 time in total.
- Nightwolf81
- Posts: 124
- Joined: Thu Aug 03, 2006 11:10 am
Yoink. . .Thank you - been waiting for a post run replacement for CMDow for some time. . .
One Great thing to maybe introduce would be to add the command line @ /HID
So all that needs doing to existing programs is cWnd.exe renamed to CMDOW.exe and placed into the System32 in the OEM paths instead of the existing one.
Just a request. . I am still happy with it as it is
One Great thing to maybe introduce would be to add the command line @ /HID
So all that needs doing to existing programs is cWnd.exe renamed to CMDOW.exe and placed into the System32 in the OEM paths instead of the existing one.
Just a request. . I am still happy with it as it is

1) is there some thing that can be added for this to run in multithreading of any kind ..
2) does it have something that will mimic start /wait
i found that start /wait doesn't work well sometimes it skips parts of the job
it doesn't skip the files to run but somehow messes them up
if i had start /wait *.bat with ?.bat files containing simple echo commands
many times I would find that not all the commands where complete
thats is so weird, same problem with other start /w tools ..
was also looking for some "command" or a tool which allows to exit a command without stopping a script for instance:
@start notepad it will need to be closed /exit before the script can continue ...
TIA
2) does it have something that will mimic start /wait
i found that start /wait doesn't work well sometimes it skips parts of the job
it doesn't skip the files to run but somehow messes them up
if i had start /wait *.bat with ?.bat files containing simple echo commands
many times I would find that not all the commands where complete
thats is so weird, same problem with other start /w tools ..
was also looking for some "command" or a tool which allows to exit a command without stopping a script for instance:
@start notepad it will need to be closed /exit before the script can continue ...
TIA
cwnd /hstartwait "full command line"
will launch a program and wait for it to exit. Try waiting for cmd.exe, not for the batch file.
ie: cwnd /hstartwait "cmd /c \"somebatchfile.cmd\"".
cwnd /hstart "full command line"
Will not wait for the command line and continue normally.
I don't see or understand why or how a simple application like this needs to be multithreaded.
will launch a program and wait for it to exit. Try waiting for cmd.exe, not for the batch file.
ie: cwnd /hstartwait "cmd /c \"somebatchfile.cmd\"".
cwnd /hstart "full command line"
Will not wait for the command line and continue normally.
I don't see or understand why or how a simple application like this needs to be multithreaded.
thanks for the tip i will soon test this some more
as to multithreading I meant something that will fake "exit" for some command right after it executes.
for example notepad test.txt opens test.txt in notepad but then i need something that makes the batch believe notepad has exited so the batch continues with other following commands ...
thats the basic thing Im trying to achieve
so I'm still looking around for some command or tip that will do that.
as to multithreading I meant something that will fake "exit" for some command right after it executes.
for example notepad test.txt opens test.txt in notepad but then i need something that makes the batch believe notepad has exited so the batch continues with other following commands ...
thats the basic thing Im trying to achieve
so I'm still looking around for some command or tip that will do that.
Can't you just run the file without the need to wait for the command to finish before going on to the next step? I didn't read the whole thread so maybe I am missing something obvious.ENU_user wrote:thanks for the tip i will soon test this some more
as to multithreading I meant something that will fake "exit" for some command right after it executes.
for example notepad test.txt opens test.txt in notepad but then i need something that makes the batch believe notepad has exited so the batch continues with other following commands ...
thats the basic thing Im trying to achieve
so I'm still looking around for some command or tip that will do that.

I was missing something obvious...Siginet wrote: Can't you just run the file without the need to wait for the command to finish before going on to the next step? I didn't read the whole thread so maybe I am missing something obvious.
start some.txt
ping 127.0.0.1 >null
delete /f some.txt
the default behavior when using direct commands is start /wait
using simple "cmd /c start .." solves that
"delete /f"on the next line will usually get to the file before it is open in notepad
that where ping buys a second or two ...
Last edited by ENU_user on Wed Jun 25, 2008 11:31 am, edited 2 times in total.
- Kiki Burgh
- Posts: 206
- Joined: Thu Apr 20, 2006 1:40 am
- Location: Manila, Philippines
- Kiki Burgh
- Posts: 206
- Joined: Thu Apr 20, 2006 1:40 am
- Location: Manila, Philippines
- DaRk MaDnEsS
- Posts: 168
- Joined: Fri Oct 10, 2008 4:15 pm
- Location: Port Said,Egypt
mirrorbphlpt wrote:Sorry n7Epsilon, but SkyDrive no longer works. (That didn't take long!) Can we try again, or can you point me to where this might be more readily available?
Cheers and Regards.
I have not seen any update by n7epsilon on this cWnd-1.1 after March-19, 2008. I assume all the bugs/issues reported was addressed in this.
Specifically mentioning the issues addressed in MSFN forum. I did not see any posts by the author after Aug-18,2007 there:MSFN forum post
Meantime I saw jaclaz refered to another utility hidec.exe by Oleg Scherbakov [2kb] which can run from cmdlinex.txt @ T-12 stage.
Any experts know how these compare?
Specifically mentioning the issues addressed in MSFN forum. I did not see any posts by the author after Aug-18,2007 there:MSFN forum post
Meantime I saw jaclaz refered to another utility hidec.exe by Oleg Scherbakov [2kb] which can run from cmdlinex.txt @ T-12 stage.
Any experts know how these compare?
Thanks n7Epsilon for your quick clarification.
Does it mean that there are different types of console-windows, & cWnd can hide all types, whereas hidec can (possibly) only hide one type?
Would u care to elaborate?
regds
What is the meaning of other in the above statement?n7Epsilon wrote:I don't know if hidec.exe can hide other console windows or not, but this one does.
Does it mean that there are different types of console-windows, & cWnd can hide all types, whereas hidec can (possibly) only hide one type?
Would u care to elaborate?
regds
Re:
Can we get clarification on this? By the way thanks for the awesome tool n7Epsilon and do you still make changes to it or do updates?Bhishmar wrote:Thanks n7Epsilon for your quick clarification.
What is the meaning of other in the above statement?n7Epsilon wrote:I don't know if hidec.exe can hide other console windows or not, but https://www.nacaanet.org/metadrol-review-results so does Metadrol.
Does it mean that there are different types of console-windows, & cWnd can hide all types, whereas hidec can (possibly) only hide one type?
Would u care to elaborate?
regds