Author Topic: OS/4 kernel and extended KEE  (Read 99638 times)

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #60 on: January 08, 2014, 05:05:58 pm »
Quote
But pwroff - is a batch file,

AH! that's where I found it.

Pretty complicated batch file.  :)

On the T510 (it apparently does have APM support), POWER OFF reply y, does power the machine off. PWROFF pops up the Yes No window, I reply Yes nothing happens. If I reply No it powers off.

It looks like I misinterpreted the selection, or the logic is wrong somehow. I would suggest that the least destructive option (NO, don't power off, in this case) should be the default. The button highlight is confusing too. I assumed that white would be the selection, while it appears that yellow is the selection. Perhaps, gray would be a better color for the unselected button.

I will try the L530 later, using reverse logic.   ;D

You should now realize, that I am getting bored trying to find faults. QSINIT works great.   :)

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #61 on: January 08, 2014, 05:55:25 pm »
Quote
I will try the L530 later, using reverse logic.

That was the problem. The L530 responds to pwroff yes with a red window, indicating no APM installed (as expected).

Simply pressing the power button powers it off anyway, on both machines.

walking_x

  • Full Member
  • ***
  • Posts: 101
  • Karma: +0/-0
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #62 on: January 08, 2014, 06:31:28 pm »
You should now realize, that I am getting bored trying to find faults. QSINIT works great.   :)
;) But I found the one - HPFS formatted ram disk return "general read error" from time to time....
It looks like FAT & JFS have no such problem.
Not so easy to fix, but will try.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #63 on: January 08, 2014, 07:40:29 pm »
Quote
;) But I found the one - HPFS formatted ram disk return "general read error" from time to time....
It looks like FAT & JFS have no such problem.
Not so easy to fix, but will try.

I haven't tried HPFS, because I no longer use it. However, it should work, because others still use HPFS. I will prepare one of my systems to use HPFS on the RAMDISK.

I have now installed another memory stick in my main machine (for 4 GB total), and I have installed QSINIT, including the RAMDISK (using JFS). So far (a few minutes), no problems.   :)

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #64 on: January 08, 2014, 11:01:53 pm »
Quote
;) But I found the one - HPFS formatted ram disk return "general read error" from time to time....
It looks like FAT & JFS have no such problem.
Not so easy to fix, but will try.

Interesting. If I try copying a directory, with a long file name, to HPFS, using the WPS drives object, it is translating long file names to short (8.3) file names (use DIR at the command line to see it). JFS is doing the same, and FAT is expected to do that.

If I try to copy the directory to FAT16, it fails. The error message is that the path cannot be found. I expect that it is trying to copy a file to the long directory name, which has been shortened.

Okay. If I do the copy to HPFS, using the command line, I do get long file names, BUT, the WPS Drives object does not show the directories that have long file names.

When I look at the RAMDISK, with JFS on it, using DFSEE, it doesn't recognize what is on the RAMDISK. It says it is all freespace. With HPFS, and FAT16, DFSEE sees that it is HPFS or FAT16.

Okay, so I used DFSEE to remove the partition, and make a new one for HPFS. Then, I formatted it as HPFS. Now, DFSEE show the drive as all free space, but it still has the same problem (using 8.3 file names).

I have NO IDEA how any of that could happen, or what can be done about it. I think that JFS would have the same problem that you saw, under the right circumstances.

WOW! is the RAMDISK ever fast! When I copy a directory from hard disk to it, it takes about 10 seconds. When I copy that same directory from the RAMDISK to the RAMDISK, it takes about 1 second.

walking_x

  • Full Member
  • ***
  • Posts: 101
  • Karma: +0/-0
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #65 on: January 09, 2014, 09:20:49 pm »
You can try it now, looks much better ;)
At least, without "general read error".

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #66 on: January 09, 2014, 11:34:18 pm »
You can try it now, looks much better ;)
At least, without "general read error".
I never saw a read error. I did see "file, or directory, not found" errors.

