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 - Lars

Pages: [1] 2 3 ... 73
Applications / Re: Java applications
« on: March 19, 2023, 04:33:34 pm »

Hit the "App Download" button and you will be able to download the .ZIP file.

You always have to be careful about interpreting error codes as OS/2 can be ambigious about what exactly an error code means.
The help text displayed by help sysXXXX can consequently also be ambigious.

Error 39 = ERROR_HANDLE_DISK_FULL : "disk is full"
Error 21 = ERROR_NOT_READY: "drive not ready"

I don't know why "help sys39" returns such a misleading error explanation. There must be some OS component that, for one reason or the other, returns error ERROR_HANDLE_DISK_FULL.

Utilities / Re: DUMPFS setup
« on: March 06, 2023, 03:08:27 pm »
Yes, that makes sense. If NVMe controllers no longer offer legacy BIOS support, then they will also not hook into the real mode BIOS hard disk interrupt (int 13h) to offer their service to read and write disk sectors (on the disks that they support).

But the initial boot process is entirely done by that legacy BIOS support until eventually the OS will tell the ADD drivers (be it DANIS506.ADD or OS2AHCI.ADD or OS2NVME.ADD) that they can take over and reprogram the HW to their liking.

And as you say: CSM is equivalent to saying "legacy BIOS".

Utilities / Re: DUMPFS setup
« on: March 06, 2023, 07:56:45 am »
... and on third thought, maybe most or all NVMe manufacturers finally decided to drop legacy BIOS support for their controllers (maybe that is what AN means when they are saying: dumping to NVMe managed disk only works sometimes). In that case, there is nothing that can be done or to write an OS2DUMP module that uses UEFI functionality to perform this job.

Utilities / Re: DUMPFS setup
« on: March 06, 2023, 07:46:17 am »
OK, thanks Dave and Lars... I was afraid it might be the NVMe drive. If ArcaOS 5.1 is ever actually released I was planning on running exclusively on NVMe, so guess I should try to set up with a RAM drive.

  Do either of you know if this is something that could be added to the NVMe driver, or is it a kernel limitation? I could raise an issue at the Arca bug tracker...


On second thought, I think that the OS2DUMP that comes with DUMPFS is a real mode executable that uses the good old BIOS calls to write to the disk (it effectively copies contiguous memory pages to contiguous disk sectors, 8 disk sectors per memory page). I cannot see how a disk driver would be involved in this. I don't know if the OS2DUMP that comes with ArcaOS is any smarter and does a better job in finding the partition to write to.

Utilities / Re: DUMPFS setup
« on: March 05, 2023, 03:52:58 pm »
As an additional check just in case something went wrong: the OS2DUMP module in the root dir should have size 10525 bytes. That's the specialized OS2DUMP that it needs for DUMPFS.IFS to work.

I also checked the ability of my system to create a dump  (Os4Krnl, OS4Dump)

Dumping is ok  but  I cannot delete dump file  -  fc/2 said:
Code: [Select]
║ Disk write protected, cannot write ║
║          Q:\DUMPDATA.001           ║
║  [ Retry ]  [ Skip ]  [ Cancel ]   ║

but it seems to me that the deletion worked on earlier versions of dumpfs.ifs

I doubt that it worked before. In any case, deletion does not work but of course, copying does (from but even to the dump partition!)
Deletion does not really make sense as a subsequent dump will just completely overwrite the existing dump (without the need to reformat the partition).

Utilities / Re: HPFS386.IFS
« on: March 05, 2023, 01:06:37 pm »
I am not sure but I think that HPFS386.IFS does not go together with the EARLYMEMINIT keyword in config.sys.
But if you remove that keyword, the rest of the system might run into boot problems...

Utilities / Re: DUMPFS setup
« on: March 05, 2023, 12:56:49 pm »
If the trap dump setup was properly followed (need to update config.sys manually with the TRAPDUMP keyword installer does not do that) and it still does not work, then I would go with Dave's comment:
need to move the partition to an AHCI or PATA managed Disk (or a RAM disk if you use latest ArcaOS).
As an additional check just in case something went wrong: the OS2DUMP module in the root dir should have size 10525 bytes. That's the specialized OS2DUMP that it needs for DUMPFS.IFS to work.

If you use a RAM disk, you will need need to format the partition on each system start (via startup batch file). In that case, also do not forget to first format to JFS and then to DUMPFS (as you had been doing manually).

Programming / Re: Qt6 Development
« on: March 01, 2023, 08:37:19 am »
What's more, there is a systemwide 260 character limit (CCHMAXPATH) on any file path.

   * CCHMAXPATH is the maximum fully qualified path name length including  *
   * the drive letter, colon, backslashes and terminating NULL.            *
   #define CCHMAXPATH         260

Storage / Re: LVM stopped working
« on: February 10, 2023, 09:29:47 am »
Move back to the latest 6.1.x Version of Virtualbox.

Version 7.0.6 does odd things. I can still start my eComStation installation but not my ArcaOS 5.0.6 installation. It will trap early with a "SYS2027" error ("Insert a system diskette and restart the system").

EDIT: I can also say that 6.1.42 does not work. The last one that worked ok was 6.1.40. What I could observe is that with 6.1.40, I can attach my (bootable) ArcaOS virtual hard drive as a 3. hard disk to my eComStation installation and it would boot from the eCS virtual (1st) hard drive and I could then run a chkdsk on the ArcaOS partition.

