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 ... 19 20 [21] 22 23 24
Applications / Re: Avoiding Windows 7's CHKDSK?
« on: May 08, 2017, 07:39:42 pm »
2Andre Heldoorn: What program writes that message? Which version? Do you have U*.DLL on LIBPATH? Are there older UFAT32.DLL on the LIBPATH? Did you unpacked all correctly?

PS: the required directory structure is preserved in the .ZIP archive.

> What program writes that message?

Ah, I see, it is cachef32.exe. It cannot find LoadTranslateTable function in UFAT32.DLL. So, either, or no U*.DLL on LIBPATH, or an older version of UFAT32.DLL is used. Please clean up your LIBPATH from dups. eCS usually puts UFAT32.DLL in \ecs\dll, and I usually put it in \os2\dll. So, it should be only one newer copy.

Applications / Re: Avoiding Windows 7's CHKDSK?
« on: May 06, 2017, 02:13:45 pm »
Dirty flag on FAT32 is the same as on FAT16 -- it is a bit set in the 1st FAT entry. On exFAT, though, it is set in the boot sector instead, but this is not the case.

Applications / Re: Avoiding Windows 7's CHKDSK?
« on: May 05, 2017, 12:52:20 pm »
For an old FAT16-based MP3 player, it is better to use new fat32.ifs with FAT16 support. The VFAT LFN's are now supported on FAT12/FAT16 too. So no need to use any REXX utilities to convert LFN's, or vfat2ea, it is all obsolete now. Please look at for a download link.

And, it is possible that fat32.ifs will behave differently than the kernel FAT, so your error will be gone.

PS: The reserved bytes in directory entries which are used to store the EA's pointer by OS/2, are reused by M$ on FAT32 as a high word of a cluster number (because cluster number is 32-bit on FAT32). On FAT12/FAT16, these bytes are not used as cluster number is 12 or 16 bits, and no high word is needed. So, it should play no role.  And you say that the drive is considered *damaged*, not dirty by windoze, so I doubt it's something with unused bytes in dir entries. As I can see, the trash in dir entries does not prevent the disk to be mounted.

PPS: is it possible to upload the disk image somewhere? (I could suggest my ftp for upload, if so)

2Sigurd Fastenrath: The default kernel is 14.104a_UNI. But also SMP kernel and OS/4 kernel and debug are supplied too. Also, default loader is QSINIT, but you can choose IBM's or OS/4 loaders. -- These can be choosen in the boot menu. And the default and fail safe configuration is without SMP. But you can also choose to use a PSD (os2apic.psd/os4apic.psd/acpi.psd by Pasha/acpi.psd by David Azarevicz). Some components are optional and not supplied on the disk for legal issues. It's up to an user to add them manually, just by copying to needed directories. These components include ntfs.ifs, Panorama and ACPI. (Please read readme.eng how to add them yourself). You also can add many programs yourself, like Netdrive, RSJ CD writer, DFSee, Mesa2 etc. For that, you need to copy programs to \apps directory, add the path to its directory to paths.sed and add WPS objects creation .rc file to rc.cfg. There's a big collection of ready to use .rc-files supplied with the boot disk. BTW, I use much more programs on my own bootable flash disk. The official distribution is just limited in size and commercial programs are not included (but there are still some shareware and abandonware programs).

2Dave Yeo: No. It is universal multiboot compliant loader, like GRUB.  (but it is began from David Zimmerli stub of os2ldr reimplementation from EDM/2, called FreeLDR, and preserved this name). FreeLDR preloads a number of files to memory, in multiboot compliant format. Then OS/2 booter is started from it. OS/2 booter takes preloaded files from memory and creates special minifsd and microfsd, which retrieve preloaded files from memory and boots OS/2. Then minifsd passes control to specified IFS and booting continues as usual. So that, we can boot from different filesystems. FreeLDR preloads files to memory (in multiboot-compliant format) from supported filesystems and then boot process continues using an IFS. OS/2 booter (bootos2.mdl file) acts as universal microfsd/minifsd pair for different filesystems. So far, I successfully tested the following IFS'es: FAT32, hpfs, jfs, ext2-os2, vfat-os2, ramfs. The Live OS/2 boot disk uses ramfs ramdisk to boot from. The files are first preloaded to memory in multiboot-compliant format (as multiboot modules). Then ramfs disk is mounted, the files are copied to ramfs and boot process continues from there. So, it uses another method of ramdisk booting. In contrast with Veit's memdisk, I use an IFS-based ramdisk, and files are taken directly from the filesystem, no need for packing files to *.pk archives. But like memdisk, it uses the el-torito boot without floppy emulation. Also, as FreeLDR is GRUB-compatible, it can boot linux kernel via linux.mdl loader too. It can chainload bootsectors and DOS kernel or NTLDR via chain.mdl loader. It can boot L4 kernel via its own loader, and other multiboot-compliant kernels too. The multiboot support code and code for reading different filesystems is ported from GRUB. It should also serve as a microfsd for os2ldr, but it is broken atm. Multiboot support allows to boot different OS'es or different single OS configurations from a single menu, which is defined in a number of config files. For example, the Live OS/2 disk can boot: 1) FreeDOS from diskette image via memdisk (not Veit's memdisk, but Peter Anvin's memdisk taken from SysLinux) 2) memtest86, which is loaded via linux.mdl 3) three OS/2 configurations via bootos2.mdl: a) Tshell b) PM/WPS/Warpcenter c) PM/WPS/XWP.