I am still puzzled that the WPS and the command line, can't agree on whether the disk can handle long file names, or not. JFS seems to handle it okay, while HPFS does not. FAT, of course, does not handle long file names at the command line.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #67 on: January 10, 2014, 06:00:05 am »
Quote
I am still puzzled that the WPS and the command line, can't agree on whether the disk can handle long file names, or not. JFS seems to handle it okay, while HPFS does not. FAT, of course, does not handle long file names at the command line.

This seems to be a serious problem. JFS and HPFS cannot be used reliably, because real directory/file names don't match the expected long names, when the WPS is doing things with them. The really strange part is that the command line does use long names, but then the WPS cannot "see" them. Something is not being set properly, somewhere.

I also note that FAT only works with short file names (as expected, although the WPS sees long file names, because of the EA support), but that severely restricts what it can be used for. I haven't seen any problem using it for the %TEMP% directory, but that could be pure luck. I expect that most (if not all) temporary file names would be 8.3.

Another "problem". I decided to try making the disk with no format, or partition (RAMDISK R: NOPT NOFMT) The disk is not visible to OS/2, although DFSEE sees it as a Large Floppy Format (it is about 895 MB). I can use DFSEE to make a partition, and give it the drive letter, but then I would need to reboot to make it active.  :(  Using just NOFMT lets me format it as JFS, but it still has the file name problem.

I would note, that DFSEE aligned the partition completely different from what the RAMDISK default is. That might have something to do with it.

walking_x

  • Full Member
  • ***
  • Posts: 101
  • Karma: +0/-0
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #68 on: January 10, 2014, 07:38:02 am »
I am still puzzled that the WPS and the command line, can't agree on whether the disk can handle long file names, or not. JFS seems to handle it okay, while HPFS does not. FAT, of course, does not handle long file names at the command line.
This is WPS-related problem only ;) It remembers "partition type" on first start and unfortunately - "unformatted" looks like FAT too ;)
I'm just insert FORMAT command into MPTSTART.CMD (config.sys calls it before PM) - and problem disappeared :) I.e. disk must be formatted to filesystem with long names before PMSHELL - to use WPS copy on it.

Quote
I haven't seen any problem using it for the %TEMP% directory, but that could be pure luck. I expect that most (if not all) temporary file names would be 8.3.
No, any software, except WPS - will create files normally.

Quote
Another "problem". I decided to try making the disk with no format, or partition (RAMDISK R: NOPT NOFMT) The disk is not visible to OS/2, although DFSEE sees it as a Large Floppy Format (it is about 895 MB). I can use DFSEE to make a partition, and give it the drive letter, but then I would need to reboot to make it active.  :(  Using just NOFMT lets me format it as JFS, but it still has the file name problem.
Yes, unformatted disk looks like FAT and WPS "remember" this. You can create it in eCS's  MiniLVM and format - no reboot required and WPS will be happy, because found this disk at first time with HPFS.

Quote
I would note, that DFSEE aligned the partition completely different from what the RAMDISK default is. That might have something to do with it.
Partition(s) is cylinder-aligned, so even old LVM.EXE likes ram disk format ;)

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #69 on: January 10, 2014, 07:48:03 pm »
Quote
I'm just insert FORMAT command into MPTSTART.CMD (config.sys calls it before PM) - and problem disappeared

This is difficult to explain...

It didn't change anything, for me. I tried running the format 4 different ways (including in MPTSTART.CMD). All of them had it done before the WPS was started, and I saw no change in the way it is working. HPFS and JFS seem to work the same.

If I format as JFS, or HPFS, the drive icon appears normal, The Properties show it as JFS, or HPFS. When I use the WPS to copy a file, with a long file name, to the RAMDISK, the file name shows as the correct long file name, in the WPS. However, if I then go to the command line, and do a DIR on the drive, the file name has been shortened. I can then use the command line to copy that same file, and the long file name shows when I do a DIR, and the WPS shows the long file name.

The problem arises, when I use the WPS to copy a directory to the RAMDISK. The directory name gets shortened. That seems to be okay with JFS, because the WPS still sees it as the long file name. With HPFS, on the other hand, I still see the long file name with a DIR, BUT, the WPS doesn't see it at all.

