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 ... 61
... and in that case you will need to specify -Zomf as a compiler switch because there is nothing massaging this switch into the linker ...

Looking at the map file I see at the failing address watcoms MemAllocator -
Code: [Select]
Module: P:\watcom/lib386/os2\clib3r.lib(nmemneed.c)
0002:0000ad60  __nmemneed_
Module: P:\watcom/lib386/os2\clib3r.lib(mem.c)
0002:0000ad70  __MemAllocator
0002:0000ae20  __MemFree
Module: P:\watcom/lib386/os2\clib3r.lib(grownear.c)
Seems a bit strange to me. Puzzling....

That does not mean much. You might have a bunch of functions marked as "static" which never show up in the map file and consequently, they don't show up in the .XQS file. On the other hand, "__MemAllocator" and "__MemFree" are close enough to each other to not fit in yet an additional "static" function.

The full exceptq will give you the source file and line which is very convenient and even works if the trap location is in a function marked as "static".

What I think is a possible problem is if you use "malloc" from a DLL/EXE using its version of the RTL and therefore heap management and then use "free" from a DLL/EXE using a different version of the RTL and therefore heap management.
That can be a problem if for example you allocate a block of memory from an executable written with Watcom and then pass on that pointer to a DLL written with GCC to have it freed. That can blow your app. Know your enemies.

And then, for Watcom, it's about using the register based RTL vs. the stack based RTL. You are using the register based RTL and hopefully you have been compiling your code to use register based argument passing (but I would think so, otherwise you'd have a whole bunch of problems and not only one ...).

For Watcom I find this:

Code: [Select]
Open Watcom Executable Strip Utility Version 2.0beta1 Limited Availability
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See for details.
Usage: wstrip [options] input_file [output_file] [info_file]
options: (/option is also accepted)
        -q     don't print informational messages
        -n     don't print warning messages
        -r     process resource information rather than debugging information
        -a     add information rather than delete information

        input_file:  executable file
        output_file: optional output executable or '.'
        info_file:   optional output debugging or resource information file
                     or input debugging or resource information file

Something like:
wstrip PCM9362_AnetCom.exe PCM9362_AnetCom.exe PCM9362_AnetCom.dbg

Looks like "info_file" would then contain that debugging data. However, I am not sure if Watcom will do at all because it does not produce either the (proper) Codeview or HLL debug format that exceptq would understand. Unless excdeptq was written to also support the Watcom debugging format but I doubt that. You will have to try out.

It's something like this:

emxomfstrip -D PCM9362_AnetCom.dbg PCM9362_AnetCom.exe

or, if you want to remove the debug info from the exe and only have it in the .DBG file:

emxomfstrip -D PCM9362_AnetCom.dbg -o PCM9362_AnetCom.exe PCM9362_AnetCom.exe (I believe)

I don't know what the .XQS files are for or what they do but nowadays I find .DBG files. Looking into them, they obviously contain the stripped debug info. I would expect that you need these files if you want to have source file and linenumber information printed out in your EXCEPTQ report.
Can you build your app, strip the debug info and have that placed into a .DBG file with the same filestem as your executable binary ?

Utilities / Re: VirtualBox, OS/2 guest, running with > 1 core. Success !?
« on: January 22, 2022, 11:45:49 am »
Unfortunately, even though > 1 core seems to work without hanging the system, the performance is hampered by I don't know what. After some time of usage, the system gets slower and slower and eventually, 1 core is then faster than > 1 core.
I'll revert back to the W4 kernel as an alternate boot config. That will limit to 1 core anyway and I'll keep around the main boot config with the SMP kernel and ACPI so that I can test in the future.

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 21, 2022, 10:00:21 am »
Yes, but how does the video (and audio) stream get to an application such as a web browser? And how does the application control the camera (perhaps focus for example), get capabilities and such? It does look like Mozilla will handle the transcoding and likely the muxing
Guess I could enable webrtc and see where the compile breaks.
Yes, we need an application that actually uses libuvc. As to controls, the libuvc example app schedules an irq in transfer in addition to the iso in transfers for the video data. The irq endpoint then delivers a message when you pres/release the camera button (at least it does for my camera). The application will need to decode that message to find out if a button has been pressed or released (2 different messages) and if yes, which one in case there are more buttons than one (I hope this is standardized).

As far as I understood BWW, the new browser (which is currently on hold) will use libuvc to get data and send over www and hopefully display received data in a browser tab (?) but maybe I got that wrong.

But it would be great if we could port webrtc to work on our platform.

Utilities / VirtualBox, OS/2 guest, running with > 1 core. Success !?
« on: January 21, 2022, 07:45:49 am »

my past experience with Virtualbox and running an OS/2 guest with > 1 core was that VirtualBox would hang very quickly and I always had to revert back to 1 core.

