Hello,
I've written a small program that puts up a GUI console like windows DOS box. It does look a bit nicer though because it isn't a console application. Clunky monitors had phosphor coating inside the tube, so I called it Phos :U
I thought people could use it if they just needed a text interface, but wanted something nicer than a console app.
Use the software by adding code to procedure phos_thread, which is run in a separate thread each time a prompt line is submitted by hitting return.
A bitmap font is included, the linked exe is only 11k. It's freeware and anyone can do what they like with it - download from http://ok-schalter.typepad.com/phos-win32-standalone.zip.
welcome to the board, and nice job :U project looks good, and the source is clean and commented.
Thanks E^cube! I'm trying to factor the whole GUI part out into a DLL for using it from other languages, too. So I've transformed the asm file into DLL format by adding a DLL entry proc and making the entry code into a callable procedure. It works in the sense that the DLL builds and I can call the exported procedure from "test.asm".
The procedure naively just calls WinMain. Test.asm does create a working window, but the message loop doesn't run. I suppose test.asm already has it's own message loop and it's non-trivial to "merge" it with the one from the DLL... I'll post a DLL version as soon as I understand this message loop business better :8)
If anyone is interested, I've made phos into a DLL (source + test files attached)...
[attachment deleted by admin]
Hi Michael,
Welcome to the forum.
Nice work :U
welcome to the forum, Michael
it looks very cool - i really like the character cell shading
a nice addition would it be able to pipe cmds to cmd.exe/command.exe and display results, I might write it for it, this really is a neat simple project, looks great. Icezlion has example pipn code
Slugsnack has been playing wth piping, as well (in both directions)
he may also be interested in the console window
it sounds like the two of you together could be close to replacing the windows dos-box, which has several bugs
Thanks everyone for your comments :thumbu
I will do more work on it, but I just got tied in with my day job until next week :eek. @E^cube, brilliant idea to rework phos to behave more like cmd.exe!
Perhaps I overestimate what cmd.exe is doing besides putting up a line editor - I will look at Iczelions pipn example code... I guess it would need to use windows fonts, resizing logic etc.
Besides documentation (there is none so far), up on my list is a very simple lexical scanner and making phos work together with an sqlite db (sqlite is cool; no bloat, public domain, just a tiny dll and one DB file) in which I store lexer tokens. I've so far extended the DLL version to attach to sqlite3.dll using the ProcAddress method and execute queries, works fine. This would make it still easier to use phos for text interface. My logic is that if you're using a command line, you will need to recognize words, too, so the command line component should simplify that. I would also like to work on cleaning up and deciding on a nicer export interface. I guess what I have in mind is make Phos into a very small, semi-cool console with a small built-in command language (instead of a menu bar ;-)
p.s. please don't pull from github as I said in my first post - my repository is broken somehow and I will just post any code here - I can't get git to upload to github under windows for some reason, so I just use it locally.
here's my code for a working pipe for both directions for cmd.exe. it's not what you'd call 'good code' right now since that is more a proof of concept snippet for a larger project for myself.
9dt.zwit.org
what i mean by good practice is all functions should be as independent on each other as possible. right now a lot is happening via global variables and there is a lot of dependency on them. ideally each function would work regardless of the other. how i did that in my larger project was defined my own structure that had a bunch of variables associated with it :
PIPE_WINDOW_INFORMATION STRUCT
dwID DWORD ?
hwnd DWORD ?
IDC_EDT DWORD ?
IDD DWORD ?
IDC_BTN DWORD ?
lpszInitButton DWORD ?
lpszDeactButton DWORD ?
hEdt DWORD ?
lpszExpandedCommandLine DWORD ?
dwCurrentPipeState DWORD ?
hProcess DWORD ?
PIPE_WINDOW_INFORMATION ENDS
for that project the read/write pipes are actually created as local variables which is why they aren't in there, for the rest of it it works very very similarly to how an OOP program would handle the solution i'm trying to create
The 9dt.zwit.org pipe code is very cool :dance: I hadn't thought that piping through cmd.exe was as clean as that...
I'm puzzled about the actual console window (the black default window when cmd.exe is run) and where it comes from. How does a console app get its ugly window :bg
QuoteClunky monitors had phosphor coating inside the tube, so I called it Phos
must be ms wanted a clunky console to match - lol
i kind of liked the green p7 phospher, so long as you didn't have to look at it for too long - lol
unless i am mistaken the window comes from cmd.exe
it wouldn't be too bad, if it wasn't so buggish
especially the copy/paste debockle
with this window, you could make a nice, well-behaved console, i think
I love this. Please make it possible to host the windows shell inside your console window. I would so use this over cmd.exe if it could host the windows shell.
::)
I've got it to do vertical resizing to get more/less lines.
The only thing that bothers me is that if you pull up/push down the top border of the window, it's sort of wobbly.
Will try to sort this out next...
Horizontal resizing will be tougher - growing the window is noob, but making the lines smaller will need to
break them into several lines :red not sure I'm to the challenge...
i dragged the bottom down to resize - crash
exception error 0xc0000095 - integer overflow
Thanks for letting me know! - I will check on another machine to sort it out. I'm on (32-bit) XP and
it doesn't do that...
32-bit XP Pro MCE2005 sp2
P4 prescott dual core
screen resolution setting: 1280 x 1024
I've fixed it - there were actually two errors...
The integer exception thingy hopefully was a missing "mov edx, 0" before the (only) div opcode in the source.
The main error was that my WM_SIZING handler called GetWindowRectangle.
But the window size is actually only changed during sizing, when the following windows option is enabled:
"Show window contents while dragging" - right click on desktop, choose properties, appearance, effects.
If that option is disabled, GetWindowRectangle always returns the same value during WM_SIZING, and
that's why my code didn't work. I now track the previous sizing rectangle in a RECT structure instead of calling
GetWindowRectangle to get it.
What I haven't found a fix for is the "wobbling" when the top border of the window is dragged, rather
than the bottom (only occurs when "Show window contents while dragging" is enabled) ...
not so fast
still get the same integer overflow
i don't think that error is caused by division
if it were, it would be "divide overflow error"
:eek oops, the version I posted was missing the "mov edx, 0" line.
I really think it's that because I've run the exe in OllyDbg, and the DIV caused the exception.
Bizarre exception, when dividing by very large/small integers I think.
Sorry I posted trash earlier - I've modified the attached file of my previous post with the fixed
version. I'm posting now mainly in case anyone has
an idea regarding the "wobble" :P
overflow error gone
i am trying to see the wobble - lol
ohhhhhhhhhhhhhh
that - lol
i think i would ignore that
all windows do the same thing
Thanks for testing the error :U
I would have thought they all do it, too... the silly thing is my first prototype
didn't do it - you could push down the top border and the bottom stayed smooth
as baby skin.
I just can't see when/how I botched it.... Will post once I got it...
That is awesome! :thumbu
I too see the "wobble" when resizing the window. I get it on other windows, too.
EDIT: Would help if I stated the OS! Win XP Pro SP3. Screen res: 1600x1200.
Best regards,
Astro.
It's the WS_EX_LAYERED style for translucent windows.
Once I took it off, top border resizing is smooth...
i never cared for the translucent thing
i mean, it was cool to see a couple times, then you find out it is slow and, when in that mode, hard to see what you want
i went to great lengths to make my machine run fast
when i open something i want it to - BANG - pop up on the screen
and when i close it - BANG - disappear
Right on! :U
I will take WM_EX_LAYERED out of it. I sort of liked it, but it would have been cooler if only the client area was translucent.
Always wondered what the reasoning was to make the caption bar / window frame see-through?
Now I've removed LAYERED, I need to work on WM_PAINT, the layered style covered up some inaccuracy
in the handler for that method...
In my debugging efforts :boohoo: I've replaced the WM_PAINT handler by a trivial version, that just blits a bitmap
square onto the client DC, figuring that should update the client region irrespective
of the actual paint rectangle, to see if the bare essentials work.
But it doesn't, there are occasional white stripes when I cover/uncover the window
with another, as if occasionally I were skipping a WM_PAINT message...
I found a posting where someone using the win32 api in C is having a similar problem:
http://www.codeguru.com/forum/showthread.php?t=283638
Is it not OK to paint the client region of the main window directly for some reason, instead of
painting on a child window client region? :red
I followed the external posting I mentioned and did the same thing as the other person,
namely invaliding the client region on entering WM_PAINT.
That works nicely and at least to me, it's just as quick as before.
So I'm posting this clean version of phos featuring vertical resizing here for completeness.
Hi
Works well for me, keep p the good work
Cheers
John
Many thanks, John!
I've cleaned it up some more and added code to the user thread function to show how
the command line can actually be used/processed quite easily.
I've replaced the file attachment to my previous posting with the updated file.
To not bore everyone with insignificant updates, the following links will always point to the
most recent versions.
Standalone version: http://ok-schalter.typepad.com/phos-win32-standalone.zip
DLL + test app version: http://ok-schalter.typepad.com/phos-win32-dll.zip
:bg
Quote
i went to great lengths to make my machine run fast when i open something i want it to - BANG - pop up on the screen and when i close it - BANG - disappear
Must be tarred with the same brush, I use win2k with all of the junk turned off and every tweak I can find to make the interface faster. If the app is only instantaneous its not fast enough, it has to finish by the time the ENTER key hits bottom. :P
Just to see if the DLL interface was viable, I've written a c demo app that interfaces phos.dll.
(The MASM32 source of the DLL has also been updated.)
The DLL could be nice for c/asm programmers who wish to avoid the Win32 API altogether but
still require a visually pleasing GUI interface. ::)
C sample application (LCC-Win32) using phos.dll: http://ok-schalter.typepad.com/files/phos_c.zip
DLL + test app source (MASM32): http://ok-schalter.typepad.com/phos-win32-dll.zip
Michael,
Your links are dead, perhaps you could make the downloads available thru the forum.
Thanks much.
...... Ed
Shame on me - most recent version attached : -)
very cool, Michael :U
no crash when i resize (vertically)
i suppose if you wanted to resize horizontally, you'd have to handle line-wrap, which is context-dependant
this thing is slicker than hot snot on a glass doorknob :bg
now, we just need to get ms to re-write cmd.exe - lol
Wow .... that was fast. It will take me a few days to to look at this (perhaps). Thank you very much Michael !
... Ed