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

Pages: [1] 2 3 ... 85
1
Programming / Re: Parition alignment
« on: March 18, 2024, 12:23:54 pm »
I remember that that would mean that the number of sectors of a partition has to be a multiple of the NUMBER_OF_HEADS * NUMBER_OF_SECTORS_PER_TRACK (where that product is identical to a cylinder size) and that a partition has to start on a sector number that is a multiple of that product and, as a consequence, also end on a sector number that is a multiple of that product minus 1.

At least that is the formula that I used when implementing "virtual partition support" (wrapping a "large floppy" type of USB MSD into a partition) in USBMSD.ADD so that LVM and MINILVM would accept such a media as partioned media without complaining.
I vaguely remember that if the media contained a number of sectors that was not a multiple of that product, that it was acceptable if the partition at least ended on a sector number being a multiple of that product minus 1 (and could start at an offset to that product) but it is possible that that is only allowed for the very first partition on a media (that said: the "virtual partition support" only requires exactly 1 partition for the whole media).

There are specific rules for the NUMBER_OF_SECTORS_PER_TRACK that apply to OS/2 and this number varies with the size of the media.
Typically it is 63, if that is not sufficient with the max NUMBER_OF_HEADS being 255 then it is increased to 127 and further increased to 255 in case 127 is still too small.

2
Programming / Re: About somFree
« on: March 13, 2024, 09:40:01 am »
"somFree" implements SOM Version 3.0. But the WPS uses SOM Version 2.x. There existed a SOM Version 3.0 for OS/2 but nobody ever installed it (apart from testing it) because it is not backward compatible to Version 2.x. There are additional SOM classes in Version 3.0 and I seem to remember that there are subtle differences in managing dynamically allocated memory compared to SOM Version 2.x.

Technically, all of the WPS could be replaced. That said, PMSHELL.EXE (the second instance of it) does not do much more than loading a huge bunch of DLLs that make up the WPS (plus interfacing to the first instance of PMSHELL.EXE to allow a WPS restart without the need to restart the whole computer).
But I think, most of the work is about interfacing to PM, that's where things become tricky and also partly undocumented as far as the WPS goes.
In the end, you would end up replacing the complete user interface and that is a lot of work.

3
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« on: March 08, 2024, 01:49:06 pm »
As to fixups: I would think that if you specify the /BASE: keyword to the IBM OS/2 linker that then, fixups can be avoided.
I would also think that the IBM OS/2 linker has the default behaviour that when it creates an EXE, it will always assume a base of 0x10000 for the first memory object (and a fixed scheme of additional bases for the following memory objects) and will then be able to avoid fixups.

If you create a DLL, you would typically not define a base when linking because that is not desirable in general and in that case, you cannot avoid the fixups (but that is what fixups are for: to allow code/data to be relocated in memory).

When I say "IBM OS/2 linker" I assume that the Watcom linker and also the Borland linker would behave the same.

4
Storage / Re: How to properly setup a working FAT32 USB stick?
« on: March 06, 2024, 07:29:11 pm »
Sorry Andi,

The 2 comers were the result of my new keyboard, it is super sensitive - hold a key down a little bit longer and it repeats, the time is much shorter than the old one was.

You should be able to change the delay as well as the repetition rate via the keyboard object. If that does not work and if you have a USB keyboard, then USBKBD.SYS is broken for you.

5
Programming / Re: DosDevIOCtl disabling keyboard in VIO mode
« on: March 04, 2024, 08:56:24 am »
The "Kbd", "Mou" and "Vio" functions have no 32-bit thunking function, the compiler will need to provide the thunk (as the VAC compiler and Watcom compilers will do if the 16-bit function is properly declared as such).
But I also do not understand why you would be dogmatic about using 32-bit only. OS/2 has a strong 16-bit heritage, that's just the way it is.

6
Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: February 25, 2024, 09:27:06 am »
"wpsenh" makes no sense as every WPS class enhances the WPS. That is the nature of every WPS class.

7
Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: February 17, 2024, 08:54:37 am »
This would go against Martin's decision to keep all old cruft.
Back at the time, he uploaded to Hobbes all old versions he could find.

8
Applications / Re: Where to upload ?
« on: February 06, 2024, 07:54:49 am »
Find attached. What I changed regarding the original:
1) updated and renamed PHYSMEM to MAKEFILE
2) updated PHYSMEM.LNK
3) updated PHYSMEM.DEF
4) updated PHYSMEM.ASM and rebuilt the driver PHYSMEM.SYS
5) added the PHYSMEM.SYM file for PHYSMEM.SYS

The executable RAMSCOPE.EXE to actually view memory is left unchanged.

9
Hardware / Re: OpenWatcom Discussion
« on: February 03, 2024, 05:39:25 pm »
@Silvan: Added my 2 cents worth to your trap description.

