Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rich Walsh

Pages: 1 ... 4 5 [6] 7 8 ... 23
76
Programming / Re: OPenchat
« on: November 14, 2023, 11:38:14 pm »
The attached is DSPRES recompiled with all the new fonts removed. This should make it functionally the same as what was included in 5.0.

That works - thank you.

If it were possible to offload the new sizes to a '\psfonts\sysvio.fon', that would be best. But, if that's not possible, more users would be better served by having those larger sizes available than not - particularly when there's now a viable workaround.

77
Programming / Re: OPenchat
« on: November 14, 2023, 08:56:36 pm »
There were some updates made to DSPRES.DLL in 5.1, yes.

I did a lot of testing on this and have come to believe that the problem arises from a "design flaw" in OpenChat.

Once I switched to the DSPRES from 5.0.x, I was able to open it and discovered that it only uses System VIO fonts for its display. In 5.0.x, there are 17 sizes available; in 5.1.x, there are now 20. It _appears_ that any DSPRES version with more than the original 17 cause the crash.

This is likely due to bad programming. My guess is that when the app asks for a list of VIO fonts, it only allocates enough buffer space for the 17 sizes known to be available when it was written. When it gets 20 entries, the buffer overflows and causes who-knows-what kind of damage.

I tried to confirm this by removing the new fonts, but because I don't know how to edit the "font directory" resource that identifies each font, the system locked up when I tried to start the app. Interestingly, when I looked at the available VIO fonts in EPM, it handled my defective DLL gracefully and displayed a font sample at a smaller size (and didn't lock up the system). Alex, if you could reconstruct the dll correctly, we can confirm/refute my conclusion.

FWIW... rolling DSPRES.DLL back to the 5.0.x version has no effect on XWP's new 'TextSize' feature (which is why I pursued this in the first place). All the fonts it needs are contained in 'syspro.fon' and 'warpsans.fon', both in \PSFONTS. However, you will lose 3 large VIO fonts that are targeted at very high resolution displays.

78
Programming / Re: OPenchat
« on: November 12, 2023, 07:53:55 pm »
Openchat pre-dates exceptq by at least a decade....

Not quite. The version of OpenChat being discussed dates to 2015. I released Exceptq v7.1 in March 2011, and v7.0 sometime in 2010. Prior to that nobody used Exceptq - not because it wasn't available but because v6.x was such a POS.

79
Applications / Re: XWP v1.0.16
« on: November 12, 2023, 06:02:35 pm »
Playing with the new Text Size - was on Standard - I selected Medium size, clicked Test and was a bit surprised to see the Properties notebook shrink in size. Is that supposed to happen?

Absolutely!

The size of dialog windows and their contents is proportional to the size of the default system font. IOW, a bigger font produces bigger dialogs. This worked great back in the days when all dialogs used the default font (System Proportional) for their text. As the font size increased, the dialogs automatically grew to accommodate. Then along came WarpSans...

To ensure that the system used the new font, eCS and AOS added entries to 'os2.ini' to force the use of 9pt WarpSans rather than the system default.. However, no one ever added an entry to lock down the default. I guess they assumed this was invariant and would always be 10pt System Proportional. But that isn't the case: at resolutions of 1280x1024 and above, the default system font changes to 12pt System Proportional. The result on higher res displays is overly-large dialogs that have been scaled to use 12pt while their content hasn't been scaled up and remains at 9pt.

'Text Size' addresses this by *always* setting the default system font to a size that will comfortably handle whatever size of WarpSans you choose. For the "Small" and "Medium" (9 and 10pt WarpSans) sizes, that's 10pt System Proportional. The result is dialogs that are the "correct" size - in this case, smaller.

80
Programming / Re: shared memory value - Odin win32k or DosQuerySysInfo???
« on: November 11, 2023, 06:40:28 pm »
Was wondering if your widget made it into xwps 1.0.16?

No, it wasn't ready so it will probably show up in v1.0.17 which I hope to have out sooner rather than later.

