Messages

31

Applications / Re: Unzip Version 6.0 hangs when booting to a commandline

« on: July 30, 2024, 11:10:13 am »

Thanks Dave,

but your test build hangs in the very same way. What I now found out: if it hangs and if I hit Ctrl-C, after about 20 seconds or so, the program will be terminated. This however only works once. If I try a second time, the system hangs solid.

What I can also observe is quite some disk activity if I hit Ctrl-C for the first time (until the program finally terminates). I'll have to check if POPUPLOG.OS2 is written ...

32

Applications / Re: Unzip Version 6.0 hangs when booting to a commandline

« on: July 29, 2024, 03:52:33 pm »

Could unzip or more likely, one of its dependents have WINDOWAPI declared in a DEF file? I quickly looked at the source of unzip and the def file hasn't been changed in ages and is simply, https://github.com/bitwiseworks/unzip-os2/blob/master/os2/unzip.def

Code: [Select]

NAME WINDOWCOMPAT NEWFILES
DESCRIPTION 'The world-famous Info-ZIP unarchiving utilities'
; SEGMENTS
;   _MSGSEG32 CLASS 'CODE'

Not sure if it is currently used.

But the DEF file says WINDOWCOMPAT and that is the correct value to use.
But NEWFILES is suspicious. At least, it should no longer be necessary under OS/2 32-bit.

33

Applications / Re: Unzip Version 6.0 hangs when booting to a commandline

« on: July 29, 2024, 03:49:40 pm »

The problem is not that a DLL could not be found as that should show up as a load error.

The problem is that starting unzip.exe simply hangs the (boot) commandline, a simple "unzip.exe" will not even show the help text (listing the options).

As others have already stated, the older UNZIP 5.52 is linked against the very basic OS/2 DLLs (like DOSCALLS, MSG etc.) and works just fine.

34

Applications / Re: Unzip Version 6.0 hangs when booting to a commandline

« on: July 28, 2024, 08:05:21 pm »

As I said, the used LIBPATH is the same for the commandline boot and the operational boot. I also do mot get an error on missing DLLs.

35

Applications / Unzip Version 6.0 hangs when booting to a commandline

« on: July 28, 2024, 01:16:25 pm »

I recently had the need to boot to a commandline (hitting F2 on boot) and to use UNZIP to overwrite a couple of files that would prevent proper system operation.
However, when I called the "unzip.exe" version 6.00 that is installed via YUM, the bootup commandline would hang and the unzip help screen would never show up.
When I instead used the "unzip.exe" version 5.52 that is still in my ECS\BIN subdirectory, it would properly work without such a problem. I am sure it is not a DLL loading problem as the LIBPATH setting is the same as for the regular boot, but of course, the newer UNZIP uses different DLLs (gcc, libcn0) than the older version (which directly uses the OS/2 API).

Anyone knows what's going on or how to fix that ?

Lars

36

Multimedia / Re: Improvement in Webcam support

« on: July 26, 2024, 11:47:00 am »

Hello

I will have to re-test some webcams that I have around.
This is the list: https://www.os2world.com/wiki/index.php?title=Category:Cameras

I don't remember if I ever made an USB Webcam Microphone work with ArcaOS. Was it possible? if so, anybody remember the steps?

Regards

I think the problem will be that the audio interface will be supported by USBAUDIO.SYS / USBAUD2.SYS but the video interface will be supported by USBCALLS/libusb/libuvc as we do not have a dedicated USB VIDEO driver.

And therefore, the audio and video data streams are not correlated or would need different means to correlate them as in that case, audio should also be handled by USBCALLS/libusb and then the two data streams somehow bundled in a container (I think that was what matroschka was good for).

37

Multimedia / Re: Improvement in Webcam support

« on: July 25, 2024, 05:56:46 pm »

I had helped porting libuvc (that in turn makes use of libusb). Whatever app uses libuvc should do. I have a test app from somewhere that I used with my "Logitech QuickCam Fusion" camera (0x046d == desc.idVendor) && (0x08c1 == desc.idProduct) where the camera claimed to not be UVC compliant (it claimed to be vendor specific) but in fact it was (as a workaround, I added a hack in libuvc to support that camera).

https://github.com/bitwiseworks/libuvc-os2

38

Programming / Re: GCC/G++ - how to export global variable without underscore?

« on: July 16, 2024, 07:47:31 am »

OS/2 32-bit calling convention for public interfaces should always be syscall in order to avoid all these name decoration problems. Depending on compiler, this is _System or syscall or _syscall and proper header files for the compiler will map that to APIENTRY and also EXPENTRY.
Note: OS/2 16-bit calling convention is Pascal. There are technical reason for using Pascal in 16-bit code (you need a calling convention where the called function cleans up the stack in order to support call gates. And Pascal is a calling convention that expects the called function to clean up the stack). Pascal uppercases all symbols ...

