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 - Mentore

Pages: 1 2 [3] 4 5 6
31
Applications / [ANPM] No repository, no packages
« on: June 21, 2016, 11:09:51 pm »
Hello everybody.
I'm trying to learn to use Arca Noae Package Manager. After installing and rebooting, I opened it up and into the "Repository" window found nothing listed.

Yet, if I try to add a repository from the list provided in the Arca Noae site, the program tell me the repository has already been added. Still there's no packages I can view.

Since I installed (long ago) a somehow broken RPM/YUM and then tried to deinstall it, I wonder if maybe something undeleted could be messing up things.

Ideas, anyone?
TIA
Mentore

32
Programming / Re: Linking problems in compiling a MAME spinoff
« on: April 25, 2016, 11:51:28 am »
For dart.c try.
Code: [Select]
#define INCL_BASE
#define INCL_PM
#include <os2.h>
#include <mmioos2.h>
#include <mcios2.h>

And in your build environment (I have it in config.site)
export 'CPPFLAGS=-idirafter g:/OS2TK45/h'
Adjusting the path to your toolkit as needed

Tried the suggested modifications, I had to edit xtramm.h file to take into account the additions.
Didn't add the CPPFLAGS directive - didn't find a config.site. But still this should have to do only with compiling... Recompiled all with GCC 4.92, still the same linker problems.

This needs a little more investigation, I think.

If I solve this, I'll do a little tests and then it will be time for MAME 0.53 and on until MAME 0.59 - which is the latest before the big emulator source change.

Mentore

Mentore

33
Programming / Re: Linking problems in compiling a MAME spinoff
« on: April 24, 2016, 07:32:18 pm »
Can you also post src\rules.mak and src\os2\os2.mak (not totally sure of the name of the last) and also the defines right before #include <os2.h> and there should also be a #include <mcios2.h> or similar, post the defines right before them as well.
BTW, the -Zmt is harmless and does nothing on kLIBC and you shouldn't need -Zexe when using -Zomf or targeting a executable with a .exe suffix

Weird, I was sure I already attached os2.mak. Oh well, doing this right now together with the other files.
By the way I must admit my memory works bad sometimes. It should have been -Zomf and not -Zexe.

Files attached. Here follows the lines you asked for:
These are defined into os2.c:
#define INCL_DOSPROCESS
#define INCL_DOSSEMAPHORES
#define INCL_DOSDEVICES
#define INCL_DOSDEVIOCTL
#define INCL_WININPUT
#define INCL_DOSMISC



First lines of dart.h:
#include <stdio.h>
#include <string.h>
#include <malloc.h>
#include <stdlib.h>
#include <process.h>
#define INCL_DOS
#define INCL_DOSERRORS
#include <os2.h>


From dart.c / dart.h seems that every reference from mcios2.h is missing... I'll try again later.
Thanks!

34
Programming / Linking problems in compiling a MAME spinoff
« on: April 24, 2016, 05:32:54 pm »
Hello all.

Time allowing, I'm trying to compile / recompile some old discotinued projects.
I recently came across some old MAME sources (until 0.60 I think), and thought it would be an interesting experiment to see if the old MAME 0.37 b14 from Marty Amodeo would work with those more updated sources. I thought, "Well, if that would allow emulating even a single game more, or make the old ones work better, it would be worth the work" and then I started diff-ing the newer sources with the old ones.

You wouldn't believe it but it compiles  8)
Just, it does not link completely... Upon linking it prints these linker errors:

obj/mame/os2/os2.o: Undefined symbol _ss_deregister_all_funcs referenced from text segment
obj/mame/os2/os2.o: Undefined symbol _WindowProc referenced from data segment
obj/mame/os2/dart.o: Undefined symbol mciSendCommand referenced from text segment
obj/mame/os2/dart.o: Undefined symbol mciSendCommand referenced from text segment
obj/mame/os2/dart.o: Undefined symbol mciSendCommand referenced from text segment
obj/mame/os2/dart.o: Undefined symbol mciSendCommand referenced from text segment
obj/mame/os2/dart.o: Undefined symbol mciSendCommand referenced from text segment
obj/mame/os2/dart.o: Undefined symbol mciSendCommand referenced from text segment

