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 ... 9
So trying EMX SSH or figuring out how to get the keys swapped between the two might do it.

Attached is "". This is the package I used in 'HelpDesk' because it is the only standalone version of SSH - the others need 3rd-party packages installed as well. As noted, it requires EMX which you almost certainly have.

[C:\]mem -v
Available virtual memory:   3,760 MB
I understand that you have the virtualaddresslimit of the config.sys in 3072, and it will work fine for you. But could you do the test to put 3760, and tell us if it works, or if at startup it tells you that you have an erroneous value and puts it by default.?

'mem' tells you how much physical RAM is accessible by OS/2. This has NOTHING to do with Virtual Address Limit which is a software concept unrelated to actual physical memory.

Every process has 4096mb of "virtual address space". The kernel always uses the top 1024mb of addresses from 3072 to 4096 mb. Virtual Address Limit determines how much of the remaining 3072mb a program is allowed to use.

If that proves not to be the problem, then we can use an "undocumented feature" to diagnose this a bit further.

Peter, change of plans. I'll PM you.


No problems booting from the USB flash drive and completing the "Boot with Menu for own values" section but it all goes wrong shortly after when I see the same message that Martin posted an image of earlier in this discussion. That message starts with "MAPISO R: Z:\OS2\EMPTY.ISO" - not sure what EMPTY.ISO is but R: is the RESERVEDRIVELETTER - I tested this by using U: as RESERVEDRIVELETTER and the message changed from using R: to U:

It seems that the USB flash drive gets lost somewhere as "\ARCA_ISO\ARCAINST.ISO" definitely exists on the flash drive. This was a new USB 2.0 flash drive, never used before so not a case of some older files left on the drive.

All the stuff involving drive "R:" is just setup for a subsequent step and not relevant here. If the ISO is where it should be (guaranteed if you use 'aosboot.cmd'), then the problem is that the flash drive you used failed to mount when the script called 'lvm /rediscoverprm'.

Every instance of this failure ever reported has been attributable to the lack of an XHCI driver on a machine that only has an XHCI controller (i.e. no EHCI/UHCI/OHCI chip). In this case, the failure might also be attributable to the problem you reported with the XHCI driver.

However... so far, in every case where someone has reported this failure when updating from 5.0.4 to 5.0.5 on an XHCI-only machine, they had failed to create a NEW copy of the flash drive and instead copied the 5.0.5 ISO to their existing 5.0.4 flash drive. This can not work because only the 5.0.5 flash drive has the new XHCI driver that you need.

Now, I know you said you used both 'aosboot.cmd' and 'dfsanos2' to create the drive (both do the same thing), but please check/double-check/retry/whatever just to confirm that the flash drive and the ISO are a matched set so we can rule that out. If that proves not to be the problem, then we can use an "undocumented feature" to diagnose this a bit further.

Multimedia / Re: Use of webcam
« on: June 07, 2020, 10:23:12 pm »
I cannot access the very same webcam from 2 different programs at the same time. So in that cause audio has to come from another source i.e. the multimedia subsystem via dart. Without webcam audio support in usbaudio.sys  it will have to be one of the multimedia devices attached to the system. When usbaudio.sys would be modified to recognize the microphone in the webcam then it becomes a problem when one is using an usb audio stick at the same time. Perhaps a difficult problem to solve. So for now I will try and write that filter program first.

I don't think you're looking at this properly because you have everything you'd need (except the code) to serve both audio and video.

Because you're using usbresmg/usbcalls, your program isn't just a server: it's also a device driver running at Ring 3. You own the device and can do with it as you wish. If it provides both audio and video interfaces, there's nothing stopping you from setting up simultaneous isochronous streams from each. Just as (I assume) you package a series of USB packet payloads into an MPEG frame, you'd do the same for the audio in the appropriate format.

What you do with the streams after you capture them is up to you...

IIUC, the "pre-boot environment" (the thing that puts up the initial menus) should detect that you're using VBox and set up the the installer accordingly. Perhaps that isn't working as expected for your VBox installation (my hard drive update went well).

Try again. This time on the 2nd menu, choose "Boot with menu for own values". On the 2nd page, it should show that the system type is a virtual machine. You can try changing this to see if you get better results. (Given that it hangs on 'Updating installed system components', this seems like the most likely W-A-G.)

BTW... this is VBox 6.x on Win?

I'm testing this now instead of the script and will report the result.

Hmmm... You may have misunderstood: this disables deletion of the Desktop FolderPos entry. Unless you're running WarpCenter or Styler Shutdown, you do not want to use this option.

I suspect IFX running during boot has reinstated this behaviour.
Any thoughts on this "moving/creeping/downward sliding Desktop icons" problem variant?

Quick Fix: on the IFX commandline in 'config.sys', add '/i' - e.g. "CALL=C:\SYS\APPS\IFX\IFX.EXE /i"

Underlying Cause: the problem arises when the WPS crashes on a system that has XCenter's "Reduce Desktop workarea" option enabled. Unlike a normal shutdown, XCenter doesn't get a chance to restore the Desktop to its original size. Later, when the WPS sees its size is not the default value, it generates a FolderPos entry for it with the reduced size. At the next startup, the Desktop gets configured with the wrong height, then has its size reduced further by XCenter yielding icon creep.

