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 - Valery Sedletski

Pages: 1 ... 18 19 [20] 21 22 ... 25
286
Hardware / Re: Limitation on using an USB DVD and CD writer under ArcaOS
« on: February 12, 2018, 10:42:39 pm »
2David Graser:

Quote
Given a choice between the newer version or the earlier version, at this moment I have go with the earlier version.  I want USB writer capability.

USB writers work with Froloff's cdrecord and OS2CDROM.DMD 10.163 on my machine. Did not tried CD/DVD Toys with it, though. I use CDRECORD directly from command line.

Quote
Can Froloff's driver be disassembled to possibly see what he added or changed?

I don't know. If someone has time and skills -- maybe.

2 Dave Yeo:

Quote
Cdrecord-ProDVD-ProBD 3.01 (i386-pc-os2-gnu) Copyright (C) 1995-2015 Joerg Schilling

Where did you took 3.01? Is this available from ArcaNoae repositories only? Access to non-arca users is closed?

287
Hardware / Re: Limitation on using an USB DVD and CD writer under ArcaOS
« on: February 12, 2018, 08:16:44 pm »
2ivan: SCSI descriptors like [bus,]id[,lun] helpful only for SCSI/ATAPI CD writers. They work via DaniS (or DaniATAPI? -- don't remember). For USB CD writers, you'll need OS2CDROM.DMD which works via drive letters, only. Interesting, does OS2AHCI supply a SCSI emulation, like DaniS does? So, SATA-atached writers will work too? Or, how else would SATA writers work? (I don't know as I haven't SATA CD writers)

288
Hardware / Re: Limitation on using an USB DVD and CD writer under ArcaOS
« on: February 12, 2018, 08:03:12 pm »
2Andreas Kohl: I don't know what is undocumented in OS/2 version of cdrtools. It works the same as UNIX versions. AFAIK, it uses libscg too (It wrote a string like "Unofficial libscg transport ..." to the screen when writing CD's) .

Quote
As long HBA support for OS/2 is existing there should not too much problems. That should set the limit to 10 year old workstation hardware in real life btw.

What is HBA?

Quote
 
Quote
    The custom version from Froloff is a bit older that that is offered in UDF package. So, it's better to install the version from UDF.
 

Does it mean that ArcaOS delivered an outdated or incapable version of OS2DASD.DMD?

No, as I checked in my arcaos copy, it has latest OS2CDROM.DMD v. 10.163, the same as supplied with UDF 2.16