Attached is the os2.mak makefile I'm using. It's identical to the old one present in the 0.37 b14 release, I just changed the -Zmt option with -Zexe to make it link with the new gcc from Paul Smedley (trying gcc 5.10 right now). Also the original makefile was not modified.

The obj files are present and I have downloaded, installed and configured the Warp 4.52 toolkit, so from now on it seems I'm stuck here.

BTW: I of course know there's SDLMAME from the great KO Myung Hun and appreciate it really much - also, I know that I cannot port the latest MAME, which architecture has greatly changed. But I love the old MAME GUI and am accustomed to it. Plus, alas, SDLMAME crashes from time to time...

Hope to hear some news from you.
TIA
Mentore

35
General Discussion / Re: Open Source / 2
« on: July 07, 2015, 11:11:28 pm »

What's the plan and how do we make best use of the source code?! Source code doesn't compile itself, someone has to do it and get a project afloat?


Basically with open source, volunteers do what ever interests them (and occasionally what they get paid to do). For example a long time ago I wanted to play an open source game, so I downloaded the source code and the EMX development environment and learned how to compile it. Been learning ever since and still compile stuff such as this SeaMonkey I'm posting this on and when things go good, share the results with the community.

I completely second the views of Dave. I too am involved in porting efforts for some of my little personal passions like 8-bit (mostly Sinclair computers) emulators, but I'm also interested in music typesetting and others (actually I'm struggling to understand Cmake because it's needed by GUIDOlib and other Qt software to compile).

36
Programming / Re: ptrace and QtCreator
« on: June 26, 2015, 09:57:59 am »
Well we do have sys/ptrace.h and it is listed as _ptrace() in emx/syscalls.h but I can only find it in emx.dll.
Look at the above mentioned headers, perhaps try calling _ptrace() instead of ptrace.
Looking at the kLIBC source there is a ptrace.asm file but seems to be from EMX. You might have to ask bird.

So there seems kLIBC still lacks something. I wonder if I got rid of ptrace calls what would happen... Thanks a lot Dave, you're always useful.

Mentore

EDIT: I took a look at an old porting guide (translated in Italian by me) and saw that one of the ptrace calls is useless (PTRACE_TRACEME) under emx, so I decided to try and remove both calls (the other is PTRACE_DETACH, and should just let the process end by itself. Maybe it won't harm to remove it.) I'm keeping notice of these modifications, also thanks to this discussion. Of course, removing ptrace let the compilation continue (until the next error of course ;) )

Just a small note: you know that we have QtCreator 2.2.1 and that there is even a rpm for it?

regards
Silvan

WHA?
Didn't know this. Where can I fetch it from?
To be honest, porting QtCreator is kind of a complex work, so it would have been interesting to complete it. But I'm having a little too many problems, so if there were a newer version available I would gladly welcome it.

Mentore

37
Thanks for sharing.

My non-driver software request will be to try to bring more love to the OS/2 GUI.
I wrote this article on 2011, someone liked it, other not, but I think it is time to improve the GUI and try to revive XWorkplace.

Revive XWorkplace means to put more functionality and more GUI improvements on it, it does not mean only bugfixing. 

Regards

I remember something similar to a flamewar when the discussion went on what "improve the GUI" means. I have to say I'm kind of an "old man" person, and must say I like the OS/2 standard WPS. Actually I'm sure that the object-oriented approach could still be a selling point, rather than its visuals. That said, maybe a little restyling could be useful, but still - I kinda prefer performances over appearance. Mind you, I usually deactivate rounded windows also in Windows and Linux...

