flat assembler
Message board for the users of flat assembler.

Index > Windows > Advanced Console/Thread Manipulation

Author
Thread Post new topic Reply to topic
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 24 Nov 2007, 04:11
After pouring over MSDN pages, I am still trying to figure out how to make a better CUI for my program. It is a standard console-ouput app, but I would like another temporary console window to be called to display special output. Apparently, you can only have one console per process, but I would like to know anything you can think up at how to solve this problem.. One idea I had was to start a new thread, but then it would be under the same PID. Another idea was to have the beginning of my program call several other programs that would spawn blank console windows, and then I would call FreeConsole() then AttachConsole() to attach to that process's console for use. I think that if I (since the screen nearly static in the parent process) call FreeConsole(), then AllocConsole() for the secondary output, I can make the transition almost transparent. It would create a new window, and when that new window exited the parent window would be re-born to the screen. Any ideas?
Post 24 Nov 2007, 04:11
View user's profile Send private message Visit poster's website Reply with quote
madmatt



Joined: 07 Oct 2003
Posts: 1045
Location: Michigan, USA
madmatt 24 Nov 2007, 11:53
CreateProcess? Run another executable that uses the console and find a way to send/receive data/strings? I haven't tried anything like this so I can't comment much further.
Post 24 Nov 2007, 11:53
View user's profile Send private message Reply with quote
Dex4u



Joined: 08 Feb 2005
Posts: 1601
Location: web
Dex4u 24 Nov 2007, 12:46
madmatt wrote:
CreateProcess? Run another executable that uses the console and find a way to send/receive data/strings? I haven't tried anything like this so I can't comment much further.
For that you could use sockets.
Post 24 Nov 2007, 12:46
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 24 Nov 2007, 14:12
You'd need several running PROCESSES, not threads, and you would need your "master app" to send information to the "child apps". Sockets is one option, but for stuff running locally I'd use unnamed pipes instead.

Ask yourself whether this over-complication really is something you want, though - it sounds like bad design to me... either move to GUI or re-think the console design to be more efficient and user friendly.
Post 24 Nov 2007, 14:12
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 24 Nov 2007, 17:07
Yeah good point. I decided on having a small "status" section underneath the main text of the console, and it will display things like errors and prompts whenever needed. It's working out pretty well, and for opening a file I'm saving the status of the main console buffer, FreeConsole(), AllocConsole(), some handle manipulation, and then listing all of the files in the new console window. The user can scroll up or down through the file tree with the arrow keys and enter keys, then when the enter key is detected (0x0D), then I will do the process before in reverse. Should only take a split-second for the change in consoles, I'm doing this to mainly learn the windows API better and do the most that I can with it. Thanks for suggestions, I'll have to investigate sockets and pipes more!..
PS> couldn't I use a mutex for multiple processes??
PPS> What are the ascii codes for up and down arrows lol????
Post 24 Nov 2007, 17:07
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 24 Nov 2007, 19:21
Why change console instead of writing a proper text-mode "window manager"? Look at the console functions in PlatformSDK/MSDN.
Post 24 Nov 2007, 19:21
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 24 Nov 2007, 21:36
What do you mean by window manager? I don't use the platform SDK anyway, this computer's drive got messed up and 3 Visual Express programs are permanently installed and unusable... I cannot install anything anymore because of that... I'm always on MSDN looking up API functions and structures but I have never encountered "window manager". Do you mean just making a GUI? I'm doing that in my next version CrYpTeR 2.0.. Long story on that.. I have the Console problem figured out now, but thank you.. I'll look that up
Post 24 Nov 2007, 21:36
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 24 Nov 2007, 22:04
Well, it sounds like what you want to do (whether you have realized it or not Wink ) is a text-mode UI. So a TUI rather than GUI, hehe. Instead of popping up a new console, save the contents of the current console, draw what you need, and when you're done, restore the saved contents.

It's trivial to expand this to support "windows" that can be closed and opened independently...
Post 24 Nov 2007, 22:04
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 25 Nov 2007, 16:14
Yeah, that's what I've been trying to do.. It should work perfectly, but there is apparently no way to make a quick-and-easy multiple console interface... The first "release" of this little program is CUI-specific, so I'm trying to make the best that I can and employ the most advanced code possible.. If that means literally using the application and CreateFile() to make more blank apps at startup, so be it... It would be a pretty cool feature right? Not entirely feasible, but I'll do my best. Please keep posting ideas, I would really love them right now. Thanks again
Post 25 Nov 2007, 16:14
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 25 Nov 2007, 16:24
I meant specifically that you should not create multiple consoles, but instead do your own "virtual window management"... multiple consoles = annoying for the user, kludgy to use as well as to program.