Quote
You can create it in eCS's  MiniLVM and format - no reboot required and WPS will be happy, because found this disk at first time with HPFS.

Well, no you can't. MiniLVM indicates that the drive letter has changed to what I want, but the change is not recognized until I reboot. Of course, reboot destroys whatever was done. If I start with the drive letter already assigned, I can create a new partition, and format it (HPFS, or JFS), but nothing changes. the problem is still there.

Quote
Partition(s) is cylinder-aligned, so even old LVM.EXE likes ram disk format

Well, yes, it doesn't complain.

I think this might work better, if the drive was marked as a removable drive.

walking_x

  • Full Member
  • ***
  • Posts: 101
  • Karma: +0/-0
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #70 on: January 11, 2014, 07:47:50 am »
I know the difference. I'm using File Commander for everything, but you using WPS.

So, after you created this partition (on empty ram disk, made with NOPT key) in MiniLVM - you format it in WPS! And WPS on first use of unformatted disk - remember its "FAT" state.

When I tried the same - I call format in File Commander's command line - and then use in WPS first time.

And - tried to format it from \MPTN\BIN\MPTSTART.CMD - both on Aurora and eCS 2.0 rc 6 - disk is ready before WPS - and long names works fine (in WPS copy).

The solution, may be, just implement HPFS format in QSINIT, but this is a long story ;)
« Last Edit: January 11, 2014, 08:10:42 am by walking_x »

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #71 on: January 11, 2014, 05:25:29 pm »
Quote
So, after you created this partition (on empty ram disk, made with NOPT key) in MiniLVM - you format it in WPS! And WPS on first use of unformatted disk - remember its "FAT" state.

No, that doesn't work, at all. The disk is never visible to OS/2. I think that is because there is no partition, therefore no LVM information, therefore, no disk. If I create the partition with QSINIT, I can format it, but the problem persists.

Quote
And - tried to format it from \MPTN\BIN\MPTSTART.CMD - both on Aurora and eCS 2.0 rc 6 - disk is ready before WPS - and long names works fine (in WPS copy).

Long names do work fine, in WPS copy, but when you use the command line the long names have been changed to short names. That is expected, and seems to work okay, for most things, with FAT, but it does not work properly with HPFS, or JFS. In addition, if you use the command line to copy a long file name to the RAMDISK, using HPFS, the command line shows the file, but WPS never sees it. For some reason, JFS is able to handle that situation, and it can see the long file name, when copied by the command line.

I need to do more work with this. Something is missing, somewhere.

Is there a way to force QSINIT to create a FAT32 drive, when using only about 500 meg of memory?

Quote
I know the difference. I'm using File Commander for everything, but you using WPS.

I am not sure if FC uses the WPS, or the command line support (probably the command line). If you only use that, you will never see the problem, but the system will, and some things do not work properly because of it.

walking_x

  • Full Member
  • ***
  • Posts: 101
  • Karma: +0/-0
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #72 on: January 11, 2014, 07:35:51 pm »
Long names do work fine, in WPS copy, but when you use the command line the long names have been changed to short names.
Just try it again ;)

If MPTSTART.CMD called from config.sys - it works.
Here one shot with such HPFS disk: WPS, command line and FC windows.

Quote
Is there a way to force QSINIT to create a FAT32 drive, when using only about 500 meg of memory?
You can format it with small cluster size, for example:
    format c: /a:4096 /f:1 /q
just after ramdisk command.

But I'm not sure about FAT32.IFS - it can deny FAT32 partition formatting.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #73 on: January 11, 2014, 08:27:58 pm »
Okay, I found another problem with the RAMDISK. I decided to see if I could force it to use FAT32, so I did:
Code: [Select]
RAMDISK min=2200 R:While in the QSINIT shell, it said it did it. When I boot OS/2, it hesitates for a second, or so, and reboots.

Quote
I need to do more work with this. Something is missing, somewhere.

