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 4 ... 64
I have a setup with the W4 kernel (to develop and debug WPS classes). That fails with PMMERGE6111. On system start, the system will trap in PMDD with PMMERGE6111 in place. Reverting back to the original PMMERGE fixes the problem

Where is it listed what USB 12.12 fixes ?

Seriously, we all know that by now, 80% of OS/2 is trial and error. It`s worth giving it a try and note down the results (worked / made things worse / did not make a difference).

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: May 21, 2022, 09:32:43 am »
I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!


It`s a trap 3 which means it is a hard coded int3 breakpoint, put there deliberately by the programmer. The reason it fires is that something is calling/jumping to address 1000:0, that is, a ZERO offset. Since this is not expected and likely is a programmer error in that somebody tries to do an indirect near call/jump with a near NULL pointer, that is caught by this breakpoint.
Note that the trap address is 1000:0001 because for an int3 the trap screen will show the address of the instruction following the int3 and the int3 instruction is 1 byte long.

In order to analyze that, you´d need a trap dump in order to find out what code tried to call/jump to 1000:0 (or rather do an indirect near call/jump with a near NULL pointer).

Thinking about it: selector 1000 points to the DOSCODE segment that contains many low level kernel routines. And the DevHelp Routine is located in that segment (and all the subroutines it calls). The DevHelp Routine in turn is the main entry point for any device driver services and therefore used by about any device driver and a pointer to the DevHelp Routine is passed to each device driver on driver load. If that pointer is not properly saved or subsequently accidentally overwritten then you might see that trap.