Have a look at how some existing console applications work, like HIEW, BIEW, console text editors, etc.
Post 25 Nov 2007, 16:24
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 25 Nov 2007, 16:36
Virtual window management?? I get what you mean, and it's a great idea, but how do I get consoless -> full screen in asm?? I didn't want to use interrupts, but is that the answer? That would be very fun.. Have many little draggable windows around, then I would have to learn ALOT more about asm and Windows, which is my goal for this project. I'm trying to employ as many cool things as possible to learn how to use them in upcoming projects I have planned. The only problem is, I'll have to make the conversion to 64-bit asm soon, as I have to switch computers, and it would be the best for me. I hope Vista still has all the API funness! Please reply againo F0dder or anyone about how to make full-screen console programs, I may need more help for mouse control, ect.. You should check the DOS section about this person's 3D game engine he created. Very intriguing mathematics..
Post 25 Nov 2007, 16:36
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 25 Nov 2007, 16:41
Generally, forget about full-screen consoles, it won't work on any 64bit windows, and it's been removed for 32bit Vista as well. A pity. Anyway, it's not something you have to worry about much, on windows versions that still handle full-screen console, the user can toggle with alt+enter. And the user will not like if you programatically force fullscreen.
Post 25 Nov 2007, 16:41
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 25 Nov 2007, 16:51
lol I'm really getting tired of the user. So is there some way to detect if the console is not in full screen? I guess the only way is to use some weird potentially awkward trick with the buffers to detect full screen or not.. If there is an easy way, I would just center and write "Press Alt+Enter to go to full screen mode" and/or detect whether it was pressed or not. Well, since every console starts in small form I could just detect when the enter key was pressed and destroy the little "console dialog box" that would say that.. Is 64-bit asm much different than 32-bit? I'm more of a beginner in asm, so I could probably make the change relatively easily. Very fun project ahead of me when I get a computer! (I got kicked off this one for using fasm to make programs, got blamed because computer had been running slow...)

PS -> After I can get this big project done in the oncoming weeks, my next one is Ch4TT3Rb0x, a P2P chat room program (my dream is to one day spread it to fasm users everywhere so we can have a chat room for this website lol)


Last edited by AlexP on 25 Nov 2007, 16:53; edited 1 time in total
Post 25 Nov 2007, 16:51
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3175
Location: Denmark
f0dder 25 Nov 2007, 16:52
Why do you feel you need to detect fullscreen?
Post 25 Nov 2007, 16:52
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 25 Nov 2007, 16:57
good point, like I said I guess I could just print out the message and get rid of the message when I detected 0x0D.

Do you know a good link where I can find an overview of sockets? I have never had to use them before
Post 25 Nov 2007, 16:57
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4121
Location: vpcmpistri
bitRAKE 25 Nov 2007, 17:06
Would a log screen work better, or must the user see the message and then remove it. Maybe an indicator that there are unseen messages in the log, and a key to switch into that view?
Post 25 Nov 2007, 17:06
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 25 Nov 2007, 17:17
That is getting pretty complicated, but if the applications goes "full screen" when the console is only small, then it will be a jumbled mess and they will think it's crazy.. THink about it, having a multi-window collection of text smashed into a tiny screen with a tiny message saying "Press Alt+Enter".. I guess I could just make a dialog box pop up when it initiates, that would solve all the problems. When I tried to call a dialog box from a console program, however, it failed. Any other ideas of how to inform the user to press Alt+enter without having it a jumbled mess? I guess you don't really need Alt+Enter, just hit the maximize button.. I think a dialog box before the process begins would be great, so the user terminates the dialog box, the process goes on it's way in less than a second, then the user would hit Alt+Enter.

About my question earlier, how different is 64-bit code from 32-bit? Links anyone? I know the basics, but is there any real difference except registers and addresses?
Post 25 Nov 2007, 17:17
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4121
Location: vpcmpistri
bitRAKE 25 Nov 2007, 18:13
The choice of full-screen is up to the user. Although I've forced it in some GUI apps it is an error in design and just a product of laziness. You can always include a shortcut to execute the program from and set it for full-screen, or state in the documentation to press Alt-Enter for full screen.

More info about 64-bit changes...
http://www.jorgon.freeserve.co.uk/GoasmHelp/64bits.htm
Post 25 Nov 2007, 18:13
View user's profile Send private message Visit poster's website Reply with quote
AlexP



Joined: 14 Nov 2007
Posts: 561
Location: Out the window. Yes, that one.
AlexP 25 Nov 2007, 18:42
Wow.. 64-bit asm is a lot different, programming good code is going to be quite a task in oncoming years.. Can't wait till the VN architecture is replaced by just a CPU with giant several gig caches. It would be a good idea, considering all program data would be easily accessed by the processor. Well, I think I'll design my stuff 32-bit for now, and rely on Windows to convert it for me. Thanks for help!
Post 25 Nov 2007, 18:42
View user's profile Send private message Visit poster's website Reply with quote
System86



Joined: 15 Aug 2007
Posts: 77
System86 04 Feb 2008, 01:33
Use GetConsoleDisplayMode to check if the console is a window or full-screen, and SetConsoleDisplayMode make the console full screen or a window.
Post 04 Feb 2008, 01:33
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.