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] 2 3 ... 5
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.

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 :)

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

Code: [Select]

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.

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.

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.

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

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.

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.

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.

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.

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.

Article Discussions / Re: Large Floppy Support Discussion - USBMSD.ADD
« on: November 27, 2017, 04:21:08 pm »
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.

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.

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.

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).

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)

Hardware / Re: Preparing an USB Flash drive with FAT32 with DFSee
« on: November 19, 2017, 04:39:28 am »
> What is the correct name for this problem?  "Un-proper CHS layout on the disk?"

The problem is generally with missing LVM info. If no explicit LVM info on disk, it won't be mounted under OS/2, so, you should create it for OS/2 kernel to call MOUNT for IFS drivers. (To be exact, the kernel will call only in-kernel FAT driver to mount disks without explicit LVM info, which will fail. It won't call IFS'es FS_MOUNT routines). Un-proper CHS layout is another problem. It prevents to add the LVM info with LVM.EXE. But DFSee allow to do this with any disk geometry (so, you can avoid destroying partitions. If the flash stick is not your own, but your friends' or clients', then repartitioning is undesirable. But you can optionally do a repartition, if you want better compatibility with LVM.EXE and your BIOS, if you want it to be bootable)

Hardware / Re: Preparing an USB Flash drive with FAT32 with DFSee
« on: November 19, 2017, 03:16:41 am »
Unfortunately, if you'll try to use FORMAT frontend with an erased flash stick, you'll get the following:

[d:\var\log]format j: /fs:fat32 /v:spower
SYS1512: The requested function is not supported on this disk or
diskette for file system FAT32.


[d:\var\log]fat32fmt j: /fs:fat32 /v:spower
FAT32 version 0.10.r331 compiled on Nov 11 2017
The new type of file system is FAT32.
Диск не имеет метки тома.
Warning!  All data on hard disk j: will be lost!
Proceed with FORMAT (Y/N)? y
Size: 14336 MB 30282525 sectors.
512 Bytes Per Sector, Cluster size 8192 bytes.
The volume label is SPOWER.
The Volume Serial Number is 0CEA-3537.
32 Reserved Sectors, 14772 Sectors per FAT, 2 fats.
15140864 kilobytes total disk space.
15122432 kilobytes are available.
0 kilobytes are in bad blocks.


100% of the disk has been formatted.

Wrote 15151104 bytes in 7.06 seconds, 2.05 Megabytes/sec
Clearing out 29592 sectors for
Reserved sectors, fats and root cluster.
Initialising reserved sectors and FATs.
WARNING: failed to set the volume label, rc=26

Format completed successfully.

will succeed. So, you can try to format with a standalone FORMAT utility. The minor problem that it fails to set the volume label with DosSetFSInfo, because of ERROR_NON_DOS_DISK == 26 error. But you can try it again after FORMAT. The FORMAT.COM frontend fails to pass control to FAT32 format routine, unfortunately.

Note that big floppy flash disks have "Fake Disk" disk name, and "Fake volume" / "Fake partition" in the volume/partition name. That is the default LVM Info, which Lars is emulating on big floppies.

Hardware / Re: Preparing an USB Flash drive with FAT32 with DFSee
« on: November 19, 2017, 02:14:41 am »
2Martin: Yes, you should to switch the "Expert mode" on in newer versions of DFSee, unfortunately. I don't know why the author removed it in non-expert mode, because it is one of the most needed functions, at least, for me. If "File->open object to work with->Partition->" does not list the flash disk, this means that you deleted the partition on it, or your flash disk is big floppy. You should back up it and erase, and create a partition then.

> I'm also not sure where is the "add the LVM info" function on the DFsee UI.

It is called "Edit->Edit LVM Info" in newer versions of DFSee. It is near the "Edit partition tables", which is used very frequently, too. (Need to switch the Expert mode on, of course)

> About the "large floppy stick" how does one produce it? Does it depends on the hardware of the stick?

You want to create a big floppy? You should erase the beginning of the flash disk with zeroes with the

wipe "" 0 2048