So if it`s about a driver, Wim should check that the saved DevHelp pointer was not accidentally overwritten (the offset part of it) by a NULL value.

Programming / Re: getting a single keypress?
« on: May 21, 2022, 07:26:45 am »
And why can't you use the standard RTL function "getchar"? Is that not available?

Off Topic discussions / Re: Slowing Down But Not Hitting the Brakes
« on: May 13, 2022, 01:32:54 pm »
Hi Martin,

sorry to hear that, I also want to express my condolences. I guess we are now hitting an age where our parents are getting really old ...

Always remember: there are more important things in life than a piece of SW.

Applications / Re: Implemented DUMPFS.IFS as a 32-bit IFS
« on: May 03, 2022, 07:31:22 am »
There is also a detailed explanation here:

However, you don't need to manually copy files. The WPI will do the necessary things.

Also, please read the introductory words of the installer:
you need to dump to a partition of partition type 7 !
Which means you either use DFSee to achieve that or format to JFS first and then format to DUMPFS.
That said, if you don't want to screw up your existing dump partition (for the AOS dumper) you should create a new one. The easiest to test all of this is to use a virtual machine under Virtual box.

The reason I wrote this thing is because FAT32.IFS still cannot seek in files > 2 GB and therefore you cannot directly use PMDF on a dump file located on a FAT32 partition.
And my system has 8 GB of RAM of which 3 GB are used by OS/2 and therefore the dumpfile will be 3GB in size.
And I have trap dumping permanently enabled for Ring0 traps ...

Applications / Re: Implemented DUMPFS.IFS as a 32-bit IFS
« on: May 02, 2022, 05:39:46 pm »
Thanks !

If you find something that does not work, just drop a note and I'll try and fix it.

Internet / Re: New Browser Delay Discussion
« on: April 25, 2022, 07:53:24 am »
Dooble as downloaded from Netlabs Exp works for me.
But I am still using eCS.
Maybe I also have some missing prerequisite component already installed, who knows.

Internet / Re: New Browser Delay Discussion
« on: April 21, 2022, 04:08:52 pm »
Thanks for your support guys. Yes, I was not right about libvusb and libuvc, it's Lars' work, not Silvan's indeed, sorry Lars.

No worries. Just wanted to make clear that NO money was spent on something nobody has explicitely paid for.

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: April 20, 2022, 10:31:25 am »
Hi Wim,
I suspect that you mean;


Internet / Re: New Browser Delay Discussion
« on: April 17, 2022, 05:13:58 pm »
About updates to libusb and libuvc:
they were done by me exclusively (with Wim doing a lot of testing, also for free) and they have been done entirely for free. No money was spent on this. I also updated IJFW ( the FXWRAP.SYS driver to more specific) entirely for free. Silvan suggested that we might need libuvc and libusb to support USB webcams in the browser.

I thought about contacting Dmitry to ask him if he would leave Russia but I thought that might be a not safe thing to do. Well, he made his decision and I am glad that he is safe.



I have a RAM disk and environment var "TMPDIR" is pointing to it (other vars like TMP, TEMP and EPFITMPDIR are instead pointing to a hard drive directory).
Effectively it´s "set TMPDIR = Z:\" where Z: is the RAM disk drive letter.
It seems that as soon as I start an app that was ported from Unix (and therefore will in some way use LIBC etc.) then, a directory "runtime-root" is created in the root of Z:

I could care less as it will be gone on the next bootup but it seems to negatively impact the initial run of such an app. Why is this directory created and how can I prevent it from being created ?

Programming / Re: Compiling a PM sample with GCC
« on: March 31, 2022, 11:32:50 pm »
Hi Martin,

just as a side note: for a 32-bit application, the HEAPSIZE keyword in the DEF file is completely superfluous (it has no effect for 32-bit applications). But it won't hurt either, it will just be ignored by any 32-bit linker. It is a remnant of 16-bit linkers (and the original source code dates back to 16-bit times).

The STACKSIZE keyword however is relevant. 8 kBytes is very small stack for a PM application. It's obviously ok for this application but it should definitely be bigger for a "normal sized" PM application. Maybe 64 kByte would be a better choice.

Programming / Re: Compiling a PM sample with GCC
« on: March 30, 2022, 09:53:52 am »
Actually, GCC wants the os2.h in @unixroot\usr\include and should find it on its own without C_INCLUDE_PATH or -I, if you want to use the one in the toolkit, you need to define USE_OS2_TOOLKIT_HEADERS 1 or edit os2.h around line 39. Should use the define though.
Likewise, if you need  Toolkit header like dive.h, the toolkit headers need to be at the end of the C include search path, C_INCLUDE_PATH=/@unixroot/usr/include;c:/usr/include/os2tk45 or use -Idirafter=c:/usr/include/os2tk45.
Anyways, PMwalker seems to be designed for EMX, after editing the makefile to compile with kLIBC, I get,
Code: [Select]
        gcc -Zomf walker.obj walker.def
weakld: error: Unresolved symbol (UNDEF) '_ClientWndProc'.
weakld: info: The symbol is referenced by:
Ignoring unresolved externals reported from weak prelinker.
Warning! W1058: file ldZXONto.: line(20): protmode option not valid for an OS/2
EMX executable
Error! E2028: _ClientWndProc is an undefined reference
Error! E2044: exported symbol _ClientWndProc not found
NMAKE : fatal error U1077: 'W:\OS2\CMD.EXE' : return code '1'
with this makefile,
Code: [Select]
walker : walker.exe

walker.exe : walker.obj walker.res walker.def
   gcc -Zomf walker.obj walker.def
   rc walker.res

walker.obj : walker.c walker.h
   gcc -Zomf -los2 -c -O2 walker.c -o walker.obj

walker.res : walker.rc step1.ico step2.ico step3.ico
   rc -r walker.rc

Need to read the documentation, probably a define missing.
Hmm, the def file is broken, need to remove the underline prefix so it reads EXPORTS ClientWndProc rather then EXPORTS _ClientWndProc
Edit:, read the readme.txt, it was actually written for a different GCC port, GCC/2, not EMX.

Apparently, decades ago, GCC/2 either did not understand the "_System" keyword as a calling convention or the emx header files did not specify the "_System" keyword in which case the compiler defaults to the "C" calling convention that in turn will lead to an underscore being prepended to the symbol name (thank god, the "C" and the "_System" calling conventions have about the same rules regarding argument passing and stack cleanup ...).
If I now look into \usr\include\os2.h and \usr\include\os2emx.h, everything is fine and gcc.exe will properly resolve the EXPENTRY macro definition to the "_System" keyword.

Programming / Re: Compiling a PM sample with GCC
« on: March 30, 2022, 09:48:34 am »
As Dave suggested, DO NOT use the IBM provided toolkit when it comes to using gcc.exe. Apparently, gcc.exe does not understand some of the specific keywords (like "_Seg16") that the WATCOM and IBM compilers understand.

You should have a \usr\include\os2.h file and, without any further customization, that file will include <os2emx.h> which is basically the "merge" of all individual header files from the IBM toolkit (at least the BSE and PM and WIN related header files). That is by far the easiest way to go for gcc.exe.

I think the IBM provided toolkit files were packaged for those developers that intend to use WATCOM or the IBM provided toolchain (Visual Age C++). Maybe that should have been stated right away ...

Pages: 1 [2] 3 4 ... 64