81
Programming / Re: shared memory value - Odin win32k or DosQuerySysInfo???
« on: November 09, 2023, 07:35:58 am »
1) QSV_TOTAVAILMEM

Apples...

Quote
2) QSV_MAXPRMEM

Oranges...

You are conflating two separate concepts: 'physical/virtual memory'  and 'linear address space'. Here's a simplistic analogy.

You have a store with inventory (RAM) and shelving to put it on (address space). Periodically, you'll face one of two problems:

A) you want to add more shelf space but you have nothing to put on it because your entire inventory is already on the other shelves. You could put empty boxes on the shelves (i.e. swap space) to make it look like you have more inventory than you really do but eventually you'll run out of that too. In the real world, you're out of 'physical/virtual memory'.

B) you have plenty of inventory but can't put it out because the shelves where it should go are already full. In the real world, you're out of 'linear address space'.

These days 'A' isn't the problem it used to be - most of us have far more than we can use. And for many of us, we can't even find a use for all the physical RAM we _could_ use, so we never run out and *never swap*. Those of us who know their needs are modest (don't build QT6, don't keep 40-50 browser tabs open, etc.) have no reason to give physical memory a second thought.

In contrast, 'B' (linear address space) will always be an issue because OS/2 will always be limited to 512mb of low/16-bit compatible memory. It isn't as bad as it used to be with the advent of high memory (i.e linear address space whose addresses start at 512mb). Still, it's worth monitoring - which is why I wrote a little widget to do so (shameless plug).