On a system that uses XWP Shutdown (rather than Styler's shutdown) and doesn't use WarpCenter, IFX's fix is precisely what's needed: remove a FolderPos entry that shouldn't exist and causes the problem. This is exactly the same as what Andreas's script does.

Problems arise with this solution when using Styler shutdown, WarpCenter, and possibly other addons. In these cases, that FolderPos is needed to restore things properly, so IFX's fix is no fix at all. The '/I' (letter "eye") switch turns it off.

FWIW... I spent a lot of time researching this but I wouldn't claim to have uncovered every last detail - plus it's been a while so my memory is a bit fuzzy. Still, I'm pretty sure that the IFX fix is the appropriate one for most ArcaOS installations.

FWIW2... I never see this problem for two reasons: (1) I don't use "Reduce Desktop workarea". Instead, I use XWP's screen borders feature to open/surface XCenter whenever I move the mouse to the bottom right corner of the screen; (2) I use "Always maintain sort order" for the Desktop (I have other things to do than artfully arrange the 51 icons currently on my Desktop).

Applications / Re: DOSBox Issue - STDCPP6?
« on: May 27, 2020, 07:46:31 am »
The problem is the extra commands not in dosbox.conf that then happen ie mounting the selected drive or folder as C:\>

If you don't want the WPS to pass the name of the directory whose menu you used, put a percent sign (%) in the 'Parameters' field of the relevant program object.

Multimedia / Re: Use of webcam
« on: May 27, 2020, 05:10:03 am »
As for Arca Noae's more recent drivers, my guess is they're mostly focusing on getting USB3 working and once that's done, they'll fix USBCALLS and such.

What exactly needs fixing in USBCALLS or anywhere else? Just because someone mentioned it in passing as a possible cause doesn't make it so. In fact, I went through AN's Mantis bugtracker and found remarkably few open USB tickets - and most of those pertained to USB3.

In my search, I did find one comment from David A (the USB developer) that's relevant here. He said that he uses a "046D:0804" as part of his QA testing and that it works "just fine". I wouldn't have known what device that was if it weren't the very first one on Wim's "USB Webcam Tests" page: a Logitech C250 Webcam.

So, at this point we know that one program is able to establish an isochronous connection with a common webcam using v12.04/12.05 while another isn't. Until someone files a ticket with AN and/or Wim cares to look into this, that's _all_ we know. IMO, it's way too early to play the blame game.

Multimedia / Re: Use of webcam
« on: May 25, 2020, 07:52:36 pm »
It worked with 11.17. It worked and still works with my USB driver stack. It fails with 12.05. Therefore, it confirms EVERYTHING. If AN did change the programming interface to USBCALLS/USBRESMG either accidentally or deliberately or if it is a bug accidentally introduced, then it is up to them to fix it.

This binary "I'm right, you're wrong" mentality gets in the way of developing a more sophisticated understanding of software malfunctions. Often the issue is not a bug, per se, but a difference in implementation. Two examples (not necessarily specific to USBCALLS, etc):

* The client calls a function that takes several arguments but one of the arguments it supplies is invalid. Implementation A identifies the invalid argument but recognizes that it has no effect in the current context, so ignores it and proceeds. In contrast, when Implementation B sees the invalid argument, it returns an error code.

* A public function calls an internal function to read the hardware; that function returns a value that is outside the expected range. Implementation A simply passes the value to the client, expecting it to deal with potentially invalid results. Implementation B examines the value, sees it's out of range and returns an error.

In the first example, the client code is clearly to blame: there's no reason to expect any called code to accept an invalid argument. In the second example, who to "blame" is less clear - this could simply come down to two different interpretations of the specifications/RFC.

Until we know what is happening at the point of failure, we have no way of knowing which implementation is in error - if any.

Applications / Re: XWP v1.0.13 GA
« on: May 23, 2020, 07:52:08 pm »
is it recommended unistalling the existing previous version before installing this last one?

Install the new version on top of the existing one. There is no need to uninstall anything.

Multimedia / Re: Use of webcam
« on: May 23, 2020, 12:35:56 pm »
When will (32-bit) ArcaOS Drivers support isochronous transfers ?

Isochronous transfers are fully supported for USB2 and have been for a while. I have no problems using Lars' USB Audio drivers with the AN stack.

I think someone's confusing the issue with USB3 where (IIUC) it is still under development.

Applications / Re: XWP v1.0.13 GA
« on: May 23, 2020, 10:17:04 am »
When I position the mouse cursor over a Program Object and click once the
Folder Status Bar shows the filename (slightly) incorrectly by inserting a space
between the last character of the .exe extension and the surrounding quotes.
Is this a known bug/design feature?

This is an artefact of the way XWP formats the string, replacing placeholder characters with actual data.

The formating string for program objects contains "$p $P" where $p is the exe name and $P are the parameters. Replacing $p, you get "program.exe $P". Replacing $P, you get _either_ "program.exe parameter" if there is a parameter _or_ "program.exe " if there isn't one.

IOW, that space you're seeing is simply the space between the $p and $P. I'll see if I can clean this up...

Programming / Re: A clock in WPS - Educational Project
« on: May 19, 2020, 07:16:30 pm »
Martin, add the following to your environment before compiling. They set default commandline options and directories:

(this last line assumes you also have a "SET TOOLKIT=<path>" in the environment)

When compiling, use:  "sc -r -S128000 -C128000 <file>"

One other thing... since this project isn't associated with XWP, it would be better to use a different prefix for its files and classes. Perhaps "MIClock" would be more appropriate (especially in Spanish).

Pages: [1] 2 3 ... 9