2David Graser:
Good that the version from cdrtools 2.01.01.a59 works for you. But v. 10.163 is newer and has more features. Some IOCTL's are missing from Froloff's version. RSJ may not work with it too. And UDF will not work with it, too. Did you checked, which CDRTOOLS version is supplied together with CD/DVD Toys? I'd suspect that this version work well with Froloff's version of OS2CDROM.DMD (because CD/DVD Toys uses Froloff's version of CDRTOOLS), but RSJ needs OS2CDROM.DMD from UDF distribution. This is only a hypothesis. Hm, looking into my version of DVD Toys, I don't see cdrecord in its installation directory. Where does it looks for it, interesting?

Yes, too bad that Nickk/Froloff disappeared both and did not left the sources.

289
Hardware / Re: Limitation on using an USB DVD and CD writer under ArcaOS
« on: February 12, 2018, 04:47:12 pm »
CD/DVD Toys are only a frontend for CDRTools, so you can use CDRECORD directly, so command line mode will be available. So, this is not a problem. No idea why it cannot work for newer machines. It should work the same.

The custom version from Froloff is a bit older that that is offered in UDF package. So, it's better to install the version from UDF.

290
Hardware / Re: Limitation on using an USB DVD and CD writer under ArcaOS
« on: February 12, 2018, 03:02:09 pm »
2David Graser: What is your os2cdrom.dmd version? You need a custom version from Froloff (cdrtools 2.01.01a59, or so), or from latest UDF 2.14-2.16. Older versions of OS2CDROM.DMD may not support ioctl's required to write CD's in packet mode. OS2CDROM.DMD 10.163 works for me.

291
Hardware / Re: Best FAT32 driver settings
« on: February 11, 2018, 10:28:36 am »
2David Graser: Ok, so it looks like the problem was with icons. Indeed, in FC/2, with no GUI, I don't observe any delays or waits to populate the directory.

BTW, I also uploaded new version r333, where I removed OBJ_ANY in DosAllocMem (which prevented CHKDSK to start), so now CHKDSK should work ok.

Also, in last versions (it was in November), I added new cool feature: now fat32.ifs can mount FS images, laying on any other file system. The images can be simple diskette images, RAW harddisk images (partition images, or whole hard disk images), VM images (e.g., VPC images, now readonly, yet). Supported VM image formats are Raw/bochs/cloop/dmg/vpc/vmdk/parallels/vvfat/qcow. I ported the image access library from QEMU, you just use the f32mount.exe utility, to mount them. Now cachef32.exe contains code to read sectors from VM images. The IFS calls cachef32.exe, to read sectors, so that, the code for reading images is run in a usermode process. You can mount images like this:

Quote
f32mount win98.dsk <directory on a FAT drive>

-- this will mount a diskette image, or,

Quote
f32mount win98.vhd dir1 /p:1

-- this will mount a win98.vhd VPC image to dir1 subdirectory, "/p:1" selects a primary partition in this HDD image. Numbers 1-4 specify primary partitions, 5-... specify logical partitions. Also, you can specify an optional header size as "/o:<size>", if your filesystem starts at offset <size> from the beginning of the image. "/p:..." and "/o:..." options can be combined, if you have a header before the partition table. Note that such way, you can mount any FAT12/FTA16/FAT32/exFAT partition image to a subdirectory on another FAT12/FAT16/FAT32/exFAT drive.

Also, (this feature is unfinished and alpha-quality, yet) you can mount an image to a subdirectory, and run CHKDSK/FORMAT against the mountpoint. To specify a mountpoint, you use the following syntax:

Quote
chkdsk d: /m:<path to mountpoint> [/f]

So, d: will be ignored, and <path to mountpoint> will be checked instead. It is done this way, because you cannot pass a directory to chkdsk/format (only a driveletter), so we pass a directory as a separate parameter, instead. And likewise, for format (the same "/m:..." parameter). But I don't recommend to use format on a mountpoint this time, yet, because this feature is not finished, and it can corrupt the image.

Does anybody want to try these features? ;)

292
Hardware / Re: Best FAT32 driver settings
« on: February 10, 2018, 10:52:25 am »
Strange. What filesystem has your disk C: ? It seems, it wrongly assumes this disk being FAT. The message

Quote
FAT32: Error: Sector 7 does not exist on drive C:

means that number of sectors on disk < 7 (usually 0). Also, please, check the newer version fat32.ifs, r332: ftp://osfree.org/upload/fat32/fat32-0.10-r332-os2.zip, I made some additional checks in FS_MOUNT, so it should not wrongly mount other file systems, than FAT/FAT32/exFAT.

PS: No idea, why it is slower on a SMP machine. Maybe, it needs some SMP optimisations, I did none so far. Did not noticed such effects on my SMP machines.

293
Storage / Re: Low level format error with JFS
« on: February 10, 2018, 04:02:21 am »
Disks > 512 GB are officially not supported on eCS / ArcaOS. But unofficially, they work with some tricks. You need to use DFSee to create volumes on them, and assign drive letters. The reason is a non-standard geometry of such drives. DaniS506 and OS2AHCI on drives from 512 GB to 1 TB assign a geometry of 127 sectors per track, and for drives from 1 TB to 2 TB, a geometry of 255 sectors per track, instead of 63 standard sectors per track. Some tools like lvm.exe or IBM Boot manager, or AirBoot, may not like such drives. So, special tricks with DFSee are required. I'm using two 2 TB drives on two machines, successfully, but OS/2 Boot manager or AirBoot don't even boot a boot sector. I use my FreeLDR or _dixie_'s QSINIT instead, as they aren't so picky regarding the disk geometry.

PS: I observed JFS CHKDSK/FORMAT errors with such drives, too. Looks like in your case too.

