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 ... 64
1
Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: August 15, 2022, 03:00:46 pm »
About driver duplicates, as far as the "main driver" goes:

1) https://hobbes.nmsu.edu/download/pub/os2/system/drivers/network/os2ndisp.exe (Version: 2.04c)
is an exact duplicate of
2) https://hobbes.nmsu.edu/download/pub/os2/system/drivers/network/TokenRingPCIv33b.zip (Version: 3.3b)

But 1) contains an additional driver to support PC-CARD based interface HW but compared to 2) it is lacking the DOS drivers.
For OS/2, package 1) is therefore the more complete set of drivers.

If you insist on keeping both, I suggest to at least update both descriptions to "Version 2.04c" because that is what the enclosed documentation refers to in both cases.




2
Programming / Re: Compiling a PM sample with GCC
« on: July 05, 2022, 09:41:44 am »
At least nmake.exe treats all environment variables as makefile variables (unless you suppress this via a commandline switch).
Therefore, you can do this (from an nmake makefile):

rc -r -i $(UNIXROOT)\usr\include walker.rc

Maybe the same thing works for make.exe.


3
Programming / Re: Compiling a PM sample with GCC
« on: June 30, 2022, 07:11:58 pm »
It's a tools warning and not a warning of the running app.
You cannot fix that in the source code.

4
Programming / Re: Compiling a PM sample with GCC
« on: June 30, 2022, 11:51:20 am »
1) regading rc: this is typically a problem with multiple versions of rc.exe existing on a standard OS/2 or AN system.
There is rc.exe in directory \OS2 and then there is a 16-bit version and also a 32-bit version in \OS2TK45\BIN or whereever the OS/2 toolkit was installed. What could be done is to rename \OS2\RC.EXE to something else which should then ensure that the toolkit version of RC.EXE is called.

2) I don't know what you are trying to accomplish regading the linker.
The problem is that nothing tells the linker what app type to produce, apart from what is specified via the DEF file.
The default app type is WINDOWCOMPAT.
You would need to introduce a "pass through" for an app type so that gcc.exe can pass it to emxomfld.exe so that it in turn can pass it to the native linker (LINK386, ILINK, WLINK, whatever is specified via  EMXOMFLD_LINKER).
But that's simply not worth the effort as the native linker will take what is in the DEF if it can find a DEF file.

5
Programming / Re: Compiling a PM sample with GCC
« on: June 29, 2022, 02:13:18 pm »
The problem is a bit convoluted as it is intransparent how the gcc shell eventually calls the system linker (be it LINK386, ILINK or WLINK) when you do this:

gcc -Zomf pmhello.obj pmhello3.obj pmhello.def -o pmhello3.exe

In any case, it appears that the gcc shell always calls the system linker with NO apptype argument at all which in turn defaults to WINDOWCOMPAT. The def file in turn properly tells the linker that the app type is WINDOWAPI. It is the system linker that then issues the warning about apptype mismatch.

It's nothing to worry about and in fact you can direct ILINK to ignore that warning and not issue it.

6
Internet / Re: lost in Hobbes
« on: June 28, 2022, 02:45:57 pm »
Meshell-os2.wpi has been moved to:

https://hobbes.nmsu.edu/download/pub/os2/util/shell/meshell-os2.wpi

automatically, to the requested directory. So where is the problem ?

7
General Discussion / Re: eCS 2.2 purchase
« on: June 11, 2022, 08:31:14 pm »
No. Either you know somebody that lends you the USB stick that has ArcaOS 5.1 on it or you will have to buy ArcaOS. And we are back to zero.

8
General Discussion / Re: eCS 2.2 purchase
« on: June 10, 2022, 10:48:04 am »
You will never know how much of system memory (RAM) is mapped below the 4 GB physical address line.

Booting in UEFI mode, you will know how much memory is mapped below 4GB, though there is sometimes problems with fragmentation and not being able to use it all. One problem with the newest systems is starting to be having the video buffer mapped above 4 GB, which makes the system unusable to OS/2.

1) Yeah. Once you have bought your new computer you can then check if it works with OS/2. Unless you find someone beforehand that has the very same computer and also uses OS/2. Great deal.

2) "Video Buffer above 4 GB (physical address line)" is a perfect example of PC manufacturers no longer even considering 32-bit OSes, left alone 16-bit OSes. It would have been a better choice if AN had accepted this fact and would have become more involved with the Virtual Box team to ensure that OS/2 will continue to run virtualized. But they decided differently.


I know one thing for sure: if my fairly old desktop computer dies, I will move away from OS/2 altogether. I already do all current development under an eCS guest running under Virtualbox.

9
General Discussion / Re: eCS 2.2 purchase
« on: June 09, 2022, 04:42:28 pm »
You will never know how much of system memory (RAM) is mapped below the 4 GB physical address line.

Newer systems tend to reserve a lot of the physical memory space below 4 GB presumably for the PCI(e) bus so that you can use older 32-bit PCI cards/devices, potentially requiring large amounts of physical address space (like, say a 32-bit PCI graphics card with 2 GB of video memory: it needs 2 GB of physical address space below the 4 GB address line). Newer 64-bit PCI cards are of course not suffering from this problem.

It's just a fact that every modern OS is 64-bit by now, which means, it has no problem accessing system memory if it is mapped to physical addresses beyond 4 GB and therefore it is not affected by this limit. And therefore manufacturers no longer care about this limit.


10
Setup & Installation / Re: OS/4 Problem SVN6139
« on: June 08, 2022, 08:59:51 pm »
... 8 cores. Looks like there is something wrong with the thread scheduling (it blocks for extended periods).

Interesting, I run with 4 cores - newer seen.  Any details?

