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 4 ... 11
Applications / Re: Replacing "Save as..." dialog (Experiment)
« on: June 02, 2021, 07:27:10 pm »
I kind of prefer the "Save as..." dialog from Qt, instead of the FOC that comes in ArcaOS.
Will it be a way to create an experimental "hack" to replace the call of the "Save as..." dialog to call the one from Qt?

Martin, do you realize that this would require large parts of Qt to be loaded into every PM process? That's probably not a good idea.

it seems that with the help of GPT.FLT (that can modify the IORBs passed between OS2DASD.DMD and the ADD drivers), you can also address sectors beyond the ABSOLUTE 2TB limit and that OS2AHCI.ADD has some sort of extension to use 48 bits of LBA address. Potentially what I proposed earlier on.

I didn't see your proposal so I wrote my own  :)

There are two new CommandCodes: IOCC_GEOMETRY64 (0x13) and IOCC_EXECUTE_IO64 (0x14). They signal the use of new extended IORBs, GEOMETRY64 and IORB_EXECUTEIO64. The only difference from the 32-bit IORBs is that a 64-bit field has been added at the end of the structures to hold ullTotalSectors and ullRBA, respectively. The .ADD code is unchanged except that it now looks at the CmdCode to decide whether to take the LBA from the 32-bit or 64-bit field.

Current versions of AN's 'os2ahci.add' and 'nvme.add' support this interface. It's use comes at a small cost: for requests above 2TB, GPT.FLT has to create a 64-bit version of each request before it sends it to the .ADD. Each request is less than 100 bytes, so the overhead is minimal.

BTW... IOCC_GEOMETRY64 returns the actual number of sectors on a disk - it isn't rounded down to a cylinder boundary. The call can also be used as a safe way to determine if 48/64-bit support is available.

What is the reason why OS2DASD.DMD cannot be modified? License issues?

Virtually everything above the .ADD/.FLT level is tied to 32-bit LBAs. There's just too much to change.

As I understand it, the GPT filter driver will split a 6 TB drive into 3 units of 2 TB each, allowing you to access a 6 TB drive as, for example, E:, F: and G:. This is different from a single drive letter with 6 TB, which is currently only possible on a network drive.
Ok, that pretty much explains it. The drive letter "logically" extends the 32 bit LBA address, providing additional upper bits for the 48 or 64 bits sent to the device to address a sector. At least, that is a good trick but it uses up valuable drive letters.

Sorry but none of this is correct.

