Messages

1

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: January 17, 2025, 10:08:22 am »

Cool, so the latest dosbox-x works fine on Arca then?

Hey J,
currently I haven't still tried again with Dosbox-x. As Dave said, there are many other problems with it so this is just one of them (and only on my VM, I'm fairly sure Dave has his PC's clock running fine).

I'm in the process of reorganizing all the source code I have on my personal Github repository, together with some sponsoring information to keep going with OS/2 related software (ports and native).

Mentore

2

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: January 15, 2025, 03:15:51 pm »

Hello all,
I'm having a real PITA trying to port DosBox-x under OS/2 with the latest tool (Gcc 9.2.0, the rest is up-to-date with ANPM netlabs repo).
-- snip --

Hi everyone, I finally found the problem! Thought it would be useful to know.
Fact is, make checks wether configure script is more recent than configure.ac and - in case - it recreates the configure script calling --recheck on config.status. BUT: I didn't notice thay my VM was setting a fixed system date at october 24, so every time I rebuilt the script it would still be older than configure.ac... Thus the loop.

I've issued a DATE command to reset time and now I'm compiling an Atari 800 emulator on SDL. Gonna let you know what's happening and maybe even give another try to Dosbox-x.

Mentore

3

Article Discussions / Re: Asking OS/2 things to OpenAI - Fun and maybe Insightful.

« on: January 09, 2025, 08:15:29 am »

Thought I'd ask Gemini a similar question. Larger example, includes where the example came from, missing #define INCL_WIN.
Actually, looking at the source, it is old MS Programming library v1.3, 16 bit API?

Code: [Select]

#include <os2.h>

/* Window class structure */
static HAB hab;
static HWND hwndFrame;

/* Window procedure */
MRESULT EXPENTRY ClientWndProc(HWND hwnd, ULONG msg, MPARAM mp1, MPARAM mp2) {
    switch (msg) {
        case WM_PAINT: {
            HPS hps;
            RECTL rc;

            WinQueryWindowRect(hwnd, &rc);
            hps = WinGetPS(hwnd);
            GpiSetColor(hps, SYSCLR_BLUE);
            GpiFillRect(hps, &rc);
            WinReleasePS(hps);
            break;
        }
        case WM_DESTROY:
            WinPostMsg(hwndFrame, WM_QUIT, 0, 0);
            break;
        default:
            return WinDefWindowProc(hwnd, msg, mp1, mp2);
    }
    return 0;
}

/* Frame window procedure */
MRESULT EXPENTRY FrameWndProc(HWND hwnd, ULONG msg, MPARAM mp1, MPARAM mp2) {
    switch (msg) {
        case WM_COMMAND:
            switch (SHORT1FROMMP(mp1)) {
                case IDM_QUIT:
                    WinPostMsg(hwnd, WM_CLOSE, 0, 0);
                    break;
            }
            break;
        case WM_CLOSE:
            WinDestroyWindow(hwnd);
            break;
        default:
            return WinDefWindowProc(hwnd, msg, mp1, mp2);
    }
    return 0;
}

int main(VOID) {
    HAB hab;
    HMQ hmq;
    HWND hwndFrame, hwndClient;
    QMSG qmsg;

    /* Initialize Presentation Manager */
    hab = WinInitialize(0);
    hmq = WinCreateMsgQueue(hab, 0);

    /* Register window classes */
    WinRegisterClass(hab, "MyClientClass", ClientWndProc, CS_SIZEREDRAW, 0);
    WinRegisterClass(hab, "MyFrameClass", FrameWndProc, CS_SIZEREDRAW, 0);

    /* Create frame window */
    hwndFrame = WinCreateWindow(
        HWND_DESKTOP,
        "My Frame Window",
        "MyFrameClass",
        WS_VISIBLE | WS_BORDER | FCF_TITLEBAR | FCF_SYSMENU | FCF_MINMAX,
        0, 0, 200, 100,
        HWND_DESKTOP,
        HWND_TOP,
        hab,
        NULL,
        NULL
    );

    /* Create client window */
    hwndClient = WinCreateWindow(
        hwndFrame,
        "My Client Window",
        "MyClientClass",
        WS_VISIBLE,
        0, 0, 200, 100,
        hwndFrame,
        HWND_TOP,
        hab,
        NULL,
        NULL
    );

    /* Message loop */
    while (WinGetMsg(hab, &qmsg, NULL, 0, 0)) {
        WinDispatchMsg(hab, &qmsg);
    }

    /* Clean up */
    WinDestroyWindow(hwndFrame);
    WinDestroyMsgQueue(hmq);
    WinTerminate(hab);

    return 0;
}