I am using the VAC compiler from time to time. It comes with an IDE called "Integrated Workframe" (IWF).
The IWF implements a couple of WPS classes, in particular one to display all "parts" of the project in a WPS folder.
You can open different views of that WPS folder much like any other WPS folder: icon, tree, details view.
A "part" is normally a file in an ordinary filesystem, however, the IWF can be extended and generalizes the concept of a "part". That said, I wrote an extension to display the contents of ZIP files within the WPS folder where the "directory" is the ZIP file and the "files" are the archive files within that ZIP file.
Now, I have linked 3 ZIP files into one project and the overall number of archive files is > 9000. Unfortunately, the IWF is not very performant and in addition, it starts a new thread for each view of the WPS folder (you can concurrently open multiple views of the same WPS folder, again, much like an ordinary WPS folder). I used the "unzip" DLL interface to query and list the archive files within the ZIP file and maybe, that also eats up quite some processing power as the "unzip" DLL interface will be called for as many views as there are open (even though, of course, the ZIP content is the very same).

What I now observe is this: the time to display all "parts" of a WPS view is already pretty slow with the OS/2 kernel (takes more than 90 seconds to display all "parts") but it becomes VERY slow with the OS/4 kernel in place where it takes much longer (3 minutes or more). From the way those IWF WPS classes work, I'd think that this has either something to do with threading or with some blocking semaphores waiting for something.
What I can see is that OS/4 activates about all kernels on my 8 core machine when that view refresh happens whereas the OS/2 kernel will typically only use 3 kernels with the rest idling (I guess ACPI.PSD takes care of that but I am of course using OS4APIC.PSD+ACPI4.BPD when I am using the OS/4 kernel).
What I additionally see with the TOP tool is that with the OS/2 kernel, one process will shortly monopolize the processing power and that will then quickly move to the next process monopolizing the processing power and so on and so forth (so, the load is not only concentrated on PMSHELL.EXE under whose context the WPS classes are executing).
With the OS/4 kernel, one process will monopolize the processing power for a much longer time.

11
Setup & Installation / Re: OS/4 Problem SVN6139
« on: June 07, 2022, 11:44:48 pm »
Specifying VALIMIT=3072 seems to fix the trap that I was experiencing. But I have probs running with 8 cores. Looks like there is something wrong with the thread scheduling (it blocks for extended periods).

12
Setup & Installation / Re: OS/4 Problem SVN6139
« on: June 07, 2022, 11:09:49 pm »
1) latest OS/4 kernel is 6140. However, I experience a trap on bootup. I donĀ“t know why. I created a trap dump but the dump formatter (that comes with eCS) cannot properly decode the dump. the OS/4 kernel seems to be not equivalent in this respect.

2) are you sure it is "E:\OS2BOOT \pmDDK.SYS" ? Looks like that should be "E:\OS2\BOOT\PMDDK.SYS". Or is that a typo ?

3) have you also installed ALL other drivers that come with the OS/4 zip ? OS4APIC.PSD, SCREEN03.SYS, OEMHLP.BPD ?

4) you might also be forced to install ACPI4.BPD in case your system no longer has working MP tables (this is something that predates the ACPI tables and provides a subset of functionality of the ACPI tables to support a multi-core/multi-processor system). However, that driver is hard to find but drop me a private note and I can send that to you.

I doubt that you need to patch something (likely, you mean ACPI.PSD). And the ACPI.PSD that can be patched is an outdated version, that is not recommended anyways.




13
The trap in PMMERGE happens in a routine called "MoveAndXform".
It happens when copying a string via the "movsd" instruction.
The exception code is C000005 which means "XCPT_ACCESS_VIOLATION".
P1 = 2 which means XCPT_WRITE_ACCESS which means the target buffer is obviously too small to receive the string.
What's more important: "MoveAndXform" calls routines "GetFaceName" and "GetCellTransform" which seems to indicate that this this is all about using fonts and displaying them in a window.

So I think, Roderick is correct and this is a problem with using fonts. The fix might be to set a proper "default font", maybe the font name of the font that is being used is too long or some such.
I seem to remember that there was a OS2SYS.INI setting for this. An alternative might be to drop a new font onto the program window (it it opens at all).

What I would try is to properly install the fonts that come with the program. Open the fonts palette, select "edit" button, then select "Add..." button and browse to the programs dir to select "AHDPHON.AFM" and "AHDPHONI.AFM". This will install the fonts to the \PSFONTS folder.

Unfortunately, I cannot test the prog as I don't have the encyclopedia data as such.
One thing you obviously need to do is to set up env vars DUX_AHD_DATA and DUX_ENC_DATA to point to the directory where you have the encyclopedia data.

I have installed AHD_PATH_2-0 and then copied over the contents of AHD_PATH_2-02 and I don't experience any crashes but the prog will not display anything either (due to the missing encyclopedia data).

14
Games / Re: DOS VDM - USB and Game port Gamepad support
« on: May 28, 2022, 03:55:17 pm »
Use Panorama, but as a test, disable the screen buffer (it's in the screen settings). If that helps then unfortunately, you will have lousy overall video performance.

15
Hardware / Re: ArcaOS 5.1 UEFI support - GOP?
« on: May 25, 2022, 02:28:15 pm »
I understand that bhyve is a hypervisor, a "host" so to say, for running a "guest" in a VM (much like Virtualbox ?).

So I understand that the "host" relies on GOP but why would the "guest" (ArcaOS in this case) need GOP for just that ?
Wouldn't you be able to run plain DOS as a "guest" (and surely, DOS knows nothing about UEFI or GOP) ?

Or is this necessary to support screen output during the ArcaOS bootup phase ?

Pages: [1] 2 3 ... 64