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] 2 3 ... 7
Applications / Re: XWP v1.0.13 Beta 1
« on: September 06, 2019, 04:22:23 am »
After installing 1.0.13 beta, Warpin still shows 1.0.12. Is that intentional ?

Yes, it's It won't be 1.0.13 until the GA.

Background: back in the past something screwed up my Warpin Database and that happened AFTER I installed XWorplace 1.0.12 but BEFORE I installed 1.0.13. It is possible that on installation of 1.0.13 there was no entry in the Warpin database for 1.0.12.

Nonetheless the side effect for the AMouse plugin installation remains: you will have to RERUN the AMouse plugin installation (deinstall and then reinstall) after installing XWP (to a different directory). Or fiddle around with files.

To see if there really was a problem, I did the following 3 times: I uninstalled XWP, reinstalled an older version in one of several directories, then upgraded to one of the betas (with a reboot in between each step). In every case, WarpIn forced the upgrade to use the existing directory, not a new one. You may have had a WarpIn failure, but I don't believe XWP was the cause.

Next time, you might consider reviewing the suggested installation directory and possibly changing it before pressing OK...

Programming / Re: fully programmatic menu creation?
« on: September 05, 2019, 09:12:56 pm »
I'm looking into the feasibility of porting some GUI code to OS/2. One of the things needed is to create the menubar and menus completely in code.

From skimming online books, I gather that this is possible, but apparently not as straightforward as calling single API methods like win32's CreateMenu, AppendMenu, SetMenu, etc.

Creating menus programmatically is quite easy but it isn't done using API calls that resemble those in Windows because the windowing model is different.

A top-level OS/2 Presentation Manager window does not have a non-client area where the OS draws stuff like menus and titlebars for you. Instead, each of these design elements is a separately created window of the appropriate class whose size and position is coordinated by the top-level "frame window".

Menubars, popup menus, min/max/close buttons, and system menus are all windows of class WC_MENU. Like any other window, they are created using WinCreateWindow() and are manipulated by sending them window messages such as MM_INSERTITEM. The end result is the same as CreateMenu() and AppendMenu() but the methodology is different.

To get a better understanding of PM windowing, I highly recommend PMTree. It provides a graphical display of the OS/2 windowing hierarchy for every top-level window open on the Desktop. You'll quickly discover there's a lot more to OS/2 windows than Windows' windows.

FWIW... on a practical note: in cases where you need to create custom menus, it is often easier to create and load conventional menu template resources, then customize them by adding or removing items, rather than starting from scratch.

Applications / Re: XWP v1.0.13 Beta 1
« on: September 03, 2019, 05:40:41 pm »
The reason for the trouble with Widgets not being found is this:
for some reason XWP 1.0.13 Beta1 does not install into the same directory as 1.0.12 did. And therefore you need to copy over the widgets from the "plugins\xcenter" directory of 1.0.12 to the 1.0.13 directory tree (in the "plugins\xcenter" directory).

Thanks for pointing this out. The directory change was intentional, the side effects weren't. However, I don't understand why the beta wasn't installed into the existing directory structure - that's the way WarpIn usually works. Did you uninstall the previous version before installing this one?

Applications / Re: XWP v1.0.13 Beta 1
« on: September 03, 2019, 05:59:51 am »
All the files are there.  However, the AN removable object fails to appear as an option in the widgets select.

I'm confused by some of the non-standard terminology you're using. Please do this:

Right-click anywhere on XCenter to bring up its menu, then click on the "Create new widget" item. At the top of the submenu that appears, you should see "AN Removable Media Monitor".
* if the item is enabled, click on it to add it to XCenter
* if it's disabled, then the widget has already been added - either to this XCenter or another one. Are you _sure_ you don't have two XCenters open (one on top of the other, perhaps?).
* if it isn't present, then are you certain that you have 'RemMedia.dll' and 'RemM_EN.msg' in 'x:\sys\apps\xwps\plugins\xcenter'? (The other files don't matter.)