Explanation:

    Include Header:
        #include <os2.h>: Includes the necessary header file for OS/2 Presentation Manager functions.
    Global Variables:
        hab: An anchor block handle, used to identify the application to Presentation Manager.
        hwndFrame: A handle to the frame window.
    Window Procedures:
        ClientWndProc: Handles messages for the client window.
            WM_PAINT: Fills the client area with blue color.
            WM_DESTROY: Posts a quit message to the frame window.
        FrameWndProc: Handles messages for the frame window.
            WM_COMMAND: Processes menu commands (not implemented in this example).
            WM_CLOSE: Destroys the frame window.
    Main Function:
        Initialization:
            WinInitialize: Initializes Presentation Manager and returns an anchor block handle.
            WinCreateMsgQueue: Creates a message queue for the application.
        Window Registration:
            WinRegisterClass: Registers the window classes for the client and frame windows.
        Window Creation:
            WinCreateWindow: Creates the frame and client windows with the specified attributes.
        Message Loop:
            WinGetMsg: Retrieves messages from the message queue.
            WinDispatchMsg: Dispatches messages to the appropriate window procedures.
        Cleanup:
            WinDestroyWindow: Destroys the frame window.
            WinDestroyMsgQueue: Destroys the message queue.
            WinTerminate: Terminates Presentation Manager.

Note:

    This is a basic example and can be extended to include more features such as menus, controls, and more complex window interactions.
    You'll need to use an OS/2 development environment (such as IBM Visual Age for C++) to compile and run this code.
    This code demonstrates the fundamental concepts of creating and managing windows in the OS/2 Presentation Manager environment.

This example provides a starting point for creating OS/2 Presentation Manager applications. You can further explore the Presentation Manager API to implement more advanced features and create sophisticated graphical user interfaces.

    https://github.com/spacerace/MPL


Interesting. It doesn't use WinCreateStdWindow, so maybe you're right and it's not a 2.x PM code. That said, I see no big mistakes. Not surprising though - GPT and other AI tools are really useful in these cases, where there's a non-ambiguous code base to use. It hallucinates, but behaves better than in other topics.

Mentore

4

Applications / Re: QT4 problem

« on: December 31, 2024, 07:59:07 am »

Since there has been a lot of traffic about QT on here I might as well add my problem.  Some time ago I had my computer messed up by friends trying to load windows programs on it.  I have almost got it back to what it was except for CoolReader 3 which requires QT4 runtime which I have.  Unfortunately, although it loads nothing is shown on the screen and since this is the program that displays all my e-books I am at a loss when I  want to relax with a good story. 

Any advice that helps me get CoolReader3 back up and running will be very much appreciated.

Hi Ivan, I think the first thing to do is check if Qt4 is complete or lacks something.
You can try to launch coolreader via command line to see if it prompts some error message, like missing or mismatched DLLs or other wrong files.
You may also try to use PMDLL on CoolReader.exe (or whatever is the executable name), if you're more experienced, and see what DLL does it refer. IIRC, PMDLL warns about missing DLLs.

Mentore

5

General Discussion / Re: OS/2 - ArcaOS Santa's List for 2025

« on: December 11, 2024, 08:05:45 am »

Paul,

  Don't know if it helps, but Ko Myung-Hun just did a new meson: https://github.com/komh/meson-os2/releases/tag/1.6.0

Regards,

Whoa, didn't find it before. I've got at least two interesting projects which build with meson. Currently I've got no time to work on ArcaOS, but willing to start again asap.
Mentore

6

General Discussion / Re: OS/2 - ArcaOS Santa's List for 2025

« on: December 09, 2024, 08:28:26 am »

What about mesaGL? I don't remember its current status. A slow renderer would still be better than no renderer at all...
Mentore

