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

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

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

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

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

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

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

8
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

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

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

11
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".

12
Hardware / Re: The last nail in OS/2's coffin
« on: January 23, 2024, 05:18:53 pm »
If you want to delve into the details:

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

Currently, this is only a proposal. But it gives a very good idea of what Intel thinks is no longer needed.

Its expected this will indeed be long term thing to happen. I understand the legacy bit takes up 12% of the space in CPU.
I read an article (I do not the have link handy) of one of the main AMD tech engineers and he said the proposal was every interesting.
However the engineer indicated the changes proposed are "very, very, very, very complex to make".

The other thing that this would imply is (the way I understand it) is that NO current VM would work anymore
to run legacy OS. Its the CPU that provides the virtualization support to hypervisor.

Roderick

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

13
Hardware / Re: The last nail in OS/2's coffin
« on: January 22, 2024, 05:24:55 pm »
Intel proposed Itanium 64 bit in 1989. It takes some time for these plans to come about. Even articles about the new 64 bit architecture from Intel mention cores that still provide X86 mixed with 64-bit only cores.

https://en.wikipedia.org/wiki/Itanium

Even if nothing happens for a while, it's worth thinking about how OS/2 runs on CPU features that matter very little to the CPU market.

The other thing that threatens OS/2 is the aging of its users. I predict that will be the actual cause of death.

With Itanium 64 bit, while moving to 64-bit, Intel wanted to push through a completely new CPU architecture with a completely different instruction set. That failed because nobody wanted to immediately rebuy all their software.

But with x86-S, Intel wants to make room on their die, kicking out all the stuff nobody needs any more (freeing space for valuable things like for example an increased cache size) and also, because the twisted x86 architecture seems to introduce more security issues then would be necessary because the x86 architecture has become too complex.
That is a completely different motivation. It is in Intel's best interest to push this through as fast as possible. And it has become fairly easy because all major OSes and their applications are 64-bit already and also already fullfil all prerequisites to make them run on x86-S.

14
Hardware / Re: The last nail in OS/2's coffin
« on: January 22, 2024, 02:28:43 pm »
If you want to delve into the details:

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

Currently, this is only a proposal. But it gives a very good idea of what Intel thinks is no longer needed.

15
Hardware / Re: The last nail in OS/2's coffin
« on: January 22, 2024, 11:39:32 am »
Taken the fact that AMD was the driving force to intoduce 64-bit mode and Intel just following, I very much doubt that AMD would put the burden onto itself to support legacy HW concepts that no current OS needs. That would throw them behind Intel with no benefit at all. You need the die for modern stuff (AI in HW or some such, larger on-chip cache, larger SIMD registers etc.) and not for stuff that is not needed at all any more.

Intel taking that step is effectively Intel's confession that 16-bit and segmentation have no future at all.
As to the ring protection, it turned out that differentiating between "user" (Ring 3) and "system" (Ring 0) is already sufficient. For paging, these are already the only 2 "Ring Protection" levels (and they are consequently called "user" and "system").

Unfortunately, OS/2 offers use of Ring 2 (in conjunction with the IOPL flag in the EFLAGS register) to simplify I/O port access and therefore there are some applications that make use of that and would need to be rewritten to use a device driver instead. But see my statement about OS/2 device drivers ...


Pages: [1] 2 3 ... 85