GPT.FLT (which isn't really a filter, per se) creates a set of emulated MBR disks, one for each partition you want to mount. It then makes each GPT partition look like it is the only primary on that MBR disk. Because access to the underlying disk (which OS/2 knows nothing about) is through this MBR emulation, MBR limits of 2TB apply.

Also, because this is an emulation, LVM disk spanning (which requires additional on-disk LVM data) is impossible.

I don't have to worry about future hardware support or getting the right hardware.

Oh ye of little faith...

Friday afternoon I went out and bought a mass-market "Windows PC" - the kind of low-end machine OS/2 users have always avoided.  In this case, a Lenovo IdeaCentre i5 with Intel i7 (8 cores), 16gb mem, and a 512gb NVMe drive formatted GPT with Win 10 Pro ($800US incl tax). The system is pure UEFI with no BIOS or CSM support.

After setup, I changed the drive order to boot USB first, then used Windows Disk Manager to shrink the Win partition. When done, I inserted my flash drive with the latest ArcaOS beta, crossed my fingers and rebooted. The installer came right up and the installation proceeded without issue. No "drama" whatsoever. I now have a fully functioning OS/2 UEFI/GPT system running on hardware that was 100% incompatible 6 months ago. No flawed emulation needed.

Now, does the integrated WiFi/Bluetooth work? Of course not - but the ethernet does and that's all I need. Does the audio work? Not with my older Uniaud build [it does work] - but I use USB audio instead because it always works. Etc, etc... Ignoring the bits and pieces that have always been a problem, I'd say AN has delivered (or is about to deliver) on its promise of OS/2 on modern hardware.

BTW... check out WSE in a few weeks - there will be a demo of installing AOS on a Windows Linux PC.

[Full disclosure: I work for AN and am actively involved in UEFI/GPT development.]

Hardware / Re: Remove Audio Adapter - Warp 4 - VM
« on: March 02, 2021, 02:19:29 am »
Martin, if you have any of the recent AOS betas you can use 'mmi.exe', my nearly-complete Multimedia Installer (no help yet). It will install/remove any MM package copied to your system or included on the AOS DVD, and will clean up 'mmpm2.ini' when done.

On an installed system, it's in '\MMOS2'. To get at it from an ISO, mount the image, then navigate to:
and run it from there.

Note: MMI is perfectly happy to uninstall drivers that aren't installed - it won't complain when it doesn't find any files. You can use this to trigger an 'mmpm2.ini' cleanup without making any other changes to MMOS/2.

Multimedia / Re: Desktop weirdness
« on: January 14, 2021, 03:48:22 am »
I have used the VOICE HelpDesk thing in the past, but that won't work any more (Telus has blocked everything), so I can't have a look.

You should re-read "HelpDesk.txt".

Code: [Select]
  Alternate Ports
  Hosts that already run an SSH server on Port 22 may want to configure
  HelpDesk to use another port.
  Note: using an alternate port may enable connections from clients who
  are behind a firewall that blocks port 22. Try using the port for a
  well-known service such as http (80) or some flavor of email that is
  less likely to be blocked.

BTW... what ever happened to the once-standard advice of "Run checkini"?

Code: [Select]
 Checking PM_Workplace:Startup

║ Remove stored reference to non-existing or faulty startup folder ?  ║
║     NOTE: Objects in this folder will no longer be autostarted!     ║
║                YES               │               NO                 ║

Programming / Re: REXX: RxStartSession, what is wrong with this call?
« on: January 04, 2021, 08:04:29 pm »
Code: [Select]
DEBUG ParseArgs => processing argument:0
DEBUG ParseObject => pArg:v:\photo
DEBUG ParseObject => pPath:
DEBUG ParseObject => DosQueryPathInfo API RC:15
invalid or malformed path

I wouldn't claim to really understand what the above is saying, but shouldn't 'pPath:' be displaying "v:\photo"? If the path is null, rc=15 (ERROR_INVALID_DRIVE) would not be inappropriate.

Programming / Re: Is there a /proc/self/exe for OS/2?
« on: December 14, 2020, 05:28:59 pm »
The system standard method might not be sufficient because for a call from command line, it will only return what was entered on the commandline. At least that is what I seem to remember.

No. It will always provide the fully-qualified capitalized pathname. The next string is the filename as entered on the commandline, and the string after that is the commandline parameters. This never varies: if the info is available, it is presented as described. (Use Theseus4 to examine any process's environment segment - it's all right there.)

Programming / Re: Is there a /proc/self/exe for OS/2?
« on: December 13, 2020, 04:03:39 pm »
I'm surprised that no one mentioned the system-standard method for determining a process's executable. The string should be accessed during startup and saved elsewhere if needed because it might not persist.

Code: [Select]
PPIB    ppib;
char   *ptr;

// get the Process Information Block
DosGetInfoBlocks(0, &ppib);

// get a pointer to the environment
ptr = ppib->pib_pchenv;

// loop through the environment strings to find
// the null string that terminates it
while (*ptr)
    ptr = strchr(ptr, 0) + 1;

// the exe's fully-qualified filename starts at the next character

strange things happen every now and then, including regular CPU usage being at 100%.

Thanks for that tip - it gets me closer to maybe explaining this:

On an idle system, open a Pentium-M version of FF to a blank page. Wait precisely 8 minutes from the time FF's window first appears. Nonstop bursts of activity will begin and never stop. Do the exact same with a 686 build (same profile) and there's no such activity.

I tested this with Dave's FF builds that are currently in 'incoming/' at hobbes. Months ago I discovered the same unexplained activity in SM, but there it takes 15 minutes. I looked at every possible entry in about:config for something that might control the timing but never found anything. I don't think it's associated with the FF "Health Report" (which I always turn off) or any other network activity.

Any ideas?

Storage / Re: FAT32 - Netlabs or AN?
« on: November 28, 2020, 10:22:49 am »
The current Netlabs version is an outstanding example of undisciplined design.

What started out as a FAT32 driver morphed into an exFAT/FAT12/FAT16-and oh yeah-FAT32 driver with no appreciable improvements in speed or code quality. Then it went off into outer space with the ability to mount disk images from various VMs, and finally, a Unix-style loop adapter that requires a new BASEDEV.

What does a BASEDEV that mounts disk images as drives have to do with a FAT32 filesystem driver?

I'd love to have a loop adapter to mount images, and I wouldn't mind downloading an exFAT driver from a jurisdiction that doesn't recognize s/w patents - and I could accept less than sterling software quality if they were packaged separately. But when it comes to saving my data in a format that has become a must-have (i.e. FAT32), I want something reliable, not "feature-rich". For that, I use AN's version.

Applications / Re: ArcaOS kernel 202 and Firefox
« on: November 22, 2020, 05:50:08 am »
So I still will need to mark the Mozilla DLLs to load high, but I no longer need mozturbo or anturbo. I hope this helps. Managing all the turbos was difficult if running two versions of Firefox, for example.

ANTurbo ('TurboSetup.cmd') is still useful since it knows which DLLs to load high and can tell you their current status. After using it, delete the turbo object(s) in your Startup folder if you don't want to preload the DLLs. Here's what the setup script reports after doing so:

Code: [Select]
Status:  Partially installed
  - 18 of 18 DLLs are marked for high memory
  - SMTurbo startup object not found
  - SMTurbo.exe is not running

One of these days I'll rewrite it to eliminate the turbo stuff, but for now this workaround should suffice.

Applications / Re: openssh-server on ArcaOS
« on: October 22, 2020, 05:48:53 am »
I've installed openssh-server on ArcaOS 5.0.2 (yum install openssh-server) but it doesn't appear that the port 22 is open,

OS/2 doesn't have a firewall installed by default, so nothing is blocking port 22.

How are you testing? Using localhost for both client and server, or from one machine to another? If the latter, have you configured your router appropriately?  IOW, unblocked the port in the router's f/w _and_ set up port forwarding for port 22?

Hardware / Re: Someone tried OS/2 with 3840x2160 Display?
« on: October 16, 2020, 06:54:34 am »
I do have the physical desk real estate to actually put such a behemoth of a display up, which means, maybe I should?

Don't - it promises to be an ergonomic nightmare. Displays like this are meant to be used as true "monitors": screens that you refer to but don't actually work with. Here's why:

Normally, a display is positioned so you are looking at a point about a third down the screen. This allows you to see the top 2/3rds with eye movement and the bottom 1/3rd by bending your neck down slightly. Now, look at where the top of the Ilyama is in relationship to the top of the conventional monitors. Your direct line of sight is about half-way down. Given its size, eye movement only covers perhaps 1/2 the screen. This means you have to lean your head back to work with the top 1/4. Try having your neck bent backward for more than a minute or two - you will *not* be happy.

Programming / Re: Aligning on 64k boundary
« on: September 14, 2020, 05:56:27 pm »
How do you allocate memory (a buffer for a message) so that it does not cross a 64k boundary? 
I don't see anything specific in DosAllocMem().

If you invoke DosAllocMem() and don't explicitly use the high-memory flag ("OBJ_ANY"), you will always get a buffer aligned on a 64k segment boundary. There is an "OBJ_TILE" flag but it is redundant since low-memory is already tiled.

Alignment issues are a bigger concern if you're using memory allocated from the heap because that could start anywhere. You might have to allocate up 128k in order to have a full 64k that starts at xxxx0000.

Pages: 1 [2] 3 4 ... 11