With the possible exception of PUMon when it uses 'Win32K.sys' (which I've never seen), every monitor that attempts to show available private and shared memory suffers from the same problem: GIGO. The values returned for QSV_MAXPRMEM and QSV_MAXSHMEM are misleading and substantially useless because the same stretch of memory is included in both. To illustrate this, I've copied the screen shot of my 'memmap' widget from an earlier posting. Take a look at it.

QSV_MAXPRMEM includes both the areas in red and those in gray. QSV_MAXSHMEM includes the areas in gray and in green. What good is that? I labelled the area in gray as "Free" due to space constraints but it's more correctly labelled "Unassigned". It's available for use as either private or shared memory, whichever claims it first.

When I took the screenshot, Dooble had been open and had claimed 46mb of the unassigned memory for private use (in addition to the 64mb of private memory every app is guaranteed). Even after closing Dooble, that 46mb would remain assigned to "private" until the system was forced to reclaim it. If you were to look at a typical mem monitor, you'd get the mistaken impression that Dooble had allocated but not freed 46mb of shared memory. But that wouldn't be correct because that memory was _never_ shared, it was "unassigned".

FYI... "real" shared memory starts at the lowest address that's actually being used. If that allocation is freed, it goes back into the unassigned pool. Any memory above that which gets freed is stuck behind the dividing line and will remain shared memory - whence the figure for "Shared - unused".

FYI2... unassigned memory claimed for private use, then freed, is not reclaimed until the system has run out of shared and unassigned mem. It will then survey all running apps to see how much private memory they're actually using. If <= 64mb, it will return the excess to the pool, then use what it needs to fill the request for shared mem that triggered the review.

Correction: high mem starts at 512mb, not 1gb as originally written

82
Applications / Re: XWP v1.0.16
« on: November 07, 2023, 05:07:50 pm »
I may have found one small problem with the XWP Startup folder.
[...]
If I right click on the inside of the folder and select icons, the choices come up. If I select Large, everything is find.
Now if I select Dynamic and select a size, ArcaOS hangs up big time which requires a soft boot.

I tried this on 3 separate installations of AOS 5.1 (same machine) and couldn't replicate the problem. However, that's not to say that there isn't a problem with Dynamic Icons...

I recently found that if I drag a program object to an open folder set to "Dynamic", then Ctrl-drop to copy it, the Desktop seems to lock up. In fact, it's only the first thread (the one that handles most of the UI). XCenter, which runs on its own thread, continues to update the time and CPU monitor. After a bit, I can access open apps but 'TOP' is unable to kill the WPS.

While testing the Startup folder, I also tested this on the 3 installations. Two of them had the problem, one didn't. The difference was the drive each was on: the two problems were on my NVME drive, the one that worked was on a SATA-attached SSD. My guess is that this is a timing issue that arises when D.I. tries to query the .exe's icon. Because the SSD is "slow", some other operation completes before the drive returns the icon. In contrast, the NVME is so fast that it delivers the icon before the other activity is done, causing some sort of deadlock. (Like I said, just a guess...)

@DavidG, it would really help if you could try this again to see whether your XCenter widgets still update after the lockup. If they keep working, then we (probably) have the same issue.

83
Applications / Re: XWP v1.0.16
« on: November 06, 2023, 10:31:46 pm »
associate it [xunlock] with '*.DLL', '*.EXE', and '*.FON'
is the attached pic the correct way to do the associations?

It looks like you left out the asterisk. Without it, this will only work for files named ".exe" or ".dll" - there aren't too many of them :) Remove them and re-enter.

FWIW... it's perfectly OK to associate a specific file with an app. For example, in AOS 5.1 the new Multimedia Installer is associated with the file 'CONTROL.SCR'. This allows you to install an MMOS/2 package by doubleclicking this file rather than having to run minstall from the commandline.

84
Applications / Re: XWP v1.0.16
« on: November 06, 2023, 07:00:39 pm »
Here are a few notes I forgot to put in the announcement:

* updated versions of ANXWP (AN's customized XWP-Lite) should be available from AN shortly - they typically send out an announcement to customers when it's ready.

* if you are simply upgrading from the previous version and not changing from, say, ANXWP to XWP-Full, then you can uncheck the options to "register classes" and "create objects". This will keep it from messing with your folder menus and the like.

* if you use Styler's shutdown feature rather than XWP's, you must upgrade to the new version of Styler (v1.20) to have any 'Text Size' changes take effect. Alternately, you can disable Styler v1.10's shutdown, reboot using XWP, then reenable Styler.

* suggestion: locate 'x:\sys\apps\xwps\bin\xunlock.exe', open its Properties notebook, and turn to the 'Association' page. Now, associate it with '*.DLL', '*.EXE', and '*.FON' (no need for a program object). Hereafter, if you need to replace a binary that is currently in use, you can select 'xunlock' from its "Open as" menu, then do the replacement. Of course, you'll still have to terminate the app or reboot to have the system use the new binary (in the case of a WPS dll, just select 'Restart Desktop').

85
Applications / Re: XWP v1.0.16
« on: November 06, 2023, 06:38:23 pm »
had a problem to start the wps after installing (same on both of my AN-partitions).
wps didn't build up and collapsed again and again. Reboot + shift helped though (using older ini).

I'm sorry to hear you had problems with this. Are you now able to start up OK and get to the Desktop?

I know of one possible startup issue but it isn't something that could be fixed by reverting to an older INI. More likely, it would cause the system to hang (no one has reported the issue so far, so I really don't know what it looks like - hang/crash/just some beeps).

If anyone has a hang or crash at startup that can't be fixed by using an older INI, then it would be _really_ helpful if I could see the last few entries in 'x:\var\log\xwptrap.log'. If you can't boot the system normally, you can get to it by booting the AOS installer and using the System Management console. Or, you can use Alt-F1 at the boot blob to boot to a command line (under UEFI, select "Show Recovery Options" then continue - the following screen will offer "F2 - boot to command line").

86
Applications / XWP v1.0.16
« on: November 06, 2023, 06:36:20 am »
XWP v1.0.16 introduces some of the most significant Desktop usability improvements in years.

New Features
  • Text Size
    With two clicks and a reboot, you can now set the text in folders, menus, titlebars, notebooks, and most dialogs to a size you can read. Use the first page of the Desktop's Properties notebook to try it out. In Test Mode, changing the text size will cause the notebook to resize and redraw itself so you can see what that size looks like. No changes will be made to your system until shutdown, so you can undo this at any time before then.

    Developed in conjunction with Alex Taylor, this feature relies on Alex's extended-size versions of 'System Proportional' and 'WarpSans'. The latest versions available will be installed by WarpIn if they appear to be newer than your current versions.

    Note: Text Size itself only affects programs that are aware of it. These include system components like PM, the WPS, XWP, Dynamic Icons, and a few others. Use Alex's newly-released Styler v1.20 to extend its reach to 3rd-party dialogs that don't specify a text size.

  • Large Icons in XCenter
    XCenter's Properties notebook now gives you a choice of Large (full-size) or Mini (half-size) icons. The WinList widget extends this by letting you set its icon size separately from XCenter and by giving you the choice of text, icons, or both on its buttons.

  • Low Battery Alert
    The Battery widget now has a Properties page to set up the widget's new alert. Set the level at which a warning should pop up (e.g. at 15%), and optionally, set follow-up warnings whenever the level drops another specified percent (say, 5%).

Updates and Bugfixes
  • XStartup
    Large parts of the XStartup code have been rewritten for improved reliability. It should no longer be necessary to impose a long delay to ensure the first object starts properly. XStartup's notebook page has also been updated with XWP-Full's Boot Logo option getting its own page.

  • XWP Help
    A Table of Contents has been added to the XWP Help system to organize its many pages into 21 top-level topics. Expanding a topic displays all relevant pages with no further nesting. Also, features not included in XWP-Lite should no longer appear in its Help file.

  • Other Changes

    • XShutdown has been revised to invoke Text Size's shutdown processing when updates occur. Related code has been refactored.

    • An undocumented setup string has been added to XFldDesktop to enable Styler and other shutdown utilities to invoke Text Size's shutdown processing when changes are pending.

    • 'xwptrap.log' has been partially reformatted to make it less verbose.

    • 'h2i.exe' which converts HTML help to .INF format has been revised to support an optional "Table of Contents" mode.

    • 'xunlock.exe' has been added to the distro to ensure scripts always have access to an "unlock" utility. It returns 0 if the file is now unlocked and >0 if it remains locked or an error occured.

    • A rewrite of the Window List widget should ensure that its last button doesn't paint over the widget to its right.

    • Code to read the display's EDID has been added to support future Text Size enhancements.

Downloads

Until XWP's files have been cataloged, they should be available from /pub/incoming (the link for Styler v1.20 is already live).

87
Setup & Installation / Booting eCS and MCP under UEFI
« on: November 04, 2023, 06:12:26 am »
Overview

If you installed ArcaOS 5.1 in UEFI mode on a machine that also supports CSM/BIOS, the instructions below will allow you to boot your existing eCS or MCP installations alongside your new 5.1 system - all while remaining in UEFI mode. This procedure requires no changes to your legacy installations, and only two small changes to AOS 5.1's 'config.sys'. The primary downsides here are that you will lose 5.1's DOS video enhancements, and the  AOS boot logo will no longer be displayed.

Note: this procedure can also be used to restore 16x9 resolutions on older machines that only offer 4x3 video when booted in UEFI mode.

Procedure

TTBOMK, the following instructions are complete and correct, and should be followed exactly as written.

1. Confirm the machine is in UEFI mode and that CSM is enabled.

2. Assign a drive letter to your EFI partition (e.g. 'U:') then open the folder 'U:\EFI\OS2'.
    Create a new file in this directory named 'OS2LDR.CFG' that contains this single line:

Code: [Select]
alt_video = 1

3. On your AOS 5.1 install, open 'config.sys' in an editor. Change these two entries as shown:

Before
Code: [Select]
DEVICE=C:\OS2\MDOS\VEFI.SYS
SET VIO_SVGA=DEVICE(BVHEFI)

After
Code: [Select]
rem DEVICE=C:\OS2\MDOS\VEFI.SYS
DEVICE=C:\OS2\MDOS\VSVGA.SYS

rem SET VIO_SVGA=DEVICE(BVHEFI)
SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA)

