MameWah Technical Thread (for MinWah)

[headkaze]

This thread is really for MinWah, as a technical discussion about MameWah, namely the launching of shortcuts and programs.

I have had experience in this field, so I am hoping to give some (hopefully) helpful tips on making MameWah an even better front end. The motive is that I wish to use this as my front end for a cabinet I am currently building, so I would like some specific changes made to suit my needs. I hope this will help create a better front end for everyone. I have coding experience in both C and VB, but as C is my primary and preffered language I have converted alot of code over to VB to help make certain features a reality. I have also attached a VB example project that demonstrates how these features can be applied. So I hope MinWah reads this!

New features demonstrated and requested:
- Launching MameWah main window from Sub Main instead of a form. Creating an API window instead of using a form allows for better control. Also doing it this way means we can have access to functions like the AddressOf operator which is only available inside a module.
- Better launching of lnk's (shortcuts) using ShellExecuteEx so that command line parameters are processed properly.
- Better way of launching executables using CreateProcess. It's better than Shell() IMHO.
- These allow for more control over the application launched. It will allow us to set the process priority, send keys to the application upon launch, simulate a click on a menu, and change various ways the window's application is displayed like removing the border and menu bar, making it fullscreen or moving the cursor off the screen.
- This will also allow the program to force the launched application to the front of the screen. No more hiding windows.
- There is also provisions here to write to the process memory space. This could be used for cheats and the like.
- Currently MameWah removes the cursor by loading an invisible one. This can cause problems while running other applications, the cursor will dissapear and re-appear. The code I demonstrate will only hide the cursor in the MameWah main screen.
- Pressing + or - on the keypad will increase or decrease the global volume. Hopefully MinWah can adapt this to use the second joystick as volume control.
- I started writing an adaptation using a DLL to hook all windows messages of the launched application. This would allow one to set up, for example, the ESC key to exit any application. Unfortunately I couldn't get it to work in VB. Perhaps I will work on this more if MinWah is interested.

I think that covers just about everything in the demo.

When you launch the demo app, keys 1 to 4 on the main keyboard will show demonstrations of launching notepad.exe and shortcuts to notepad.exe and explorer.exe. Pressing the + and - keys on the keypad will turn the global volume up and down. This application is meant for MinWah and him only, there is no point in other people downloading this (except if you are a programmer or just plain interested in this crap).

Thanks for your time, and I hope MinWah will reply and comment on the demo.

VBLaunch.zip

[Minwah]

Thanks for the suggestions.  I haven't looked at your app yet so bear with me...these are my initial thoughts:

- Launching MameWah main window from Sub Main instead of a form. Creating an API window instead of using a form allows for better control. Also doing it this way means we can have access to functions like the AddressOf operator which is only available inside a module.

I use a Sub Main but I am not sure about using API Windows.  Could you explain more please, such as what AddressOf is used for?

- Better launching of lnk's (shortcuts) using ShellExecuteEx so that command line parameters are processed properly.

I looked into this a while back when I started working on the current betas.  The problem is that ShellExecute will not wait for the shelled app to finish - this is crucial in a FE (I mentioned this in another thread yesterday).  I couldn't find a way to ShellExecute & Wait so I opted for sticking with the current launching method.  If you know how to do this then I can substitute something in.

- Better way of launching executables using CreateProcess. It's better than Shell() IMHO.

I already use CreateProcess (always have).  I recently added Shell as an alternative only if the {nowait} flag is used.

- These allow for more control over the application launched. It will allow us to set the process priority, send keys to the application upon launch, simulate a click on a menu, and change various ways the window's application is displayed like removing the border and menu bar, making it fullscreen or moving the cursor off the screen.

I haven't really played about with this much - I'd be interested in some of this though.  In theory you can already launch something maximised ({max} flag) or minimised ({min} flag) but it depends somewhat on the application.  The other stuff I don't know much about, although I did attempt to send keys to the application before, but didn't have a lot of joy.

- This will also allow the program to force the launched application to the front of the screen. No more hiding windows.