Note:  Checking my other partition, in the XCenter>Properties>Widgets
The an Removable media is listed with the option of rebuilding object when right mouse button selected. My problem partition does not list it in the Widgets page and as a result cannot be rebuilt, although all required files are where they should be.

A widget only appears on the Widgets page if it has already been added to XCenter. If it isn't listed, you have yet to add that widget. Use the context menu for any existing entry as another way to access the "Create new widget" submenu. Assuming RemMedia appears on the submenu, select it to add it to XCenter.

Note: the "Classes" page of the XCenter properties lists all the DLLs XCenter knows about. Is "remmedia.dll' listed? If not, the files probably aren't in the right place.

Programming / Re: DragText & STDIN
« on: September 03, 2019, 03:49:58 am »
If text is dropped and the drop target is an app, then it's possible that the file created by the app will be saved in the directory of DragText. Not in the directory of the source of the text or, for example, in the desktop directory (i.e. the homre of the WPS).

Not supporting files in the the DragText directory is not a perfect option, and using <WP_DESKTOP> if the path of the output file would be DragText's may surprise an user.

Are there other options to exclude DragText input, or to avoid the use of the DragText directory? The dropped DragText file has got rather specific EAs. If the dropped file is located in DragText's directory, and the EAs may be DragText's, then use the <WP_DESKTOP>?

Rather than making a simple task pointlessly complicated, have you ever considered using the target app's "Save as..." menu item? After all, it _is_ the accepted method for choosing the correct name and path for a file you wish to save.

FYI... the reason you're getting the filename 'DT_TEXT' is because your editor doesn't understand DragText's native methods for exchanging text. If it did, the text would just appear and have no effect on the filename. Instead, your editor is reading a temp file created specifically to enable d&d in more apps.

If that's unsatisfactory, you can disable creation of the temp file so the operation always fails ("Setup->Paths->Create temp files" in DT's Settings notebook). If instead you would like to have DT override the app's handling of d&d so DT's native text exchange works, try this (it may not work): open DT's notebook to Setup->Reenable. Look at the entry for 'e.exe', then create a new one for your app with the same checkboxes selected.

BTW... DT has nothing to do with 'stdin'.

Applications / Re: XWP v1.0.13 Beta 1
« on: September 01, 2019, 08:06:53 pm »
So far it works ok, but graph in CPU pulse a little bit out of screen.

I found the problem and fixed it. Oddly, it only affected systems with 1 or 2 cores. On my quad-core, it worked OK. I had to set /MAXCPU to 1 or 2 to see it.

Is there any possibility to read Virtual Address Limit from DosQuerySysInfo but not from config.sys?

Are you referring to the V.A.L setting on the Memory page of the "Kernel" object? The slider there changes the setting in config.sys, so I'm not sure it is a good idea to read the value from somewhere else. Why do you need this change?

Applications / Re: XWP v1.0.13 Beta 1
« on: August 30, 2019, 07:04:38 pm »
So far it works ok, but graph in CPU pulse a little bit out of screen.
More than a little bit, over 50% pulse graph does'nt show at all.

The widget relies on XCenter to give it the dimensions of its window - and sometimes XCenter gets it wrong. If that's the case here, then you can easily fix this.

First, expand the width of the widget; the graph will redraw itself. Wait a moment, then restore it to your desired size; again, the graph will be redrawn. Does this fix the problem? If not, try increasing the height of XCenter. Let it reformat itself, then restore the original height.

One or the other of these resizing actions should cause the graph to be drawn correctly. If not, please let me know.

It also tracks a lot faster which seeks attention from ones eyeballs, the older and slower one you only looked at when you wished to.

The speed has been doubled from 1 sample per second to 2 samples per second. The slower speed hid a lot of the sub-second variations and gave some users the impression that it was grossly inaccurate. In fact, it was accurate but failed to provide any real-time indication of activity.