4. In your boot manager's config file, add entries for your BIOS-based installs that are identical
    to the one you have for AOS 5.1, with the only difference being the drive letter to be booted.

    For example, if eCS 2.x is on your E: drive, its entry in 'launcher.cfg' would look like this:

Code: [Select]
eCS 2.x (E:) = \EFI\OS2\OS2LDR.EFI E:

    In 'refind.conf', it would look something like this:

Code: [Select]
menuentry "eCS 2.x (E:)" {
    loader \EFI\OS2\OS2LDR.EFI
    options "E:"
}

5. Reboot.

Notes
  • This is a machine-wide change that affects all AOS 5.1 UEFI installs. If you have more than one, update 'config.sys' for each.
  • Do not make any changes to your BIOS-based installs in connection with this - it should all "just work" with no user intervention.
  • This has only been tested with Panorama. Regardless, SNAP should work as well.

88
Setup & Installation / Re: UEFI: Dual Boot - Windows 11 and ArcaOS 5.1
« on: November 03, 2023, 09:25:36 am »
I was recently shown such a layout on ESP:
[...]
Here is no bootx64.efi at all.

BOOTX64.EFI is a fall-back that is only used if:
* the firmware finds an ESP that has no entries in its boot list but does have this file
or
* the firmware is booting an MBR disk, in which case it always boots this file regardless of the boot list