PS: Originally, it is needed for osFree project, to boot L4 microkernel and to be more OS/2-like at the same time. osFree develops an L4-based OS/2 personality, so we needed the method of booting L4. L4 uses GRUB usually, but we wanted more OS/2-like boot with microfsd etc. And also it made universal enough to boot OS/2 too.

PPS: Also, it uses features ported from a fork of GRUB by Adam Lackorzynski (one of L4 Fiasco developers from Technical University of Dresden). These features (toggle command and GRUB variables support) allow to set boot options from main menu. You press a key and it toggles different values of a variable. Then variables are substituted into boot scripts. Also, these variables can be passed into config files via text preprocessor (like #define in C preprocessor does). For example, it can be passed to config.sys.  Also, the files like config.sys can contain directives like !include, !ifeq, !ifneq etc, so you can control different parameters passed to config.sys and include/cut pieces of config file depending on that. The idea to use text files preprocessor is used in Veit's os2csm too. But I use more human-readable format for text preprocessor directives. And Veit intercept's int 13h during config.sys reading. I just patch config.sys in memory after preloading it by freeldr.mdl.

PPPS: Also, FreeLDR can start from QSINIT/os4ldr menu on HPFS or JFS filesystems. (HPFS support is added into FreeLDR too, also it supports FAT, ext2, ntfs, JFS, ISO9660 and different UNIX filesystems, like reiserfs, XFS, UFS2, FFS etc).

2Dave Yeo: reverse-engineering? Why? It is open source. Source code is available from osFree svn:, Maybe, you confused it with OS/4?


> I wonder if this FreeLOADER file could be assumed as being legal Software.

Why not legal? It is based on GRUB, indeed, under GPL license, in fact. I wrote it for osFree project, and use for universal bootable CD/flash/etc. It can be used as a boot CD or maintenance system, booted from a hard disk too. Or, as a live OS/2 system.

PS: Which error in fat32 driver, btw?

Off Topic discussions / Re: Genode OS Framework version 17.02
« on: March 02, 2017, 11:12:53 pm »
The Muen separation kernel is one of the target kernels. Genode itself is C++.

Article Discussions / Re: OS/2 Books Fans?
« on: March 02, 2017, 07:08:48 am »

Applications / Re: Regina REXX vs. OS/2 REXX
« on: March 02, 2017, 06:57:44 am »
2Martin: I don't know exactly the list of functions, but it can be determined if we'll add a debug log for rexx.dll and rexxapi.dll, so we can see, which functions it calls. The full list of functions in REXX.DLL is here: and for REXXAPI.DLL: Involved here are SOM functions, so that WPS uses REXX for scripting (to register/deregister WPS classes).

Article Discussions / Re: OS/2 Books Fans?
« on: February 28, 2017, 08:46:56 am »
I have apibas,inf and kdebug.inf

Applications / Re: Regina REXX vs. OS/2 REXX
« on: February 26, 2017, 06:25:58 am »
Hi all. I am working on Regina REXX integration for OS/2 in osFree project. Indeed, the REXX.DLL and REXXAPI.DLL were existed in Regina code, but they were incomplete. Also, we in osFree had our own DLL's as forwarders to REGINA.DLL, so that, you can load REXX.DLL (the interpreter itself) and use it without specifying REGINA.EXE before each script. -- You just run .cmd file and CMD.EXE passes it to REXX interpreter. But there is a problem: CMD.EXE is a 16-bit program, so it uses 16-bit REXX functions in REXX.DLL and REXXAPI.DLL, instead of 32-bit ones. But 16-bit functions were missing, as Regina is a pure 32-bit program. But, using Regina via REXX.DLL/REXXAPI.DLL is working with 32-bit shells like 4OS2. So that, Regina REXX is working with 32-bit programs, but does not work with 16-bit programs. Most notable 16-bit ones are CMD.EXE and WPS (yes, it is, for some reason, using 16-bit functions, not the 32-bit ones). So, if you install our REXX and REXXAPI, WPS won't work too and OS/2 will not start. We extended REXX.DLL and REXXAPI.DLL with some 16-bit functions as wrappers around 32-bit Regina functions, and 32-bit wrappers for CMD.EXE 16-bit subcommand handlers. So, some 16-bit programs began to work. For example, rexxtry.cmd when run in cmd.exe, and executing "CLS" command of CMD.EXE (a 16-bit subcommand handler). But another problem exists. Usually, REXX.DLL is loaded by REXXINIT.DLL, which is, in turn, loaded by PM, and keeps it loaded. REXXINIT.DLL starts thread, which listens a message queue, and  serializes access from applications to REXX.DLL. So, there's another problem: Regina for now works with only one application at one time. So, we can start only one Regina client at one time. So, we need somehow serialize access to regina.dll in rexx.dll. This has to be done, too.

Also, i should note that switchrx.cmd works by swapping different versions of REXX.DLL (the interpreter) and REXXAPI.DLL (the API for extending other programs by REXX). Other DLL's are mostly usable for different interpreters. For example, REXXUTIL from Object REXX can be used with Classic REXX without problems. It has more functions implemented. Also, except for IBM's versions of REXXUTIL, exists WINDOWS version of REXXUTIL (it seems, it is called REGUTIL and is used by Regina too). But we also have two other native OS/2 REXXUTIL versions, with source code available, the one written by Mike Greene and the one supplied with eComstation.

Actually, for switching different REXX interpreters, we can suggest to rename other REXX/REXXAPI versions to CREXX/CREXXAPI and OREXX/OREXXAPI, and RREXX/RREXXAPI and make a wrapper REXX/REXXAPI with a config file, which will specify, which pair of REXX DLL's to use. I also plan to implement this in the future. This will allow to switch different interpreters without a reboot.

Making more 16-bit wrappers for regina.dll entry points will make CMD.EXE and WPS work with Regina. So, we need to finish it too.

I added your notes about missing Regina features to our bugtracker:

And yes, to test our Regina REXX version, You'll need to start runworkplace=d:\os2\cmd.exe instead of d:\os2\pmshell.exe in config.sys. This will start cmd.exe instead of WPS. As we know, WPS requires more 16-bit API's implemented, and may use REXX/REXXAPI from multiple threads. So, WPS needs to be disabled. Then you can run a REXX program in cmd.exe. (This is needed temporarily, because many features are unimplemented)

Setup & Installation / Re: Question about OS/2 3.5 floppy image files
« on: February 25, 2017, 11:45:57 pm »
Physical floppy discs only under Windows hosts afaik.

And OS/2 VBox host now supports physical floppies. The only problem for now that it is now not very stable and slow.

Applications / Re: Vbox5.06 beta
« on: January 10, 2017, 05:02:22 am »
But you can attach USB mouse or USB harddisk to a VM (you only need to add an USB controller to Storage section, and attach a .vdi to it).

??? Why would anybody want to do that? I  can see that USB 3.1 will end up replacing SATA, in the near future, simply because it is cheaper, but it is also FASTER. But doing that In a VM doesn't make sense, at this time.

Just to give an USB controller to a guest OS? VBox is needed not only for you to see your physical USB flash formatted with an exotic filesystem. It is used by developers for testing different configurations in VM's. At least, I sometimes need to test booting OS/2 from USB controller. It is different from a SATA controller from OS' point of view.

PPS: Also, no need to disable sound, as it uses Null audio drier. So, guests will see the audio card, but the sound will be not output. It should not affect the performance.

Well, that is clearly WRONG. When I enable sound, the performance is definitely much slower than without it. 

You seem to be wrong here. I doubt that enabling sound could eat up significant resources.

Perhaps that is because I use the SoundBlaster option, which works a LOT better under win 10.

You can try HDA or AC97 too, but not sure if it will help.

Pages: 1 ... 19 20 [21] 22 23 24