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 ... 20 21 [22] 23 24 25
316
Applications / Re: Establishing Wlan Connection by Command Line
« on: June 16, 2017, 02:20:18 pm »
What is the problem? You just create a config for wpa_supplicant.exe, start it, and additionally start the DHCP client (if needed)

317
Storage / Re: USB and Format Issues
« on: May 30, 2017, 02:19:04 pm »
2Eugene Gorbunoff: How could reformat help him? Does it create the LVM info?

Anyway,  using DFSee, as I suggested above, is non-destructive. It only writes a DLAT sector before the boot sector. After you eject and insert again the flash stick, it will be mountable, and no need to format. Using reformat formats the stick, so, its contents will be lost. What if it is other user's flash stick and he is not agree to reformat it?

318
Storage / Re: USB and Format Issues
« on: May 30, 2017, 01:56:25 pm »
2Paul Richards: If you able to see disk contents in DOS prompt, then in OS/2 command prompt it should be seen too. Did you assigned the LVM info to flash disk? If not, the disk will be inaccessible. You need to take DFSee from http://hobbes.nmsu.edu and assign a drive letter first.

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

PPS:
> 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.

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

321
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 http://trac.netlabs.org/fat32/ 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)

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

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

324
2Dave Yeo: reverse-engineering? Why? It is open source. Source code is available from osFree svn: https://sourceforge.net/projects/osfree/, http://osfree.org. Maybe, you confused it with OS/4?

325
2Sigurd:

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

326
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++.

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

328
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: http://svn.code.sf.net/p/osfree/code/trunk/OS2/REXX/rexx/rexx.h and for REXXAPI.DLL: http://svn.code.sf.net/p/osfree/code/trunk/OS2/REXX/rexxapi/rexxapi.h. Involved here are SOM functions, so that WPS uses REXX for scripting (to register/deregister WPS classes).

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

330
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: http://osfree.org/doku/en:issue:list

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)

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