command, then try formatting it. (But select the full disk first, if you don't want to occassionally erase the wrong disk!) Lars' version of USBMSD.ADD should emulate the MBR with partition table, and the LVM info. I'm not sure if DFSee will allow you to format a flash disk without a partition created, but you can try my FAT32.IFS format instead. Unfortunately, format of the flash stick without a partition may not work under OS/2. But you can erase it under OS/2 and format it under windows then.

2Pete: What is USBcfg for? Never used it.

Internet / Re: Torrent - what is actually working???
« on: November 16, 2017, 03:21:57 pm »
I used both QBitTorrent (it is newer and more powerful) and ACT (special coloured version of ctorrent, written by acw. Unfortunately, author is R.I.P. now, so no updates for his software anymore, unfortunately. But there is still his web page alive: Maybe, ACT from this page will work, it should be the latest).

Hardware / Re: Preparing an USB Flash drive with FAT32 with DFSee
« on: November 13, 2017, 08:48:12 pm »
Also, the [micro/mini]SDXC flash cards (these are those larger than 32 GB) are usually formatted as exFAT on the factory. This is the cause some OS'es or devices cannot see such flash cards, because of an exFAT FS, unknown to them. Newer versions of fat32.ifs contain an experimental exFAT support, so you can see such flash cards in OS/2. But if your device does not see the exFAT filesystem, it is better to reformat it to FAT32. The disadvantage of FAT32 (compared to exFAT) is that files >= 4 GB are unsupported (because the file size field in directory entry is 32-bit, which limits the file size to 2^32 == 4 GB). But the FAT+ feature of fat32.ifs allows the 64-bit file size on FAT32 (it is stored in special EA, and bits 32..34 are duplicated in three previously reserved bits of the directory entry. So, first 35 bits are still stored in the directory entry, allowing files with sizes up to 2^35 == 32 GB to store their sizes in the direntry, instead of an EA. If the size is bigger than 32 GB, the full 64-bit size is stored in EAs). But the FAT+ feature is supported with OS/2 only (and with DR-DOS too, but with a bit other way than OS/2. So, you can only move big files on FAT32 disks between different OS/2 copies. WIndows will not understand such big files on FAT32, unfortunately).

I have a 128 GB microSDXC card which I use with mini USB cardreaders. It is used instead of a USB flash disk. I use it for carrying data, as well as for booting from it (most USB microSD cardreaders are bootable). I changed its geometry to normal hard disk geometry and it could be bootable on all my computers. Also, I reformatted it from exFAT to FAT32 as it has more stable support in fat32.ifs and FAT32 is supported by most operating systems. Windows can't be bootable from exFAT, at least. But GRUB4DOS, FreeLDR and QSINIT can boot from both, FAT32 and exFAT. Linux can't boot from exFAT too, at least, with FUSE exFAT driver. Maybe, it will boot with Samsung exFAT driver (if it is compiled into the kernel), but I didn't tried.

Hardware / Re: Preparing an USB Flash drive with FAT32 with DFSee
« on: November 13, 2017, 08:27:36 pm »
No need in using any scripts. Usually, the flash disks are partitioned. But some of them are not, like my Silicon Power 16 GB was. In this case, you need to create a partition first. (but if the stick is already partitioned, no need to repartition and reformat)

First, when working with DFSee, you need to select the current disk with File->open object to work with->Partition->...  No need to reformat and repartition. Just add the LVM info, eject and reinsert the disk and it will be seen under OS/2. This is indestructive, you can do this (add LVM info) without losing any files from the stick, as the only info added is the LVM DLAT sector immediately before the partition boot sector. I do this with any friends or clients flash sticks they are carrying to me to pass me their files.

So, usually, you only need to add the LVM info, and it will work fine under OS/2.Those sticks that are big floppies, can be seen with Lars' USBMSD.ADD version. It adds a virtual DLAT sector too, so no need to add it with DFSee. But partitionable media are better and more secure, so, it is recommended to repartition your flash disks. You only create the partition, and that's it.

For booting from flash disks, you may need to normalize the geometry in the partition table. Some BIOSes, like mine, doesn't like some flash disks geometries (cylinders/heads/sectors numbers), and as a result, won't boot from them. So, it is better to redefine the flash geometry to the geometry having 255 heads and 63 sectors per track. This is done with GEO command in DFSee. You can run "geo" without parameters to see the current disk geometry. It will show the cylinders, heads and sectors numbers.

The total number of sectors on the disk is equal to Cylinders * Heads * Sectors. So, you just multiply the current values to get the total number of sectors. Then divide the result to (255 * 63) and you will get the new number of cylinders.

Then wipe the disk with the

wipe "" 0 2048

command, which overwrites the disk with an empty pattern ("") starting from 0 sector, and rewrite 2048 sectors then, starting from the 0 sector.

Then enter the

geo Cyls 255 63

where Cyls is the new number of cylinders you just calculated. This should change the current geometry of the disk. Then go to Mode=FDISK->Create new partition, and create a primary partition, occupying all the disk. When operation finishes, quit DFSee, eject and reinsert the disk. Then do lvm /rediscoverprm and the new drive letter will appear. Then do

format o: /fs:fat32

and format the disk. You should install the latest version of fat32.ifs 0.10 for this command to be working.

But these steps are not mandatory. They can help the flash stick to be capable of booting from it, and to convert the stick from the big floppy to the partitionable one (which will improve the compatibility with majority of OS'es, including OS/2 installations, which haven't Lars' USBMSD.ADD installed) The mandatory thing is a command to add the LVM info. You need to define an explicit drive letter, or set the drive letter to "*:" (which means, the 1st available one). WIthout this, the drive letter won't be assigned to an USB stick/hard disk and the disk contents won't be seen.

Hardware / Re: Hardware Reports / Reviews - More - MORE !!!!
« on: November 10, 2017, 05:28:53 pm »

- Logitech Unifying Transceiver
- Logitech Wireless Mouse M280
- Logitech Illuminated wireless keyboard K800

were tested by me on MCP2/ACP2, so I know nothing about ArcaOS. But it should work with ArcaOS too, with big probability. Also, I should note a disadvantage of keyboard k800: It stops responding frequently on pre-boot applications, e.g., pure DOS, BIOS setup, FreeLDR, QSINIT apps. After a cold reboot it works again. And it works fine under OS/2 (I saw no times when it stops responding in OS/2, only in pre-boot environment). It is very annoying, but otherwise, it is very pleasant keyboard (it is wireless, charging from microusb, and having two rechargeable AA batteries inside, which could be replaced to batteries with more capacity. It uses Logitech Unifying receiver, which can be used together with a wireless mouse, like Logitech M280, supporting the same Unifying receiver. I also heard that the you can take two Unifying receivers, plug them into two computers and switch between them via a keypress. I did not tried this, yet, though. I ordered two more Unifying receivers on Aliexpress, waiting for their arrival. Will test them, when they arrive. The wireless keyboards/mice can be paired to an Unifying receiver by a win32 utility, downloaded from Logitech site. It is paired only once, and works without a special software on any OS.) Also, the K800 keyboard has a backlight with adjusted brightness and a sensor of hands proximity. It turns off on inactivity and turns on when you bring your hands to it. Very pleasant in use, except for that it sometimes does not responding (only in BIOS pre-boot environment).

PS: It also has no problem with key autorepeat, as with much newer USB keyboards. I bought another USB keyboard (some OKLICK model, with backlight, too, but it was much cheaper than K800) before this one, and it did not autorepeat keys, when you hold it on. K800, in difference from that OKLICK keyboard, does autorepeat well. I suspect that it is applicable to all Logitech keyboards.

Polls / Re: Compatibility with OS/2
« on: November 07, 2017, 02:13:02 am »

This is not true. This is a common misunderstanding. 16-bit code works in 64-bit mode. Dixie, the author of QSINIT (aka Tetris) said that he safely uses 16-bit IDT/GDT entries together with 64-bit and 32-bit ones. This is EFI version of QSINIT. EFI is 64-bit here, and QSINIT uses some 16-bit routines. So, 16-bit code can coexist with 32-bit and 64-bit ones. Indeed, under "16-bit", many people mean 16-bit real mode code, not 16-bit protected mode code, as 16-bit OS/2 and Win16 are. So, VM86 processor mode won't work in 64-bit "long" mode indeed, but 16-bit protected mode code will work.

Applications / Re: Mount ISO as drive letter
« on: November 06, 2017, 09:21:44 pm »
This script: for NDPISO Netdrive plugin can be associated with .iso files in shells like FC/2, so that, when you tap Enter on an .iso image, it gets mounted. If you tap Enter the second time on the same file, it gets unmounted. You specify a root directory, say s:\iso and mounted .iso's appear as subdirectories under s:\iso. Multiple ISO's can be mounted at the same time. Very easy and convenient.

PS: A bit offtopic, but about mounting images too: For mounting FAT12/FAT16/FAT32/exFAT filesystem images, you can use fat32.ifs 0.10 r328. It includes a f32mount utility, which allows to mount images to a subdirectory on a FAT drive. You run it as "f32mount a:\path\to\file.img w:\tmp" and contents of file.img appear under w:\tmp directory. Also, except "raw" images, I added the code from QEMU emulator, which allows to mount the VM images, like .vmdk of VMWare, .vhd from VirtualPC, .qcow from QEMU, RAW images, etc. You can mount diskette images, as well as harddisk images, a partition number could be specified as "/p:N" too, and an optional offset before a partition table, with "/o:offset". Partition numbers can be primaries from the range 1..4 and logicals, from range 5..255. 5 is the 1st logical partition. Offsets can be decimals, as well as hexadecimals, beginning from "0x". So far, some problems still exist though, and the feature is still alpha-quality, but it is promising :)

Pages: [1] 2 3 ... 5