Basically, the firmware assumes that if it is looking at an MBR disk, it must be a removable disk (i.e. USB stick or the like) that is being used to install an OS. This isn't unreasonable given that 99.9% of all UEFI installs are to GPT disks while most install media are still MBR.

89
Setup & Installation / Re: UEFI: Dual Boot - Windows 11 and ArcaOS 5.1
« on: November 03, 2023, 05:08:48 am »
Rich, your instructions do work, and I can boot ArcaOS 5.0 directly from rEFInd.
I can also boot ArcaOS 5.1 directly as I did before.

As you pointed out, DOS window does not work in ArcaOS 5.1, and it never worked in ArcaOS 5.0. This is fine for me, as I rarely use DOS.

Just to confirm: "success" means you can see whatever messages are displayed during bootup and that you can open full-screen DOS and OS/2 sessions. Is that what you see on both the 5.1 and legacy installs? And yes, if DOS windows didn't work under 5.0, they shouldn't work under this arrangement because you've reverted to 5.0-style video support.

90
Setup & Installation / Re: UEFI: Dual Boot - Windows 11 and ArcaOS 5.1
« on: November 02, 2023, 08:40:17 pm »
using the UEFI shell looks like fun but could be the answer to a couple of incorrect descriptions - not sure how - in the boot list:
a] AN Launcher shows as UEFI-OS
b] rEFInd shows as Windows Boot Manager

rEFInd shows as Windows Boot Manager because you didn't change the name when you were using 'bcdedit' to change its path to reFind. AN Launcher shows as UEFI-OS because the firmware found another 'BOOTx64.EFI' in your other ESP. You can delete the entry as often as you wish but it will keep coming back until you delete/rename the file.

From a command prompt run 'bootorder /v' to see the list of items in your firmware's bootlist and reorder them as needed. I wrote both 'bootorder' and 'bootdelete', and planned to write a 'bootadd' but quit AN before I got around to it. 'bootorder' made it into 5.1 but 'bootdelete' didn't, so I've attached it here.

I seem to recall something about being able to boot both GPT and MBR volumes on the same disk somewhere in the ArcaOS 5.1.0 related docs but have not been able to find it again to check exactly what was stated.

Perhaps you saw it 2 or 3 postings above this one... (edit: I assume you meant UEFI and BIOS installs on the same disk rather than GPT and MBR)

What really amazes me is that seemingly no one has tried to simply use 'os2ldr.efi' to boot a BIOS-based install in the exact same fashion as a UEFI install. Had they done so, they would have found that all text-mode output is hosed: inital bootup messages and all full-screen sessions are just colored dots at the top of the screen. However, the Desktop comes up just fine and Win/OS2 works as well. The fix I referred to above (if it still works) simply restores text-mode video. Neil has my instructions on how to do so. If it works, I'll post them in a new thread.

Pages: 1 ... 4 5 [6] 7 8 ... 23