With Virtualbox 6.1.32 which was recently released, I find this in the change log:
VMM: Workaround for OS/2 guest unstability on newer AMD CPUs due to a missing TLB flush in OS/2 (bug #20625)

My host OS is Win 10 and my CPU is an Intel 8-core but I thought "so what, just give it a try" and I activated 2 cores for the OS/2 guest virtual machine.
And lo and behold, it seems to work ok. As a test, I rebuilt my complete USB driver stack which starts quite a few parallel processes (I think nmake starts multiple processes if the dependencies allow) and that always used to hang pretty quickly in the past when using > 1 core.

So, I believe this not just fixes a problem with AMD CPUs but a general problem with handling the TLB, at least for OS/2 guests (I suppose this somehow interacts with OS/2 memory management where the OS/2 memory management might have some pecularities which make it distinct).

Can somebody confirm that ?

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 21, 2022, 06:30:05 am »
WebRTC is probably the solution for video conferencing. QT5 supports it, as well as our Firefox. Of course it needs to be coded for our platform and currently as far as I know, only USB audio supports microphone input.
libuvc is totally generic in handling video input: it effectively sets up iso in transfers for the video in endpoint to receive video data. It could do the very same for the audio in endpoint to receive audio data but it does not (I think but I would need to check).
This is completely independent of any OS/2 audio drivers. It works via libusb which in turn works via USBCALLS and USBRESMG.

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 20, 2022, 08:09:37 pm »
I also think WiFi would be a high priority. Both WiFi and dual screen have been mentioned by Arca Noae on their roadmap.

I'd add an item that is partly software and partly hardware -- I'd like to see video conferencing on our platform. This also seems to be in progress, but at BitWise and in discussions here. That is both audio and video hardware.

Funny enough, the video support is better under VirtualBox then it is on plain HW. My built-in notebook webcam is detected in VirtualBox as a USB video device with bulk endpoint. The combination of libuvc+libusb has no problems using it. What we now need is a port of a Linux web app based on QT (for display) and  livuvc+libusb (for the data streaming). I am not yet clear about audio (synchronized to video).
The OS/2 MMPM subsystem is built upon streams that can be synchronized. But if you use libusb + libuvc, they know nothing about the OS/2 MMPM streaming (manager). You just read video and potentially audio directly from the device but then, these are not synchronized.


Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 20, 2022, 08:54:11 am »
Yes, I set it with NO_ERROR. At first I was worried about the scope of rc as it is used throughout the file.  Though thinking about it, I'm not sure what happens if there is an error, whether in the memory allocation or what DosQueryPathInfo() returns, perhaps it should have been passed somehow to the class, nsLocalFile::SetPermissions(uint32_t aPermissions). about line 1931
In C, if you declare a variable in a block ("{" ... "}"), it is only known in that block (and effectively becomes a stack variable unless you declare it as "static" in which case it will be placed into the default data segment with a "madeup" unique name).
If you declare a variable outside of any block, then it is known throughout the whole source file (module). That way, you can have "rc" multiple times in a file but they are only declared locally.

The routine you are pointing to looks reasonable. Obviously, "NS_IMETHODIMP" is a define for something like "ULONG APIENTRY" or "unsigned long _System" or "unsigned long _cdecl" or such. In other words, a combination of return value and calling convention (you would need to search the header files for it ...).
By the way: "ConvertOS2Error" can also deal with a NO_ERROR = 0 on entry, therefore:
Code: [Select]
    if (rc)
        return ConvertOS2Error(rc);

    return NS_OK;
can just become:
Code: [Select]
     return ConvertOS2Error(rc);

Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 19, 2022, 09:18:36 am »
Thanks, that worked, except the EA's are still there. Probably need to strip them later when the tmp file gets moved to the permanent name in download.cpp

You should also preset the "rc" Variable with a decent value. Just like the initial example from Alexander Taylor.

Applications / Re: SeaMonkey downloads and Unix permissions
« on: January 18, 2022, 12:09:19 pm »
Change both input params to "const char *", change function logic to ensure that you ALWAYS return a value (currently, you don't).

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: January 15, 2022, 09:06:23 pm »
USBKBD.SYS and USB MOUSE.SYS contain a HID descriptor parser.
There is nothing like that in USBCALLS.DLL or USBRESMG.SYS, at least not in my version.
If they did add something, I'll be looking forward for them to publish the interface.
I guess they added functionality so that the whole USB bus hierarchy can be queried. It's all drifting apart.

Games / Re: DOS VDM - USB and Game port Gamepad support
« on: January 15, 2022, 10:50:27 am »
What if any was changed from USBCALLS/USBRESMG version 12.10 to version 12.11?
If would be helpful if AN or you would share that secret with us. Otherwise, on the long run, it will become impossible to implement anything using USBCALLS .

Pages: [1] 2 3 ... 61