Personally, I consider the line graph to be totally worthless if you have more than 2 cores. It just devolves into a meaningless jumble of lines that tell you nothing about actual usage - particularly when running FF or SM. The new bar graph provides a far more coherent view of overall usage. If a mozapp has a core pegged, the bar graph tells you about it without letting that excess activity take over the entire display.

I still have a problem with cmd file icons vanishing from the Tray but I suspect it is likely to be none XWP related as cmd icon's change of there own volition sometimes

This is a fundamental flaw in PM that occurs when the WPS restarts. PM mistakenly thinks that the WPS is using is a copy of the system's VIO icon, so it destroys that copy when the WPS terminates. In fact, the WPS is using the original icon; destroying it leaves the system with no VIO icon at all.

There are two possible outcomes here. One possibility is that windowed text-mode apps (such as cmd.exe) have no icon at all. The other is that PM reuses the memory for some other icon, giving cmd.exe and friends a completely unrelated icon. What I see most often is a printer or printer-port icon.

Applications / Re: My experience with ArcaOS & problems I've faced etc.
« on: August 11, 2019, 10:35:42 pm »
when the update was done XCenter didn't start automatically during bootup. I had to finally manually create a shadow into the Startup folder to fix that.

This should not be necessary, nor is it a particularly desirable way to start XCenter.

The very first option on the first page of XCenter's Properties notebook is "Open XCenter automatically". If it isn't checked, please enable it, then remove that shadow from Startup. This way, XCenter will also reopen automatically if you restart the Desktop - that won't happen if it is started from Startup.

OTOH, if it is checked _and_ it consistently fails to open after a reboot or restart, please advise so I can investigate the problem.

Applications / Re: XWP v1.0.13 Beta 1
« on: August 06, 2019, 01:59:32 pm »
would it be possible to remove/avoid the entries for USB sticks/HDDs (that had been plugged in on system start) and only keep those for fixed disks ?

AirBoot doesn't know how a drive is attached, so nothing in its menu would enable USB drives to be filtered. XShutdown is in no position to do any filtering because it fetches the list immediately before showing the Shutdown dialog. If it takes more than 3 seconds to get the list, it abandons the effort and doesn't show any list. There just isn't time to probe multiple partitions to handle an edge case like this.

Applications / XWP v1.0.13 Beta 1
« on: August 04, 2019, 11:31:23 pm »

The first beta for XWP v1.0.13 is available for testing.

New Features
  • XShutdown now provides a live Reboot List taken from your AirBoot/BootManager's menu. It is always up to date and requires no configuration (IBM BM support requires LVM). XShutdown's page in the Desktop's notebook has also been updated.
  • The Pulse widget now offers two types of graph: the standard line graph, and a new color-coded moving bar graph that shows average load across all cores. Other improvements include a faster line graph and fixed-position display text that shows when a core is offline.
  • An ACPI-based CPU Temperature widget has been added to XCenter, courtesy of David Azarewicz.
Updates and Bugfixes
  • NLS - Lite versions will use the "LANG" environment variable to determine which NLS version to load; the behavior of XWP-Full is unchanged. Language settings for all versions can be overridden by putting this in config.sys: "SET XWP_LANG=xxx" - where xxx is a 3-digit country code that XWP supports (e.g. 039)
  • XCenter - 'Create new widget' has been added to all XCenter menus
  • Install/Remove - after uninstalling XWP, the "System" object will be recreated in System Setup the next time the Desktop restarts
  • See XWP Help's "Version history" topic for additional update details.
This beta is available in both Full and Lite versions for German, English, Spanish, Italian, Japanese, and Dutch.


Events / Re: ArcaOS 5.0.4 is out!
« on: July 29, 2019, 06:29:50 pm »
I was wondering if the lastest fixes to XWP made it into this release?