This should already happen really.  The hiding of Windows is done 'just to be sure'.  In Windows it is almost impossible IMO to prevent every single thing like the occasional desktop popup - hiding Windows is a good failsafe.

- There is also provisions here to write to the process memory space. This could be used for cheats and the like.

This is probably beyond me to be honest.

- Currently MameWah removes the cursor by loading an invisible one. This can cause problems while running other applications, the cursor will dissapear and re-appear. The code I demonstrate will only hide the cursor in the MameWah main screen.

Actually this is the exact opposite of what happens.  I used to just hide the cursor in Mamewah but it caused the exact problem you described - the cursor would pop up when launching emulators etc.  Hiding the cursor completely by swapping it for an invisible one means you never ever see it - seems strange if you do see the cursor, it shouldn't be possible.

- Pressing + or - on the keypad will increase or decrease the global volume. Hopefully MinWah can adapt this to use the second joystick as volume control.

I was intending to add a volume control (JCrouse has been on at me about it for ages!).  The Player 2 joystick is used for navigation tho, so I would probably add a menu option by default - you can always use the ctrlr feature to remap.

- I started writing an adaptation using a DLL to hook all windows messages of the launched application. This would allow one to set up, for example, the ESC key to exit any application. Unfortunately I couldn't get it to work in VB. Perhaps I will work on this more if MinWah is interested.

Sounds good...I did some reading into hooks but never really got very far.  I'm not sure what the limitations of VB are in this respect.

I think that covers just about everything in the demo.

Just about to try it...

[headkaze]

I use a Sub Main but I am not sure about using API Windows.  Could you explain more please, such as what AddressOf is used for?

Ok nice to know your using this method. Using an API Window is demo'ed in the example app. The AddressOf operator is used to enumerate the windows so you can get a handle to the window. With a handle you can do alot more with the opened application.

I looked into this a while back when I started working on the current betas.  The problem is that ShellExecute will not wait for the shelled app to finish - this is crucial in a FE (I mentioned this in another thread yesterday).  I couldn't find a way to ShellExecute & Wait so I opted for sticking with the current launching method.  If you know how to do this then I can substitute something in.