294
Hardware / Re: Best FAT32 driver settings
« on: February 10, 2018, 03:43:28 am »
2David Graser: hi

I'm using

Quote
ifs=d:\os2\boot\fat32.ifs /cache:2048 /h /ac:* /largefiles /fat /exfat /eas /plus
call=d:\os2\cachef32.exe /f /p:2 /m:50000 /b:250 /d:5000

As far as I can see this is almost the same settings as you have, except for "/fat" for FAT12/FAT16 support, "/exfat" for exFAT support, "/eas" for EAs support, and "/plus" for support of files whose sizes are larger or equal than 4 GB. These are very useful switches, if you don't know. Also, I don't use FM/2, but use FC/2, I have a 1 TB FAT32 USB drive -- it works relatively fast (only needs to spin up first, as it goes to sleep usually). My 128 GB microSDXC card works fast too -- they both reread in a second or so, not 40 seconds, as you report. So, it is probably, specific somehow to FM/2, I'd suppose.

PS: Also, AFAICS, WPS opens these 128 GB and 1 TB drives faster than 40 s. It scans all directory structure for about 10 s (folder view), but just opening an icon view is fast -- 1-2 s. FC/2 does not scan whole directory structure each time, but FM/2 probably, does.

295
Programming / Re: OS/4 & PmDDk.sys
« on: December 23, 2017, 01:15:34 pm »
It works fine on two my machines (one with eCS 2.2 and Panorama video driver, another with MCP2 and SNAP video driver). Tested with both the latest OS/4 kernel and 14.200 kernel from Arca. I see no problems with it so far.

296
Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 28, 2017, 09:44:14 am »
2Andreas Kohl:

> Actually I'm only 1/4 немецкий but 3/4 германский. I don't know how to translate it into English. :D

What's the difference between немецкий and германский? I found them synonymous :)

Quote
I don't want to be confusing. EXPART support for CP simply exchanges the following files:

Code: [Select]
\os2\dll\ENGINE.DLL
\os2\dll\LVM.DLL
\os2\boot\OS2DASD.DMD
\os2\boot\OS2LVM.DMD
\os2\boot\IBM1S506.ADD
\os2\FORMAT.COM
\os2\LVM.EXE
\os2\LVMGUI.CMD
\os2\javaapps\LVMGUI.ZIP
\OS2DUMP
\OS2KRNL

Moveton from #os2russian said that his copy of EXPART package has os2krnl.smp file too. So, no SMP restriction, indeed. His package is, probably, is newer than yours.

> For an end-user or operator it's only interesting that OS2LVM device mapper relies on OS2DASD.

Of course. OS2DASD.DMD/OS2LVM.DMD pair from Aurora-level systems are used together. They could be exchanged to danidasd.dmd or os2dasd.dmd from Merlin, and everything will work. OS2DASD.DMD from Merlin and DANIDASD.DMD are 16-bit drivers. OS2DASD.DMD/OS2LVM.DMD from Aurora are 32-bit ones.

Quote
Quote
If so, it is also possible to assign a 0x7 partition type to an ext2 partition. Linux does not care about partition types, so it would not hurt it. So, we can try testing it.

Sounds sane. Every IFS (ext2, hpfs, jfs) should also use the specified IFS partition id which is 7 (dual 0111). ;)

Ok, I tried to create an ext2fs partition with type 0x7. Without ext2fs partitions, mwdd32.sys/ext2-os2.ifs/ext2_lw.exe are loaded syccessfully and everything boots fine. With an ext2fs partition created, it hangs on pmshell.exe start (or on cntrl.exe start). It looks that it hangs on an attempt to mount a partition (all partitions, except for the OS/2 boot partition, are mounted about this point). So, it tries to mount it, but hangs, for some reason. This needs further investigation.

297
Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 27, 2017, 08:26:24 pm »
2Andreas Kohl:

> I'm aware of the limitations. Fortunately Валерий wrote elaborately about it, so I have nothing to add. Большое спасибо! Oчень эрудированнo.

Danke schoen :) (I know German a bit too :) Studied it at school.)