As has been stated, the calling convention also applies to data variables (only for the naming, of course. Nothing is called from a data variable). And before you start fuzzing with tools,aybe the easiest way is to use:
EXPENTRY char * myGlobalVar;
or (I cannot remember)
char * EXPENTRY myGlobalVar;

and to then use the def file to export a symbol named myGlobalVar because the syscall calling convention neither decorates names (as C callin convention does) nor uppercases names (as the Pascal calling convention does).
It will leave the symbol name untouched.

It should be obvious that on the accessing side, you will need to also properly use the calling convention:
extern char EXPENTRY *theGlobalVar;

39

Applications / Re: Experiment: Moving OS/2 Graphic/MM Resources

« on: July 12, 2024, 07:54:26 pm »

The Mouse Setup object is managed by WPS class "WPMouse". That class is implemented in DLL WPCONFIG.DLL.

If I unpack WPCONFIG.DLL, I find this text string in it:
STARTFOLDER=?:\OS2\POINTERS

It is therefore hard coded and cannot be changed.

Note: The STARTFOLDER is a setup string for the "wpclsFindOneObject" class method of WPObject for the top level folder to search from. So you will only be able to search under that folder.

40

Events / Re: Warpstock Europe 2024 Follow Up

« on: June 20, 2024, 10:34:02 am »

Maybe your system is old enough to foresee use of a 32-bit OS, just like mine that is about 7 years old.
The problem with (many ?) new systems is that they reserve large amounts of physical address space below the 4 GB physical boundary for PCI use (and therefore not for RAM).
I think I read somewhere that this was done for older HW that can only address below the 4GB physical boundary but needs a large memory space, for example older graphics cards with very large screen apertures and memory space to hold textures and the like.
That makes much sense if a 64-bit OS is in use but severly restricts a 32-bit OS that has to rely on that memory space to be (mostly) addressable for RAM.
The reservation of that physical address space is static to cater for a 'worst case'.

41

Applications / Re: RPM Repository: IBM OS/2 Toolkit.

« on: May 24, 2024, 09:51:45 am »

I would not assume exactly the same code. However, I would always prefer the files in \OS2\DLL over those in \OS2TK45\SOM\COMMON\DLL.

People not installing the toolkit (which should be assumed to be the majority) need a working system.

42

Programming / Re: ClassiCube porting thread

« on: May 11, 2024, 09:45:52 am »

AN will answer you that it is not their SW.
The author is Sergey (glassman). The best you can do is find his email address or contact Eugene Gorbunoff who would know how to contact Sergey.

Sorry, meant to say Dmitry (Steklenev) and not Sergey.

Anyway, he has a webpage that also allows contacting him directly, maybe that is easier and also more efficient: https://5nets.ru/

There is a feedback link: https://5nets.ru/feedback/


The difference I found between the initial version of FOC contained in eCS (where it does not crash) and that in ArcaOS (where it crashes):

The install script of eCS forwards the functions "WinFileDlg","WinDefFildDlgProc","WinFreeDlgFileDlgList" from PMCTLS.DLL to PMEX.DLL but it does not "clone" them, so the original routines in PMCTLS.DLL are not accessible anymore. PMEX.DLL in turns calls into FOC.DLL.

ArcaOS on the other hand does not only forward the original functions from PMCTLS.DLL to PMEX.DLL but it also "clones" them to another ordinal so that the original procedures can be called from foc.dll, for example.

That seems to be the difference that makes FOC crash under ArcaOS but work ok under eCS. As I said, I have no probs under eCS and even regedit2.exe works just fine with FOC even though AN puts it on the exclusion list.

43

Programming / Re: ClassiCube porting thread

« on: May 10, 2024, 11:38:25 am »

AN will answer you that it is not their SW.
The author is Sergey (glassman). The best you can do is find his email address or contact Eugene Gorbunoff who would know how to contact Sergey.

44

Programming / Re: ClassiCube porting thread

« on: May 09, 2024, 03:20:15 pm »

As a quick test, back up and replace the files as contained in the ZIP file.
Explanation to follow.

45

Programming / Re: ClassiCube porting thread

« on: May 09, 2024, 11:37:51 am »

Actually, "PMEX.DLL" is dynamically binding to and calling into "FOC.DLL" to do its job and that is part of the "Win" eCosoft runtime.

I am beginning to believe that eCoSoft "win","base","net" runtime has been broken in later versions.

I have 2018.11.8.0 installed for "Net" and "Win" and 2017.11.15.0 for "Base". I do not experience crashes but (after registering the WPS class for FOC configuration, gleaned that from the ArcaOS installation), after setting exception in the FOC exception list, it has no effect/is ignored.

You can find older versions here:
https://en.ecomstation.ru/projects/developer/toolkit/?action=runtime-old