Again in the example you can see how you can wait properly for the application to finish. It's generally required to specify a "titlebar" string to find the right window. But ShellExecuteEx, as you say, dosn't return a handle to the process, so I use a trick to get it (only works with .exe's so pretty useless) or just search for the titlebar.

This should already happen really.  The hiding of Windows is done 'just to be sure'.  In Windows it is almost impossible IMO to prevent every single thing like the occasional desktop popup - hiding Windows is a good failsafe.

Oops I meant "hiding a window", not hiding Windows. I just mean the code for bringing a window to front zorder and foreground.

This is probably beyond me to be honest.

Well, there is code to do exactly that, but finding the memory locations etc. will be up to other enthusiastic hackers

Actually this is the exact opposite of what happens.  I used to just hide the cursor in Mamewah but it caused the exact problem you described - the cursor would pop up when launching emulators etc.  Hiding the cursor completely by swapping it for an invisible one means you never ever see it - seems strange if you do see the cursor, it shouldn't be possible.

I've personally had a few problems with it.. my suggestion is to force the cursor to the bottom right corner of the screen, that way you can still use it if need be

I was intending to add a volume control (JCrouse has been on at me about it for ages!).  The Player 2 joystick is used for navigation tho, so I would probably add a menu option by default - you can always use the ctrlr feature to remap.

hehe yes I believe it's an important inclusion since we don't want to wake up the neighbours in crazy hours of the morn' right? Well it just seemed like a cool thing to add IMHO

Sounds good...I did some reading into hooks but never really got very far.  I'm not sure what the limitations of VB are in this respect.

Yeah the DLL hook is quite possible, I have working code in C, in fact the DLL is written in C and VB loads the DLL using the LoadLibrary API function. Problem is, I couldn't get it to work in VB (yet). It will be nice to add the ability to quit anything with a key specified by the user.

Just about to try it...

C00l

[Minwah]

Ok nice to know your using this method. Using an API Window is demo'ed in the example app. The AddressOf operator is used to enumerate the windows so you can get a handle to the window. With a handle you can do alot more with the opened application.

The API Window looks like it works pretty well.  However is there any practical advantage over the current method I use?

Again in the example you can see how you can wait properly for the application to finish. It's generally required to specify a "titlebar" string to find the right window. But ShellExecuteEx, as you say, dosn't return a handle to the process, so I use a trick to get it (only works with .exe's so pretty useless) or just search for the titlebar.

In your example the problem is present where the program continues after launching the shortcut target (rather than waiting for it to finish).  Are you saying the program shouldn't do this, or that it could be modified to fix this?

I've personally had a few problems with it.. my suggestion is to force the cursor to the bottom right corner of the screen, that way you can still use it if need be

What problems have you had (& on what OS)?  Since the cursor is changed on a system level you should never see it, unless the cursor is something other than 'arrow'. 'hourglass' or 'arrow+hourglass'.  Moving the cursor is no good as some apps move it back to the centre of the screen.  I'm pretty confident my current method is best, having spent a lot of time trying different things.

hehe yes I believe it's an important inclusion since we don't want to wake up the neighbours in crazy hours of the morn' right? Well it just seemed like a cool thing to add IMHO

Well a lot of people use a volume knob but a good few people have requested this too.  Would you mind if I pinch your code?  If not I'll add it for the next beta.

Yeah the DLL hook is quite possible, I have working code in C, in fact the DLL is written in C and VB loads the DLL using the LoadLibrary API function. Problem is, I couldn't get it to work in VB (yet). It will be nice to add the ability to quit anything with a key specified by the user.

That would be pretty cool


Just a point about the sending of keys...it doesn't seem to work for MAME at least - I suspect it only works with 'Windozy' apps, similarly to how the VB built-in SendKeys function works.  Alternatively I could be wrong and it might have been a timing issue, I'll have to do a bit more testing.

[headkaze]

The API Window looks like it works pretty well.  However is there any practical advantage over the current method I use?

I think so, but without looking at your current code I can't say what the differences are exactly. If you use Sub Main then I wonder how you create your window.. are you using a form? If you are, I am totally convinced that my method is better. Without experience in C it's hard to explain the advantages other than saying it's more API friendlier. The point is my application is meant to work like a normal C program would but using VB. I know the advantages of using VB too since I've programed for a a few years, but C is the way to go. I'm not about to write my own C front end though because I don't have the time, yours is (almost) perfect for my needs anyways. Hope you eventually see my reasons for the way I do things.

In your example the problem is present where the program continues after launching the shortcut target (rather than waiting for it to finish).  Are you saying the program shouldn't do this, or that it could be modified to fix this?

Your saying that my application continues after launching the shortcut? Of course it does, so does MameWah. Are you using WaitForSingleObject(hProcess, INFINITE)? Otherwise how do you wait in the background for the process launched to end? Mine does the same except it waits a while, processes the message system, checks if the process has ended and loops. Its basically the same, and designed to take very little processor time.

What problems have you had (& on what OS)?  Since the cursor is changed on a system level you should never see it, unless the cursor is something other than 'arrow'. 'hourglass' or 'arrow+hourglass'.  Moving the cursor is no good as some apps move it back to the centre of the screen.  I'm pretty confident my current method is best, having spent a lot of time trying different things.

Well, I think your method should definately not be removed, rather, my method added as an option. Removing the cursor is ok for some apps, moving the cursor would be a better option for some apps I believe. In that case the cursor is still available just out of view (if you grab control of the mouse or trackball, there you go the cursor is there.

Well a lot of people use a volume knob but a good few people have requested this too.  Would you mind if I pinch your code?  If not I'll add it for the next beta.

Of course you can use the code.. well the volume code isn't mine, but do you see a copyright notice/terms of use on it? No, neither do I, meaning its freely distributable. The code in mMain.bas is practically all mine. Well, we would be liers saying we didn't get help from code off the net wouldn't we? All the same, I do respect a copyright/terms of use when I see one.

That would be pretty cool


Just a point about the sending of keys...it doesn't seem to work for MAME at least - I suspect it only works with 'Windozy' apps, similarly to how the VB built-in SendKeys function works.  Alternatively I could be wrong and it might have been a timing issue, I'll have to do a bit more testing.

Well, Mame is a command line application, therefore how do you get the handle to the window? You can't. But I havn't looked at this specifically, perhaps the command prompt window can be accessed and the keys send to that. You know what I'm thinking arn't you? "remove that damn warning message to type ok or move the joystick" hehe, its possible I believe.

Thanks for checking out my ideas, I hope they may help in some way.

Keep in touch, I think we can work together on some of this

[Minwah]

I think so, but without looking at your current code I can't say what the differences are exactly. If you use Sub Main then I wonder how you create your window.. are you using a form? If you are, I am totally convinced that my method is better. Without experience in C it's hard to explain the advantages other than saying it's more API friendlier. The point is my application is meant to work like a normal C program would but using VB. I know the advantages of using VB too since I've programed for a a few years, but C is the way to go. I'm not about to write my own C front end though because I don't have the time, yours is (almost) perfect for my needs anyways. Hope you eventually see my reasons for the way I do things.

Yes I am just using Sub Main to show a form.  I'm sure you method has it's advantages but since I don't have any real problems I'll leave it for now.  In any case I plan to use DirectDraw eventually which probably means I'll be doing some re-writing in this area anyhow.

Your saying that my application continues after launching the shortcut? Of course it does, so does MameWah. Are you using WaitForSingleObject(hProcess, INFINITE)? Otherwise how do you wait in the background for the process launched to end? Mine does the same except it waits a while, processes the message system, checks if the process has ended and loops. Its basically the same, and designed to take very little processor time.

Mamewah doesn't launch shortcuts directly, for this reason.  When launching .exe's yes I use WaitForSingleObject IIRC.  In your example after launching a shortcut execution continues immediately - this is the point I am making, I want to avoid this which is why I don't launch shortcuts, rather determine the target .exe and launch that.  For the most part, this is suffiient anyway except for a few cases (one of the other threads here highlights a good example of this).

Well, I think your method should definately not be removed, rather, my method added as an option. Removing the cursor is ok for some apps, moving the cursor would be a better option for some apps I believe. In that case the cursor is still available just out of view (if you grab control of the mouse or trackball, there you go the cursor is there.

Using the {cursor filename} flag you can specify a cursor to use should the app being launched require one, so you already have the best of both worlds.

Of course you can use the code..

Cool, just saves me sourcing it from elsewhere...and yes we all pinch a bit of code, no point re-inventing the wheel afterall

Well, Mame is a command line application, therefore how do you get the handle to the window? You can't. But I havn't looked at this specifically, perhaps the command prompt window can be accessed and the keys send to that. You know what I'm thinking arn't you? "remove that damn warning message to type ok or move the joystick" hehe, its possible I believe.

Yeah I tried for a long time to achieve this (got the idea from ArcadeOS) but was never able to do it...I came to the conclusion it must be pretty hard!  I'll be very impressed if you can figure it out!

Thanks for checking out my ideas, I hope they may help in some way.

Keep in touch, I think we can work together on some of this

Sure, thanks for your interest.  BTW sorry if you feel I have shunned any of your ideas...it's just that I spent a lot of time on it over the years and the launch stuff in particular I am quite reluctant to change since it works just about perfectly already imo.  Why fix what's not broken I suppose is my thinking...

[headkaze]

Sure, thanks for your interest.  BTW sorry if you feel I have shunned any of your ideas...it's just that I spent a lot of time on it over the years and the launch stuff in particular I am quite reluctant to change since it works just about perfectly already imo.  Why fix what's not broken I suppose is my thinking...

np, well I guess I am a little dissapointed, but the thing is, if MameWah works the way I want, I'll be happy. Perhaps B8 does this, but mainly it's important that I can launch lnk's with full command line arguments. That way I can launch PC exe's, chankast using Chankast Launch etc. Plus I intend on writing mini apps for other stuff that requires specific stuff.  This means command line parameters are a must, through shortcuts (hopefully). Expect a Mame Launcher from me soon that will send the ok etc.  so if B8 can launch shortcuts with parameters I'll be happy.

I guess you can consider my code example for some later releases. The thing is, I was thinking it would be nice to put the code into the front end instead of launching wrapper apps. Hell, MameWah could do it all really.. send the keys, force the full screen, etc. Well it was a dream I guess

[headkaze]

Mamewah doesn't launch shortcuts directly, for this reason.  When launching .exe's yes I use WaitForSingleObject IIRC.  In your example after launching a shortcut execution continues immediately - this is the point I am making, I want to avoid this which is why I don't launch shortcuts, rather determine the target .exe and launch that.  For the most part, this is suffiient anyway except for a few cases (one of the other threads here highlights a good example of this).

In my code I use WaitForSingleObject also, but I just process messages as well (I would say a better and safer way of running an app in the background). It's standard stuff in C programming, so there is no problem. You say "after launching a shortcut execution continues immediately", well it always will, whether you wait for it to exit or not. There is always processessing going on in MameWah until it exits, my loop is practically equal to waiting INFINITE, execpt it processes messages, like DoEvents, thats normal coding in C. Coding in C is always the "right way to code".

Yeah I tried for a long time to achieve this (got the idea from ArcadeOS) but was never able to do it...I came to the conclusion it must be pretty hard!  I'll be very impressed if you can figure it out!

Well if ArcadeOS can do it, so can we! For a start we can use an API Viewer to view what this program does exactly. The question is, where does it send the keys to? Well, obviously without a window we must send to the command prompt window (thats a guess).

[Minwah]

In my code I use WaitForSingleObject also, but I just process messages as well (I would say a better and safer way of running an app in the background). It's standard stuff in C programming, so there is no problem. You say "after launching a shortcut execution continues immediately", well it always will, whether you wait for it to exit or not. There is always processessing going on in MameWah until it exits, my loop is practically equal to waiting INFINITE, execpt it processes messages, like DoEvents, thats normal coding in C. Coding in C is always the "right way to code".

In simplest terms, what I'm getting at is that if you add another line of code after 'StartProcess'/'StartShortcut' to say display a messagebox...for Method '1' the message box will not appear until you close notepad.  For Method '2' the messagebox appears before you close notepad.

From what you say I'm sure there is a way around it.  FWIW Mamewah processes messages too, I added this in order to deal with powering the pc down while emulators/apps are running.

Well if ArcadeOS can do it, so can we! For a start we can use an API Viewer to view what this program does exactly. The question is, where does it send the keys to? Well, obviously without a window we must send to the command prompt window (thats a guess).

ArcadeOS is a dos program though, and probably does it at a lower level than is possible with Windows (I guess).

[headkaze]

In simplest terms, what I'm getting at is that if you add another line of code after 'StartProcess'/'StartShortcut' to say display a messagebox...for Method '1' the message box will not appear until you close notepad.  For Method '2' the messagebox appears before you close notepad.

Thats strange, they always appear first for me. But anyways, the messagebox isn't supposed to be there anyway, its just to explain whats happening. The messagebox's are always causing wierd and wonderful effects... thats why in a production release they would be removed.

ArcadeOS is a dos program though, and probably does it at a lower level than is possible with Windows (I guess).

If they can do it in DOS we can do it in windows Both can work on the same level, just that Windows now restricts access per user access level. So no problem, if they can do it so can we

[Minwah]

Thats strange, they always appear first for me. But anyways, the messagebox isn't supposed to be there anyway, its just to explain whats happening. The messagebox's are always causing wierd and wonderful effects... thats why in a production release they would be removed.

Sorry, what I meant is say for example if you *added* a msgbox just after the Start__ part.  StartProcess waits until the shelled app has been terminated, then would display the msgbox.  With StartShortcut it launches the shortcut and the msgbox is displayed immediately after (ie before the launched app is terminated).

I think what you said earlier means that to fix this one would add a further step to determine the app/process launched by the shortcut, and then wait for this process to finish.

If they can do it in DOS we can do it in windows Both can work on the same level, just that Windows now restricts access per user access level. So no problem, if they can do it so can we

True, but I admire your confidence! 

[headkaze]

Sorry, what I meant is say for example if you *added* a msgbox just after the Start__ part.  StartProcess waits until the shelled app has been terminated, then would display the msgbox.  With StartShortcut it launches the shortcut and the msgbox is displayed immediately after (ie before the launched app is terminated).

I think what you said earlier means that to fix this one would add a further step to determine the app/process launched by the shortcut, and then wait for this process to finish.

Ahh I get what your saying. In example 2 I demonstrate launching a shortcut without a titlebar. It's impossible to get the process or window handle. The only way to do that is searching out the titlebar using FindWindow(). So in example 3 and 4 I demonstrate using LaunchShortcut() but give it the titlebar of notepad.exe and iexplore.exe so it does get a handle to the process and window, thats how it makes notepad's window in example 3 go fullscreen with no border and menu. In example 2, LaunchShortcut() can't wait for the process to end, so it exits back to the main window process WindowProc() and continues processing messages.

[Minwah]

Ahh I get what your saying. In example 2 I demonstrate launching a shortcut without a titlebar. It's impossible to get the process or window handle. The only way to do that is searching out the titlebar using FindWindow(). So in example 3 and 4 I demonstrate using LaunchShortcut() but give it the titlebar of notepad.exe and iexplore.exe so it does get a handle to the process and window, thats how it makes notepad's window in example 3 go fullscreen with no border and menu. In example 2, LaunchShortcut() can't wait for the process to end, so it exits back to the main window process WindowProc() and continues processing messages.

Thanks, that makes perfect sense.  So if you don't know the titlebar string is it impossible to find the window?  Just that in your example you obviously know the titlebar for Notepad & Internet Explorer, but in my FE it could be any program so this will always be different.

[swindus]

Its possible to iterate thru all windows and get the process id of them with api functions. Then match the process ids of all windows with the id you get when you start an application with CreateProcess. So you can find the window without knowing the titlebar caption.

[headkaze]

Thanks, that makes perfect sense.

[Minwah]

With the StartProcess() function using CreateProcess() API (which returns a handle to the process),  I then use enumeration of all windows and use GetWindowThreadProcessId() API function for checking which one matches the hprocess. So that way is pretty much automatic. That will work fine for most .exe's and most emulators.

This is pretty much what Mamewah does currently, for launching exe's.

With the StartShortcut() function using ShellExecuteEx is quite different. I'm pretty sure it's not possible to launch a .lnk and get the handle without using FindWindow. LaunchShortcut("notepad.exe"...) will work using a "trick", but not shortcuts. I was thinking the window title could be placed in the ini files by the user manually. I think it's the only way (for .lnk's at least). Since in general one ini file is for one emulator, the titlebar will remain the same. If the title bar changes for each game eg. "Chankast - Game1", "Chankast - Game 2" etc.

Thing is there is never really any need to use a shortcut for emulators, exe's do just fine.  The only reason to use shortcuts is for PC apps/games, which will obviously all have different titles.

I can modify the code to search out just "Chankast" instead of a full string using enumeration. The current example uses FindWindow() which only works with an exact match of the window title. StartShorcut() will only be needed for the apps that need to launch from a lnk (for example Chankast Launch works well launched from a shortcut with command line parameters)

The thing is the titlebar can say anything, not neccessarily including anything useful like the exename.  So for this reason the above isn't really a 100% reliable method, is it?

[headkaze]

The thing is the titlebar can say anything, not neccessarily including anything useful like the exename.

[Minwah]

I found a reasonable solution to launching a shortcut and getting it's window handle. Basically I read in the shortcut's target and then use that to launch it as usual.

This is what I already do.  The problem is that the target does not include any additional switches or whatever, which is why you need to add them into the _commandline parameter.