> There are two different cases on LVM-enabled OS/2 systems. The orignal LVM partition support introduced by WSEB and the later CP1/CP2. It was enhanced in 2002 by the Extended Partition (EXPART) support to address larger hard drives and additional partition IDs (but only for uniprocessor ACP1/ACP2). The MWDD32.SYS based IFS implementations predate these developments. On non-LVM enabled systems the corresponding filter drivers ext2flt.flt or hfs.flt can still be used for recognition.

Expart? Do you mean, partfilt.flt/ext2flt.flt? The second one was created for ext2-os2.ifs. The 1st one was its enhanced version for fat32.ifs, to support additional partition types, by default. They could be added with "/p" switch too. hfsflt.flt is a filter from hfs.ifs (Macintosh HFS file system for OS/2). It has nothing to do with partition types. It is needed for Macintosh floppies. They have no BPB, which is required for OS/2. So, this filter creates a virtual BPB on the fly, which makes OS/2 happy with these floppies. Why only uniprocessor ACP1/ACP2? partfilt.flt has some problems with SMP?

Or expart is something like partfilt.flt/ext2flt.flt, but for LVM systems? AFAIK, for LVM systems, such support is unneeded, because you can create the LVM info for any partition type, and the kernel will call all IFS'es for that partition, and it will be mounted if some IFS will recognize it. Or not all partition types are supported? 0x7/0xb/0xc supported, but Linux 0x83 is not? I am not sure. It is possible, indeed...

If so, it is also possible to assign a 0x7 partition type to an ext2 partition. Linux does not care about partition types, so it would not hurt it. So, we can try testing it.

298
Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 27, 2017, 05:57:58 pm »
2Lars:

Quote
b) In the year 2017 it only makes sense to support systems with LVM. It's too late to make USBMSD.ADD compatible to an OS of the year 1996. There would be too many limitations.