38
Programming / Re: ptrace and QtCreator
« on: June 22, 2015, 08:26:20 pm »
Well we do have sys/ptrace.h and it is listed as _ptrace() in emx/syscalls.h but I can only find it in emx.dll.
Look at the above mentioned headers, perhaps try calling _ptrace() instead of ptrace.
Looking at the kLIBC source there is a ptrace.asm file but seems to be from EMX. You might have to ask bird.

So there seems kLIBC still lacks something. I wonder if I got rid of ptrace calls what would happen... Thanks a lot Dave, you're always useful.

Mentore

EDIT: I took a look at an old porting guide (translated in Italian by me) and saw that one of the ptrace calls is useless (PTRACE_TRACEME) under emx, so I decided to try and remove both calls (the other is PTRACE_DETACH, and should just let the process end by itself. Maybe it won't harm to remove it.) I'm keeping notice of these modifications, also thanks to this discussion. Of course, removing ptrace let the compilation continue (until the next error of course ;) )

39
Programming / ptrace and QtCreator
« on: June 22, 2015, 11:58:01 am »
Hello all, kind of a different question. Once sure that Qt programs are compiled, I got back porting QtCreator 2.1 (the latest under Qt 4.7, AFAIK).

I got stuck, still, in compiling qtcreator_process_stub, an utility executable which was present also in the 1.3.1 version of Qt Creator for OS/2.

The source makes use of two ptrace calls, which I had to modify to make it compile (I'm not listing the modifications I'm making: Qt Creator 2.1 is really old, so I don't think it would be possible to include them in the official sources). And it compiles well but fails linking, complaining the absence of _ptrace from symbols.

This is indeed correct: I searched for ptrace in my development tree and found only the ptrace.h neader file - no .c, .cpp, .cc nor library file. Searching in the usual places didn't take me further.

From Wikipedia I'm seeing ptrace is useful but rather obsolete, so I was wondering if there's a ptrace for OS/2 or I have to delete those calls to make our version of QtCreator work. The one who developed the 1.3.1 version for OS/2 would be really of help in this circumstance.

Thanks in advance,
Mentore

40
Hi Mentore,
Quote
The program compiles but doesn't link. If I use -Zomf, the prelinker stops reporting a bunch of undetermined references, while using -Zexe it's g++ (ld) which stops saying it doesn't recognize the -O option. Needless to say, but there's no '-O' option in linker switches.

The rule is that you need to link with -Zomf to pull in OMF libraries which usually have a .lib suffix. With kLIBC -Zomf will also pull in aout libraries (.a suffix). As QT is an OMF build you will always need to at least add -Zomf to LDFLAGS.
-Zexe is hardly ever useful now a days and was introduced for those cases where a *nix makefile targets foo instead of foo.exe. It's better to add $(exeext) to the makefile if needed but most build systems can figure this out due to Windows also needing it. Using -Zomf also seems to create a correct executable with the .exe extension.
The error about -O is part of the command that GCC creates to call LD.

Thanks Dave and all of you. As said before, the problem was solved reworking the .pro file to include all the JSON files. Socializer works a little bad so I consider it a "no-way", but still this confirms I can build Qt GUI programs. By the way, yesterday evening I was able to compile cpik (PIC microcontroller programming software under Qt) which is a VIO software, so it seems everything works fine.

Mentore

41
EDIT: indeed I must have eaten my brains in a moment of hunger!!!  :o I included the header and cpp files, but did not modify the .pro file to compile the .cpp files. I'm feeling such an idiot now...

I'm afraid I'm getting too used to fancy IDEs and similar. Ok, back to work. Thank you! I'll report my results eventually.

Mentore

Aaaaannnd... It worked! Socializer.exe is up and running. And it does quite an interesting job, though it seems unable to load images. Nevermind, it's still a nice step forward in creating new OS/2 software. This makes my evening :)

Mentore

42
Hello all.

I'm getting back to porting Qt programs, but I'm having troubles in linking. Here's the scenario: I decided to port Socializer (facebook QT browser) to try and have a native facebook browser native.

Being a Qt 5 application, I solved the JSON problem with an alternative library - works.

The program compiles but doesn't link. If I use -Zomf, the prelinker stops reporting a bunch of undetermined references, while using -Zexe it's g++ (ld) which stops saying it doesn't recognize the -O option. Needless to say, but there's no '-O' option in linker switches.

I also tried to

I attach here the makefile and the error messages reported. I'm currently using GCC 4.73, but the errors are the same. I even tried to delete all the -Z* linker options, and linking stops complaining it can't find the Qt libraries with errors like this:

U:/usr/i386-pc-os2-emx/bin/ld.exe: No such file or directory for QtGui4

or

U:/usr/i386-pc-os2-emx/bin/ld.exe: No such file or directory for QtWebKit4

but the library files (.lib files) are there. I'm really puzzled by this behavior. (Of course it's my ignorance on how gcc / ld work.)