10
Hardware / Re: OpenWatcom Discussion
« on: February 01, 2024, 06:38:36 pm »
As a very wild ass guess, it might have to do with this change added by Juri to the Watcom 2 (fixing my problem):

https://github.com/open-watcom/open-watcom-v2/commit/e905d92c6d3b5b7c22845e4450bd9a7ba5b87757

But I am far from being sure. I am not a compiler expert.

11
Hardware / Re: OpenWatcom Discussion
« on: February 01, 2024, 10:38:03 am »
Watcom 1.9 is what supposedly everybody should use, so I called that "official". But for a seldomly used feature ("based pointers") it produces an incorrect binary (for code executing in Ring 0 -> device drivers) where Watcom 2.0 will work properly. But Watcom 2.0 is "Jiri's fork" where you never know what he will do next.

Is there a possibility at all to report a bug against Watcom 1.9 ?

12
Applications / Where to upload ?
« on: February 01, 2024, 08:03:15 am »
I have fixed "RAMSCOPE" to work under 32-bit OS/2 (in particular: its device driver PHYSMEM.SYS).
Not that it would matter but it was worth the fun :-)

I have uploaded to "www.hobbesarchive.com" (hopefully,it's unclear if it ever found its way). Is that now the agreed place or what ?

Lars

13
Hardware / Re: The last nail in OS/2's coffin
« on: February 01, 2024, 06:52:08 am »
What OS/2 applications do exist where you would not find an equivalent under Linux (or Windows)?
And more importantly: what developer would bother with OS/2 development tools?
I can tell you from my own experience that this becomes an increasing problem. One version of Watcom being incompatible with the next and unfortunately picking the "official" version does not help because it is the one that is buggy.

14
General Discussion / Re: Reg article on CUA
« on: January 25, 2024, 01:41:51 pm »
It *is* interesting, in more ways than the CUA interface aspect. It points at another "Register" article (16-bit DOS), which says:

"ms removed the 16-bit compatibility layer from x64 Windows OS's of the time, and you could no longer run 16-bit apps. Developers responded with DOSEMU", and many other flavors of DOS emulators. To this day, you can run such emulators to get at the many versions of DOS OS and applications, "on x64 Windows & Linux".

That's an OS that is older than OS/2, and if it can be emulated and survive & thrive to this day, there shouldn't be any reason why OS/2 (all variants) can't be emulated as well, and prosper long into an x64 world.

An X86 CPU can be emulated so that it will run OS/2. But OS/2 exploits almost all HW features of that chip, in contrast to DOS and Windows-16 bit (DOS only runs in real mode and therefore all "protected mode only" instructions are irrelevant, it also only supports 16-bit segments/operand and address sizes). And that will make the emulation incredibly slow.

15
Hardware / Re: The last nail in OS/2's coffin
« on: January 24, 2024, 10:43:06 am »
Correct. Virtualization of OS/2 (and likewise: DOS and Windows 16-bit) will not be possible once x86-S is introduced. Only emulation will be possible (with a huge performance impact, of course).

This raises the question of how virtualization works currently with a 64 bit system running 16 bit code. My understanding is that in 64 bit mode, 16 bit software doesn't work.
As for emulation, with JIT compiler, performance can be pretty good. The PowerPC OS/2 was supposed to run DOS/WinOS2 well, as well as some versions of NT such as the Alpha port.
I doubt that anyone will actually do it but possible.

Quote
Compatibility mode (sub-mode of IA-32e mode) — Compatibility mode permits most legacy 16-bit and
32-bit applications to run without re-compilation under a 64-bit operating system. For brevity, the compatibility
sub-mode is referred to as compatibility mode in IA-32 architecture. The execution environment of compatibility
mode is the same as described in Section 3.2. Compatibility mode also supports all of the privilege levels
that are supported in 64-bit and protected modes. Legacy applications that run in Virtual 8086 mode or use
hardware task management will not work in this mode.
Compatibility mode is enabled by the operating system (OS) on a code segment basis. This means that a single
64-bit OS can support 64-bit applications running in 64-bit mode and support legacy 32-bit applications (not
recompiled for 64-bits) running in compatibility mode.
Compatibility mode is similar to 32-bit protected mode. Applications access only the first 4 GByte of linearaddress
space. Compatibility mode uses 16-bit and 32-bit address and operand sizes. Like protected mode, this
mode allows applications to access physical memory greater than 4 GByte using PAE (Physical Address Extensions).

So, with the existing "IA-32e" architecture, your OS can be running all in 64-bit mode while it can still execute applications containing 32-bit and 16-bit code (and data) segments. Obviously, Virtualbox uses this support to run 16-bit and 32-bit OSes like DOS, Windows 3.x and OS/2.

Once x86-S is introduced, Intel CPUs will no longer support this "compatibility mode".

Pages: [1] 2 3 ... 85