Custom Query (6 matches)
Results (1 - 3 of 6)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #7 | invalid | Change the "Tray 1" name in default Tray Widget | ||
| Description |
Hello The "Tray" widget in XCenter came by default with a tray with the system icons called "Tray 1". I was wondering if we can rename that "Tray 1" and maybe call it "System" by default. Regards |
|||
| #6 | fixed | Consider UTF-8 for the WIS | ||
| Description |
An example where UTF-8 in the WIS would be useful is the Russian package, which currently uses CP866. Unfortunately, Ulrich's surname contains an umlaut, which is not present in CP866, resulting in the WarpIN database having an unrecognizable (and less than useful) Vendor name. This was discussed at some length in the ArcaOS Translators' list on or about 8/17/2021 in the thread, "XWP packaging for languages that do not use CP850." |
|||
| #5 | worksforme | WPS restart: reset SHELL semaphores for reliable operation of API "WinWaitForShell" | ||
| Description |
using XWP 1.0.13: there are three named event semaphores that are using by the "WinWaitForShell?" API function so that this function can block on (or being polled for) these 3 events: Desktop created, Desktop opened, Desktop populated. The named event semaphores are: \SEM32\WORKPLAC\SHELL1WT.SEM (for Desktop created) \SEM32\WORKPLAC\SHELL2WT.SEM (for Desktop opened) \SEM32\WORKPLAC\SHELL3WT.SEM (for Desktop populated) These 3 event semaphores are created by the 1. instance of PMSHELL.EXE but they are opened and set by the 2. instance of PMSHELL.EXE. The problem is, that on XWP function "WPS restart", the 2. instance is just terminating thread 1 (which leads to process termination) without resetting these event semaphores. If the WPS is then restarted and an application also starting up (or the WPS) is using "WinWaitForShell?" waiting for the desktop to be created/opened/populated respectively, the "WinWaitForShell?" API call will return immediately without blocking because the event semaphores are still set. This typically leads to hang problems and the like because the WPS is typically not in the state that the application/WPS class expects it to be after returning from "WinWaitForShell?". One indication of such might be WPS classes installed via WarpIn? and requiring a WPS restart to become active where the WPS restart will lead to a system hang. I propose to reset these 3 event semaphores shortly before the 2. instance of PMSHELL.EXE terminates its thread 1 (on a "WPS restart"). |
|||