I visited it, seven years back, and got it compiling and the examples ran good. [https://github.com/OS2World/LIB-GRAPHICS-WarpMesaGL.
Problem is that it is old. Gives gl.h while now it is gl2.h that is required.

sh*t. I was hoping there was a better solution.
AFAIK also PortableGL has its limits (TinyGL is good but even more limited).

Mentore

7

General Discussion / Re: OS/2 - ArcaOS Santa's List for 2025

« on: December 06, 2024, 08:06:24 am »

OK, it uses GTK. That would be a huge job to port, much like Qt. While nice to have, I can't imagine it being ported.
It can also run in a browser, so that might be a possibility, though even for that there's a good chance it needs something we don't have, webgl or node.js.

Might be possile to use odin to build GTK - but if it needs opengl, etc we're royally screwed. nodejs is working well enough to build chromium....

What about mesaGL? I don't remember its current status. A slow renderer would still be better than no renderer at all...
Mentore

8

Games / Re: RetroArch Port

« on: November 26, 2024, 08:17:55 am »

Hello Mentore

Just one extra thing. can you put your ported version of RetroArch in some repository (like Github - https://github.com/MentoreSiesto?tab=repositories)
If possible I want to learn from your makefile, and I think it will be nice for everyone to check it out.

Regards

I'll check my sources and do that asap. One thing I need to put in my TODO list is to get those sources in my repositories, indeed.

Mentore

9

Games / Re: RetroArch Port

« on: November 19, 2024, 07:51:12 am »

Hi.

I did understand, that you disabled this stuff. My point was that you should not concern yourself to much, with getting this to work. Cores will be enough work by themselves ;-)

Right you are 

Mentore

10

Games / Re: RetroArch Port

« on: November 18, 2024, 10:51:44 am »

Well I understand, that on an RaspberryPi, you would want that functionality, but I would just #ifdef Discord out.
Downloading of cores would also mean, you or someone would have to host the OS/2 specific core files. I don't know that it would be worth the hassle.
Rather I would have some RPMs or WPIs, which install some cores.

Hi Jochen,
As written before I ruled out Discord and some other options because I hadn't the needed libraries/time to port them - can't remember well what were my choices (Yes I'm a little chaotic, I should document my steps when I make them).
So Discord and maybe some other options are missing.
As for cores, I'd like to understand better if they have to be ported - I guess the answer is "yes", so downloading them via our RetroArch port might be cumbersome if we would rely on the "official" repository.
Guess I'll have to investigate a little further - for now I am content of being able to port on OS/2 such a beast, but indeed at the moment is just useless - so better try to take a step further.

Mentore

11

Games / Re: RetroArch Port

« on: November 15, 2024, 11:05:16 pm »

Hi Martin,
the next few weeks will be truly a handful both at work (where I have an ArcaOS VM) and in theatre, but I'll see what I can do. RetroArch would be really cute to have. It was tricky to port it due to its SSL libraries which rely a lot on IPv6 but I managed somehow - and I feel OS/2 would profit a lot of a new TCP/IP stack (which, I'm afraid, we will not see).

Mentore

Which feature needs networking? Is it for downloading core etc.?

As far as I know it's not only for downloading cores but also for networked game and (not in this version) Discord chat. I couldn't implement Discord due to some libraries missing (don't remember the details right now).

Mentore

12

Games / Re: RetroArch Port

« on: November 15, 2024, 08:26:32 am »

Hello Mentore

I don't know if you can port some of the basic cores for NES and SNES that are very common and don't require a console BIOS to be downloaded by the user.

Regards

Hi Martin,
the next few weeks will be truly a handful both at work (where I have an ArcaOS VM) and in theatre, but I'll see what I can do. RetroArch would be really cute to have. It was tricky to port it due to its SSL libraries which rely a lot on IPv6 but I managed somehow - and I feel OS/2 would profit a lot of a new TCP/IP stack (which, I'm afraid, we will not see).

Mentore

13

Games / Re: RetroArch Port

« on: November 14, 2024, 07:45:12 am »

Hello

Mentore ported RetroArch (1.19.1) and I just noticed today, which is awesome.

I installed "yum install SDL2 SDL2_net" it runs but I don't know if the cores (emulators) need also to be ported, or it will be download the cores from a site.

I tried to download the Core list from the app, but it is not downloading. Remains in 0%.

Anyone here with more experience with RetroArch?

Regards

Hi Martin,
this I have to investigate deeper. I also tried to download some core and, looking at the RetroArch homepage, it almost seems like cores have to be ported too. I'll have a look at what retroarch cores are - but many things point me in that direction (last of them, there are github repositories for cores).

Mentore

14

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: November 07, 2024, 07:51:49 am »

As an example. this code compiles fine with DosBox,

Code: [Select]

    FSINFO fsinfo;
    ULONG drivenumber = drive[0];
    if (drivenumber > 26) { // drive letter was lowercase
        drivenumber = drive[0] - 'a' + 1;
    }
    APIRET rc = DosQueryFSInfo(drivenumber, FSIL_VOLSER, &fsinfo, sizeof(FSINFO));
    if (rc == NO_ERROR) {
        bool cdrom = false;
Whereas with DosBox-x, the error is,

Code: [Select]

drive_cache.cpp: In member function 'void DOS_Drive_Cache::SetBaseDir(const char*, DOS_Drive*)':
drive_cache.cpp:159:32: error: cannot convert 'DOS_Drive' to 'ULONG' {aka 'long unsigned int'} in initialization
  159 |     ULONG drivenumber = drive[0];
      |                         ~~~~~~~^
      |                                |
      |                                DOS_Drive
drive_cache.cpp:161:32: error: no match for 'operator-' (operand types are 'DOS_Drive' and 'char')
  161 |         drivenumber = drive[0] - 'a' + 1;
      |                       ~~~~~~~~ ^ ~~~
      |                              |   |
      |                              |   char
      |                              DOS_Drive


Thanks a million for all of these contributions on your side, Dave. It seems DosBox-x is not viable - too bad, but hey, I did try at least
Now back to RetroArch. I'll try to delve deeper into the network part and see if I can go a little further than my first attempt (there are some interesting TLS libraries, I shall try them all).

Mentore

15

Programming / Re: DOSBox-x - infinite loop in configure/make

« on: November 06, 2024, 12:02:46 pm »

Better to edit configure.ac, about line 368 and remove the CXXFLAGS line, the -Zmt on the LDFLAGS line and add -Zomf -Zhigh-mem -Zbin-files there. There's also a hard dependency on sdl-net in configure.ac you might want to comment out.
Then run "bash autogen.sh" rather then sh autoreconf then try configure.
There's other emxism's in the source to watch out for as you go.

OK, tried to modify it and no - still loops; make keeps calling configure. I'll have to delve deeper into this.
Mentore