Danidasd.dmd is still quite usable. I use it in my Universal Boot Disk (a Live OS/2 system, capable of booting from ATA or USB CD's/USB flash sticks/USB hard drives/ATA hard drives/etc), to boot from USB sticks or hard drives. LVM is not usable in this case. Also, there are cases where the use of LVM is impossible. For example, I used to update Warp 3 to a newer fixpack at one plant, to allow them to use flash sticks, instead of floppies. The plant has a Warp 3 PC, which controls a glass-cutting bench. The people from that plant contacted me at a freelance site. They were not ready to update software to latest eCS system. So, if USB stack can work on such system, why not? So, it is desirable to support such systems, if we can. In fat32.ifs, I support Warp 3/Merlin systems, because 16-bit IFS should support them. No need to artificially limit it to the latest systems only. Nothing prevents the USB stack to work on such systems, too. And, some people use older systems in VM's. So it is better to support such systems too.

Also, regarding FAT/FAT32 only on big floppies. I think, that nothing prevents USBMSD.ADD to support Big floppies with any file system. Indeed, there can be Big Floppies, created by Linux, with ext2fs, or any other file systems. Nothing prevents me to create the Big Floppy with HPFS/JFS too. Indeed, creating partition table is not hard, but if you have flash sticks from other people, then reformatting/repartitioning is undesirable. The stick could be created by Linux, and not Windows.

As I understand, you check for the FS name field after the BPB, and if it is FAT, then you emulate a zero track with MBR and DLAT. But you can check for three first bytes instead, to be EB XX 90 (a two-byte JMP SHORT instruction, followed by the NOP instruction), and also the valid Partition table at 0x1BE offset, and the valid BPB otherwise. If JMP/NOP and a valid BPB exist, then it is a Large floppy, otherwise it is a PRM. As far as I can see, the valid partition type field is not mandatory. You can use 0x7 in any case. FAT32.IFS will mount the partitions with type 0x7 fine.

> This is also a dead end because with EXFAT Microsoft decided they are going to drop the BPB for good and describe the media layout at another place on the media. Another nail in the coffin of OS/2.

In exFAT, M$ has the BPB being zeroed-out, and it is followed by a new structure, which I call BPB2, which is equivalent to BPB, but has the 64-bit replacements for HiddenSectors and LargeTotalSectors fields. This is to support volumes of sizes larger than 2 TB. Also, for support of big clusters (which could be up to 32 MB), the Byte-sized shift values are used instead of BytesPerSector and SectorsPerCluster fields. Indeed, this does not prevent to mount exFAT partitions under OS/2. FS_MOUNT routine just parses the BPB2 structure, instead of the BPB. The problems could be with HiddenSectors, when booting OS/2 for such partitions. But indeed, this is not a big problem too. QSINIT can emulate the BPB in memory, and pass it to os2ldr, if Booting from exFAT, if you use QSINIT as a boot manager.

299
Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 27, 2017, 05:14:25 pm »
[There has been some discussion about porting the EXT file system to OS/2. I don't know much about that, so I won't comment, but word is that it is much like JFS. I also don't know much about HPFS386, but I suspect that JFS is more than a suitable replacement.

Quote
Ext2 has already been ported to OS/2. Problems include no LVM support and I understand people looked into adding it and failed.

it supports only very old ex2fs version, and does not mount newer ones. Yes, there are some problems with LVM. It works fine with danidasd.dmd. I don't know, where are incompatibilities with LVM. Probably, it is not ext2-os2.ifs itself is incompatible with LVM, but it is mwdd32.sys driver, which it is based on. Need to look at it better. Possibly, we'll just need to update mwdd32.sys.

Quote
No EAs (xttrs), at least back then. Case sensitive file system, seems OS/2 actually upper cases most stuff when writing to a file system. The porter added a switch to make it case insensitive to allow running OS/2 on it, and yes, he wrote the mini and micro filesystems to make it bootable. And it was old, kernel 1.3 IIRC and Linux likes to change things.
I used to format my Linux partitions on OS/2 to have access to the Linux disks.

You need to reformat the filesystem with special switch, changing its revision.

Quote
It would be nice if our JFS was once again compatible with the Linux JFS. Would be nice to port the Linux JFS to OS/2 as it has had more love over the years and supports links, both hard and soft as well as *nix permissions.
According to wiki, JFS is perhaps the best general purpose all around file system for Linux.

Our JFS is compatible with Linux. Linux sees OS/2 JFS partitions fine. And OS/2 can mount Linux JFS partitions, if you format them with -O (case insensitivity) option. OS/2 supports only FS'es, formatted as case-insensitive. Also, it requires BPB to be present in the boot sector. Linux JFS is case sensitive by default, and it has no BPB. But you can format it with the -O option and create the BPB with DFSee. There is Linux JFS ported to OS/2 already. It is OpenJFS project which is available from Netlabs. But Netlabs sources are a bit outdated. There are two versions at Netlabs svn, from 2003 and 2007. The IFS mostly works. The missing part is UJFS.DLL. But it could be created from fcsk/mkfs, which are present. Hard links should work in OS/2, like they do in ext2-os2.ifs. You only need a user mode utility to create them. For soft links, the kernel support is required, which is missing in OS/2. UNIX permissions require kernel support too. But I fear that permissions overlap with some OS/2-specific data in inode structure.

300
Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 27, 2017, 04:21:08 pm »
Quote
Actually the most important problem WAS and IS solved.

The problem exists because the FAT32 support is not properly written (probably not designed properly, in the first place). Some improvements have been made recently, but it is still not a proper file system, therefore it needs some special handling to make it work. No other (supported) file system needs help to make it work with USB.

What do you mean? Not designed properly? Is still not a proper file system? What special handling does it need?

Large floppy support does nothing with FAT32 specifically. As Lars correctly said, the problem is with OS2DASD.DMD, which thinks that Large floppies are FAT, but not IFS case. So, without Lars' workaround in USBMSD.ADD, the OS2DASD.DMD assigns a drive letter to it, and then the kernel calls MOUNT routine of in-kernel FAT driver, not any IFS-es. So, the proper Large Floppy support requires OS2DASD.DMD (and maybe, kernel too) rewrite. It is significantly harder. FAT32.IFS does not require anything special, compared to JFS or HPFS.

Quote
Quote
And I can not recommend to use JFS in conjunction with non-removable USB MSD under OS/2 for production level at the current state.

That is flat out ridiculous. The current JFS is, IMO, the most reliable OS/2 file system to use with any device (removable, or not), that can use it. I find it far more reliable than HPFS ever was, and the performance is a whole level higher (especially with removable media). Personally, I would never use anything else, if there was no need to be compatible with other operating systems.

Having said that, I do use HPFS with the ARcaOS, or QSINIT, RAMDISK.  The reason is that the RAMDISK can be created with HPFS format, and I can turn the cache size down to minimum (64 KB), which helps performance (it would be better if it was zero, but that is not allowed by HPFS).

You can also use the "/1" switch for hd4disk.add, to improve performance. It disables the strat2 routine, which simplifies things in ramdisk case, so it improves performance about 5 times.

Quote
I also use FAT32, to be able to interface with windows, which is still a necessary evil. I do turn off EA support to avoid problems caused because the FAT32 file system, in windows, does not know about them, and it causes nothing but problems, for very little gain.

I don't aware of any problems which are caused by EA support, except for EA files laying around everywhere. But this can be fixed in the future, as I plan to implement the "classic" EA support with "ea data. sf" file. Also, it should be noted that, with EA support, it is possible to store files, bigger than 4 GB, on the FAT32 volume, to transfer them between OS/2 systems. Indeed, support of big files up to 32 GB is possible without EA's, but bigger files require the EA support. The 64-bit file size is stored in three extra bits (previously, the reserved ones) of a directory entry. If it does not fit into 32+3 == 35 bits, the full 64-bit size is stored in the FAT_PLUS_FSZ EA. This feature could be enabled with  "/plus" switch. This feature is called FAT+ and it is suggested by DR-DOS developers. Also, copying files with EA's, including the desktop from the OS/2 boot partition, works fine. I saw no problems with it.

Quote
FAT (12 and 16) still has some limited use, but I try to avoid them, except for special things. The new addition of ExFAT support to the FAT32 driver, is interesting, but I don't know how useful that will be in the long run. I do know that there are serious questions about the legality of doing that, which is the reason why Arca Noae.removes that feature from the FAT32 driver that they distribute.

FAT12/FAT16 have very frequent use -- floppies, flash sticks < 2 GB, some old mp3 players, which could not support FAT32, SADUMP partitions (I also discovered that 4 GB FAT16 partitions, with 64 KB clusters, are supported by FAT os2dump, and it could be read with FAT32.IFS, so, such partitions could be used instead of DUMPFS. Read more in fat32.inf documentation on this topic). Regarding the legality of exFAT support, it is legal. In some countries, like USA, there are software patents. So companies like Arca Noae, should pay licensee fees to M$. Arca does not like this, so they don't want to include exFAT support in their distributions. I made a version without exFAT (#ifdef-ed from sources, but they want sources completely without exFAT. (and without FAT12/FAT16 too, but this is ridiculous, because it hurts nothing, and it is nonsense.) Also, they don't want to sponsor my developments, but want to include new version with FORMAT/autocheck/other features, without paying me, so I'll suspend implementing their wishes, for the time being.). Software patents are not valid in my country (Russia), and also it is implemented in many free opensource programs, like FUSE exFAT plugin in Linux, FatFS (which is the library QSINIT FAT support is based on). So far, there was no M$ claims about these projects. As I understand, they only sue commercial projects. Free projects have nothing to get from. You can freely use exFAT support for your own needs. It is Arca has problems with using it, not you or me. (But I made a version without exFAT, they are not satisfied with it, and not even thanked me for making it).

Quote
There has been some discussion about porting the EXT file system to OS/2. I don't know much about that, so I won't comment, but word is that it is much like JFS. I also don't know much about HPFS386, but I suspect that JFS is more than a suitable replacement.

JFS was developed earlier than IBM/Exigen USB stack, so they did not recommend to use it on removable media. I successfully use JFS with my USB hard drive for a long time. I've seen no problems with it. The only thing you need is to explicitly eject the volume before removal. But thic is the case with any file system. Also, JFS is journalled file system, so it is not recommended to be used on flash sticks, because of quick wearing-out of log area. So, it is better to use FAT32 or HPFS with flash sticks (or any other non-journalled FS)

Pages: 1 ... 18 19 [20] 21 22 ... 25