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
Setup & Installation / Re: Ecomstation 1.0
« on: Today at 07:48:46 am »
www.xeu.com is also dead, has renamed itself to

https://www.payglobaltechnology.com/

as has changed its business model.

2
Applications / Re: XWP 1.0.17: any availability date ?
« on: March 20, 2024, 05:16:02 pm »
ok, thanks for the answer.

3
Applications / XWP 1.0.17: any availability date ?
« on: March 20, 2024, 06:56:08 am »
Out of interest but also need (I had raised 2 tickets): is there a rough availability date for XWP 1.0.17 ?

I was curious and looked into the XWorkplace/XWPHelpers SVN repos but could not see any checkins from Rich. I therefore suspect that currently, he only has done the changes to his local copy.

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

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

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

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

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

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

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

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

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

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

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

15
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

Pages: [1] 2 3 ... 85