On Sat, 5 Sep 2020 13:52:38 -0400 Lewis wrote:
>
>Hi, Gregg...
>
>On 09/04/20 10:53 pm, Gregg Young wrote:
>>On Fri, 4 Sep 2020 17:19:39 -0400 Lewis wrote:
>>>I've just made some interesting rediscoveries:
>>>
>>>While my comments in the help section regarding DOS sessions are
>>>mostly
>>>correct, the behavior we currently have and what is possible to change
>>>is not.
>>>
>>>All VDMs run at some delta between 0 and 31 in priority class
>>>PRTYC_REGULAR (Class 2). The VDM handler apparently maps the DOS
>>>Setting
>>>"SESSION_PRIORITY" values 1 to 32 to priority deltas 0 to 31.
>>>
>>>This is essentially what I put into the help text. However, what is
>>>not
>>>clear (or stated incorrectly, based upon program observation) is that
>>>SESSION_PRIORITY (i.e., delta) *cannot* be changed for running VDMs,
>>>and neither (as stated in the help) can the class be changed. IOW, All
>>>VDMs run in class 2. SESSION_PRIORITY is settable in program
>>>properties
>>>*before* starting the session, and fixed at that level (delta) once
>>>started. There is no way to adjust these DOS session settings once
>>>running.
>>Thanks for the info. If the fact that something is a VDM is available
>>when the menu is being generated this would be an easy fix. If not
>>probably not worth doing. I don't know if it is available but I will
>>check.
>
>I don't know if it is available, either. WatchCat doesn't treat these
>entries any differently, and like lSwitcher, allows the user to jockey
>priority and delta just like for other OS/2 processes, but selecting a
>different process and then switching back to the VDM in question shows
>everything as it was before making any changes. Whether these are listed
>similarly in WatchCat as the result of an oversight or because there is
>no way to identify them other than "VDM" I have no idea.
I am reasonably sure there is a way to determine this and I may have the program type available during menu creation. If I don't I don't see it as a big enough issue to be worth figuring out how to get it.
I haven't looked because your earlier issue about the language list not showing RU and CZ correctly grabbed my interest. I now have them all showing correctly along with the dialogues all rendering correctly for all languages on my codepage 850 system. Now if I could only get the menus working.
>
>>>Polling options can be changed for running VDMs, however (IDLE_SECONDS
>>>and IDLE_SENSITIVITY), but lSwitcher provides no dialog for doing
>>>this.
>>>
>>>So, what is needed is an RFE for lSwitcher to remove the Priority menu
>>>selection for VDMs as it is simply irrelevant and misleading and to
>>>adjust the help as necessary. (Likewise, XWP help should be updated to
>>>include this tidbit pertaining to DOS sessions, but that's a different
>>>discussion for a different project.)
>>This would require you making a case for this being needed by ArcaOS
>>for something (retro gaming?) and I would then expect lSwitcher to at
>>minimum be an install option for ArcaOS.
>
>This would have to be paired with a second RFE to create an object in
>the lSwitcher folder to toggle between standalone and widget. The only
>alternative becomes too cumbersome (creating software selection entries
>for lSwitcher and an optional Standalone sub-item, and all that that
>entails on the backend for doing the install).
>
>I would love to see lSwitcher made available as an install-time software
>selection, but we would need the above to do it effectively.
The reason I said option because I am aware of this issue.
Maybe some REXX to call wic.exe:
Have warpin uninstall the taskbar package then install the widget and restart the desktop. Do the reverse for the other direction. This of course means we need to always have access to the wpi.
The other alternative I see is installing if they select the widget don't create the taskbar object and rename lswitch.exe to lswitch.ex. They will still need to manually create the widget. There is probably a way to remove the window list and completely install it but I have no idea how that would work. If they want the taskbar rename lswidget.dll lswidget.dl Probably need to restart the desktop to assert it never got loaded.
Then have some REXX that reverses these changes if someone wants to switch. A desktop restart would be required. As would manual installation of the widget for it to be used. We could install them both crippled and have two additional packages which install the REXX scripts for changing and run one of them based on which package they used to install them (ie Activate Widget).
The last issue is if they switch to the Taskbar what to do with the window list?
There might be a way I can determine if the widget is actually in use verses just in the xcenter folder. If this is possible it should be possible to allow the taskbar to run. However gracefully handling someone trying to create the widget with the taskbar running might not be possible.
>
>>>Comments and discussion welcome for all of this absurdity.
>>:-) Thanks
>>
>
>I know, it's silly to be hashing out these little nonsense items for the
>few of us using DOS sessions. That said, as you point out, if we are to
>get into the weeds for DOS games and such, it seems reasonable to expect
>that we'll handle DOS sessions with some degree of seriousness.
You are going to a lot of trouble to get the screen and audio working. Thanks
back to list