With 6.1.42, it would instead attempt to boot from the (broken) 3rd hard drive (ArcaOS) and of course, fail on that.

Now after reverting to VirtualBox 6.1.40, my ArcaOS partition is unfortunately broken to the extent that chkdsk will no longer do:

[e:\]chkdsk e: /F
The current hard disk drive is: E:
The type of file system for the disk is JFS.
The JFS file system program has been started.
JFS0068: CHKDSK  Superblock is corrupt and cannot be repaired becaus
primary and secondary copies are corrupt.  CHKDSK CANNOT CONTINUE.

There must be some change from 6.1.40 to 6.1.42 and likely also to 7.0.6 that led to a change in disk ordering on boot.

General Discussion / Re: ArcaOS on Youtube @MichaelMJD
« on: February 01, 2023, 02:32:29 pm »
Just a speculation:

Is there a connection between the blocking of the video and the failure of the 2rosenthals website? By the way it is still marked as an infected site by Bitdefender.

Perhaps the video generated so much traffic on the ArcaNoae site that the servers went down because of this and the video may have been taken off the market for the time being.

Or one of the old Windows evangelists has noticed and doesn't want a new OS/2.

All speculation. The only onces able to tell what is really going on are at Arca Noae.

I can access:
without a problem. Your problem seems to be Bitdefender specific.

General Discussion / Re: ArcaOS on Youtube @MichaelMJD
« on: February 01, 2023, 12:26:50 am »
Read through this and you know why:,3251.msg37902.html#msg37902

They don't have any guts to take a stand against criticism.

Programming / Re: Qt6 Development
« on: January 31, 2023, 07:18:21 am »
But does the change go against QScreen or against QPlatformscreen?
I have to admit that I got lost. They are inventing 2 different functions "logicalBaseDPI" and "logicalDPI" that return the exact same value (and sorry, yes, that seemingly changed from QT5 to QT6) and then they introduce them in two different classes. It's also unclear what is now physical and what is virtual. How could you compute a physical DPI value without the ability to query the screen size as physical horizontal and vertical lengths?

Programming / Re: Qt6 Development
« on: January 30, 2023, 12:48:03 pm »
Font scaling should be fixed with - new qos2.dll link is in the testing thread.

I got lucky with browsing github during my lunch break today, and found - searching for references to this led me to a commit which added logicalBaseDPI on other platforms - and voila ;) seems logicalBaseDPI defaulted to 96,96 is not set - which was different to the screen/font dpi of 120,120 - so windows got scaled (which we didn't wnat/need).

I don't get your explanation. From what I can see, QPlatformScreen::logicalDpi is not properly implemented in your github repo. It just returns QPlatfromScreen::logicalBaseDpi and therefore a 1:1 scaling between "logical" and "physical" for x and also y coordinates.
The BWW repo has an implementation for QPlatformScreen::logicalDpi that is more complex and will lead to a different scaling, at least under certain conditions.
Additionally: Looks like you can fumble around with environment var: QT_FONT_DPI to set your logical DPI. Maybe you can try "set QT_FONT_DPI=120" and see if that makes a difference. At least you can experiment with it ...

And I think it seconds what Alex said: QScreen:: is about Windows scaling and QPlatformScreen:: seems to center around font scaling, at least according to the comments in file qplatformscreen.cpp, at least the BWW repo has this:

Code: [Select]
    Reimplement this function in subclass to return the logical horizontal
    and vertical dots per inch metrics of the screen.
    The logical dots per inch metrics are used by QFont to convert point sizes
    to pixel sizes.
    The default implementation uses the screen pixel size and physical size to
    compute the metrics.
    \sa physicalSize
QDpi QPlatformScreen::logicalDpi() const
    QSizeF ps = physicalSize();
    QSize s = geometry().size();

    if (qFuzzyIsNull(ps.width()) || qFuzzyIsNull(ps.height()))
        return QDpi(96, 96);
    return QDpi(25.4 * s.width() / ps.width(),
                25.4 * s.height() / ps.height());

Hardware / Re: USB32 USBMSD problem of re-read diskette
« on: January 24, 2023, 05:30:09 pm »
By now, I don't think it is a timing problem in the driver. It is a problem of not testing for an inserted media long enough for the drive to react. The number of retries is too low and/or the check for inserted media is not done at all places required plus the returned error info ("sense code") is not properly taken into account (the "sense code" will for example tell you if the drive is not ready, does not contain media or if the media has just been swapped and whole bunch of other potential error/status conditions). Then, for a USB floppy drive, you need some special handling regarding the fact media might not be inserted (for a USB memory stick, the "media" is always "inserted"). That is what you observed: to try and access the media when there is no media inserted will lead to that typical "rattling sound" and Windows does the same.

What I did in the past was to install "Wireshark" under Windows which contains an additional "USB capture" feature (USBpcap).
That is what I used to track what commands in what sequence Windows issues against the USB floppy drive (by using it under Windows). I then modified USBMSD.ADD to follow that sequence (as good as that was feasible), including some guesswork about necessary retries.

And regarding that it works on one system while it does not on another system: the USB floppy drive HW has some physical variation even if it is the very same model (but a different physical drive !) and that can lead to one drive needing more retries than another drive (for example). This has to be anticipated and taken into account. You just cannot test against each and every USB floppy drive on planet earth.

Pages: [1] 2 3 ... 73