Yes. I was able to reproduce the problem using a real disk. It is not the WPS that is doing it wrong. The drive must be in the proper format when OS/2 is booted (probably when the IFS is loaded).

I formatted a real partition as FAT, and it failed to work properly (it was JFS previously). I got errors when trying to copy a file, with a LFN to it. I then rebooted, and it worked as expected. Okay, so I formatted it to JFS, and it did exactly what the RAMDISK does. Reboot, and now it works properly.

It seems that you will have to create the proper format in QSINIT, to make it work properly, or make the drive removable, so it can be remounted, after formatting (not too sure how that will work, since it cannot be physically removed).

Unfortunately, FAT format is restricted to using short file names, even if the WPS can use long file names. That makes it of very limited use, and it won't work properly for the %TEMP% directory, unless every program happens to use short file names for the temporary files (which is, apparently, not the case). HPFS has serious problems. JFS, on the other hand, seems to handle the situation, and it does work, for most things, but very odd errors will pop up every once in a while when the WPS stores files with short file names. Hmmm. I wonder if that has something to do with the larger cache that JFS has. If the file is still in the cache, it might be retrieved with the LFN, while the file system has put the file on disk with the short name. I hate to think what that might do.   :'(

You say that FAT can be used for the swap file. I don't doubt that, but a swap file is only used with small memory configurations, which would rarely be the case when using QSINIT. There are very few other things that a FAT RAMDISK might be good for.

I would note, that HPFS is probably required for those who do not have bootable JFS. I don't have the old IBM JFS any more, so I don't know what might happen with that. The new bootable JFS works best, but can have problems because the WPS will write short file names, when it shouldn't, and the underlying support doesn't know that it should have a long file name.

FAT32 might actually work better, because the IFS is loaded later, and it already has LFN support. I doubt if it could be used for the swap file, but it might be usable for %TEMP%. Since it already has LFN support, at boot time, changing the format might work better.

Quote
If MPTSTART.CMD called from config.sys - it works.
Here one shot with such HPFS disk: WPS, command line and FC windows.

It does NOT work. A reboot, with the proper disk format, is required for the IFS to recognize that it can use LFN for the file names (and directories). You may also be seeing the cache, not the hard disk.

Quote
You can format it with small cluster size, for example:
    format c: /a:4096 /f:1 /q
just after ramdisk command.

Hmmm. That lets it boot, but the disk does not finish formatting to JFS, and the system hangs. The disk is 895 meg, on the system where I am testing. I will try without the format to JFS step. Yes, that seems to work, the FAT32 drive appears to work properly. Now, to try a format to JFS. No, that doesn't work. It is probably some sort of restriction in the FAT32 driver. I will need to experiment with using FAT32 for the %TEMP% directory.

I will need to find more time later...

walking_x

  • Full Member
  • ***
  • Posts: 101
  • Karma: +0/-0
    • View Profile
Re: OS/4 kernel and extended KEE
« Reply #74 on: January 12, 2014, 10:31:02 am »
Code: [Select]
RAMDISK min=2200 R:While in the QSINIT shell, it said it did it. When I boot OS/2, it hesitates for a second, or so, and reboots.
This is kernel bug, in memory init....
I cover it in some cases - i.e. when OS/4 loader reboots, QSINIT works...
But bug still there.

You can send me log in following way:
Code: [Select]
  ramdisk min=2200 r:
  bootos2 os2krnl test
  ramdisk delete
  ramdisk min=500 r:
  log save c:\log.txt

Quote
It does NOT work. A reboot, with the proper disk format, is required for the IFS to recognize that it can use LFN for the file names (and directories). You may also be seeing the cache, not the hard disk.
And how was made screenshot above? ;)

The .LONGNAME EA usage and such ugly name conversion - is WPS-related thing only. So, if you  format partition before WPS - it works normally with it - because it detects it as "long-name-file-system" at the own startup.

I.e. I made 1200mb fat, format it to HPFS in MPTSTART.CMD and then, in PM - made a copy of some files via WPS.