The version in 5.0.4 is labelled v1.0.12+ and dates to April 6, 2019. It includes the fixes below. A beta of v1.0.13 will be out in a week or two containing these changes plus significant enhancements to XShutdown and the Pulse widget.
  • Pulse widget: the graph is faster and the text no longer moves as the numbers change. When a core goes offline, it now displays a dash '-' rather than a number.
  • CPU Temperature widget: this ACPI-based widget was provided by David Azarewicz.
  • XCenter: The 'Create new widget' option can now be accessed from all XCenter menus. Also, a font-size error in 'Diskfree (condensed)' widget has been fixed.
  • XView: Two fixes: Refresh/F5 failed to update Xview and all disks in any view; and, empty folders failed to display newly-added files.
  • Help: Lite builds now omit most pages that refer to features not included in LIte.
  • WPI: Changed default install directory to '$(WARPIN_DEFAULTTOOLSPATH)\xwps' from '$(WARPIN_DEFAULTTOOLSPATH)\WPS\XWorkplace'.

Programming / Re: Compiling PMMail with GCC 4.9.2
« on: July 08, 2019, 11:02:07 pm »
After building pmmail we discovered an odd issue with the gcc compilers. The popen function is hard coded to use sh as its shell which doesn't play well with path names containing back slashes and of course fails on systems where sh isn't installed.

I ran into this and got annoyed enough to write my own which doesn't use any shell at all. See the attachment.

While we're on the subject of annoyances... The file's extension should be '.c' but os2world won't allow me to attach something so dangerous, so I had to change it to '.txt'.

NDFS32 - 0

Valery, which NetDrive plugin were you using when you tested NDFS32?

My _guess_ is that the plugin, not the generic filesystem, supplies EA information. I know for certain that the ISO plugin returns '0' for DosQueryFile/PathInfo() (I never tested DosFindFirst()). It may be that other plugins return the correct value. I'm especially curious about the SMB plugin since that's the one that is most often used. I'd test it myself but I don't have a network set up right now.

It's hard to understand what good it does to return "4 Bytes" on a FIL_QUERYEASIZE if the return value is to serve as a measure of how many bytes you need to allocate when you want to actually request an EA. As I said, you need an FEALIST with at least one entry plus the extra space for the requested EA Name to return the result. even if the EA is empty/does not exist. That is most certainly more than 4 bytes.

How is the OS supposed to know that you're going to waste your time requesting some EA when it's telling you that there are NO EAs?? Returning '4' says "Ain't nothin' here, don't bother". If you're going to ignore what it says, then you'll just have to put forth some effort to calculate the appropriate size because it won't assist you in pursuing something that's pointless.

Who is using HPFS (and therefore testing with it) these days ? Nobody.

What kind of excuse is that for not bothering to find out how things are supposed to work? I have no use for willful ignorance, so I *did* try to find out. These are the results I got from running a simple DosFindFirst() against files with no EAs on various filesystems. The number is the value of FILEFINDBUF4.cbList:

FAT - 4
HPFS - 4
CDFS - 4
JFS - 0
FAT32 - 0

You know what this shows? JFS & FAT32 are BROKEN. There was a _reason_ I suggested using HPFS as a reference: "[it] has not been altered by well-meaning but potentially ill-informed third parties" the way bootable JFS has been.

Here is the back and forth discussion regarding FS_FINDFIRST/FS_FINDNEXT:

It's hard to understand why there should ever have been a "back and forth" in the first place: none of this is subject to debate.

You write a test program that incorporates the various scenarios, run it against one or more files on an *HPFS* formatted disk, then alter your own IFS to produce the same results as HPFS. Period, end of discussion. It doesn't matter if the results you get are good, bad, or just stupid - they are what the OS and programs like 'unpack.exe' were built to expect.

Note: I consider HPFS to be the reference IFS as it is the only filesystem that is pure IBM and has not been altered by well-meaning but potentially ill-informed third parties.

Pages: [1] 2 3 ... 7