according to the error.txt it doesn't find the JSon stuff. did you add the library to link with -ljson.lib or such?

I know it seems so, but still - the software package I used to allow the JSon functionalities does not contain a library. Indeed I have to investigate further this issue, but even the documentation does not talk about a library file.

EDIT: indeed I must have eaten my brains in a moment of hunger!!!  :o I included the header and cpp files, but did not modify the .pro file to compile the .cpp files. I'm feeling such an idiot now...

I'm afraid I'm getting too used to fancy IDEs and similar. Ok, back to work. Thank you! I'll report my results eventually.

Mentore

43
Hello all.

I'm getting back to porting Qt programs, but I'm having troubles in linking. Here's the scenario: I decided to port Socializer (facebook QT browser) to try and have a native facebook browser native.

Being a Qt 5 application, I solved the JSON problem with an alternative library - works.

The program compiles but doesn't link. If I use -Zomf, the prelinker stops reporting a bunch of undetermined references, while using -Zexe it's g++ (ld) which stops saying it doesn't recognize the -O option. Needless to say, but there's no '-O' option in linker switches.

I also tried to

I attach here the makefile and the error messages reported. I'm currently using GCC 4.73, but the errors are the same. I even tried to delete all the -Z* linker options, and linking stops complaining it can't find the Qt libraries with errors like this:

U:/usr/i386-pc-os2-emx/bin/ld.exe: No such file or directory for QtGui4

or

U:/usr/i386-pc-os2-emx/bin/ld.exe: No such file or directory for QtWebKit4

but the library files (.lib files) are there. I'm really puzzled by this behavior. (Of course it's my ignorance on how gcc / ld work.)

44
My priorities are having a decent browser and good multimedia (especially video) support.
So I've learned that I'm not a programmer but can still learn enough that I'm posting this with OS/2 SeaMonkey 2.28 (currently probably the only one in the world) and regularly test FFmpeg and even libav, including contributing my test results back upstream so they don't remove us. (fate.ffmpeg.org and fate.libav.org and do the odd fix. These are the bases of most of our (and most other open source)  multimedia support.
Even us non-programmers can work to have software working on our platform of choice.

I completely second what Dave is saying, adding music software to the list.

Mentore

45
Hi Mentore

The reason that OS/2 code up to OS/2 1.3 works on NT/2000 is the OS/2 subsystem those operating systems contain. Remember that M$ were very involved in OS/2 up to and including 1.3 so I guess it was to their benefit that their early OS/2 apps could run on Windows NT/2000.


Regards

Pete

All true AFAICR. The IBM staff completely rewrote the window management after the IBM / MS split. IIRC, they also switched the pure PM programming interface from FAR PASCAL call scheme to C call scheme (indeed I saw many FAR PASCAL calls in Windows code some year ago, for and old Win16 program ported on Win32).

Pages: 1 2 [3] 4 5 6