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 - Dave Yeo

Pages: [1] 2 3 ... 224
Networking / Re: GenMU WIFI driver for Ralink 301
« on: January 27, 2022, 07:47:23 pm »
The common problem is the inability to operate the radio. Can't turn the radio on and off, can't get a connection.
IIRC, the wpa_supplicant is for connecting to encrypted WiFi and without it, can only connect to an open system.

Networking / Re: Squid Cache
« on: January 27, 2022, 08:31:57 am »
Hi Digi,
Code: [Select]
Y:\>yum provides gssapi.dll
heimdal-libs-1.5.3-1.oc00.i386 : Heimdal kerberos shared libraries
Repo        : arcanoae-rel
Matched from:
Other       : gssapi.dll

heimdal-libs-1.5.3-2.oc00.i386 : Heimdal kerberos shared libraries
Repo        : arcanoae-rel
Matched from:
Other       : gssapi.dll

heimdal-libs-7.7.0-4.oc00.i686 : Heimdal kerberos shared libraries
Repo        : installed
Matched from:
Other       : gssapi.dll

Basically the same response from yum provides krb5.dll and com_err.dll

Networking / Re: GenMU WIFI driver for Ralink 301
« on: January 26, 2022, 04:51:23 am »
Yea, Doug changed his ISP. Same user name at or wait till he shows up here.
And welcome to the forum.

Comments, Suggestions & Questions / Re: Hobbes (Files) Reoganization
« on: January 26, 2022, 01:13:35 am »
Perhaps also a misc or such sub-directory for ones that don't fit elsewhere such as full screen cmd sessions?

This is what I remember. I thought it would be a good choice cause it worked with Mozilla. But now it seems it's not. Beside the topic of this thread - which compiler/linker combination allows debugging with idebug?

Basically LDFLAGS=-g -Zomf. All the OS/2 linkers should work, the usual is wl.exe as we have the source. We stopped using ilink for Mozilla as it couldn't handle the code size, IIRC the limit was 32 MB

Now I think I've to try again gcc for compiling and linking.

Should be fine. Linking against libcx will give exceptq support, LDFLAGS+=-lcx, -Zmap for map files.

Thanks for explanation. Have to test.

Usually I use makefiles and gcc -c (compile only) and link with whatever I choose in the makefile. Something like -

Code: [Select]
cc = gcc
link = wlink
$(cc) $(objs) ....
$(link) .....

Interesting, guess you'd use the OW crt files then, creating an OW binary. As Lars mentioned, did you use -Zomf as a CFLAG? Or .obj as a suffix and GCC was smart enough to create an OMF object file. Also be hard to do things like the equivalent of -Zhigh-mem. I guess for a simple C program it would work. Perhaps part of the reason for your short exceptq report.
It'll fall down with CPLUS source where you use g++ instead of gcc (same rules for linking). When I moved to GCC 9.2.0 for building Mozilla, it was trying to call a response file from another response file, which doesn't work. Went through similar back around FF4 when the linker cmd line grew to over 64KB (32KB?) and piping the cmd line failed. Then we ended up linking directly with wl.exe, it was hard. This time I linked directly with emxomfld, 873 object files (most consisting of 15 source files) plus libraries created a long cmd line (900 odd words) and was tricky to get working. Here's the sh script I ended up with, renamed to .txt to post. Note the needed libraries.

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 24, 2022, 07:07:09 am »
For some systems, yes. It varies but some systems have holes (used by the hardware I believe) in the memory address map creating the problem that Andreas has, only a couple of GB's accessible in the lower 4GB's of address space.

OK, as you know, #1 only works with OW tools.
I think perhaps your understanding of how GCC works is incomplete. GCC itself will call the linker.
Code: [Select]
gcc -g test.c -o test.exe will compile test to an aout object file and link with ld.exe, it won't produce a debuggable binary (it did way back)
Code: [Select]
gcc -g -Zomf test.c test.exeWill convert the aout object file to omf and link with emxomfld.exe, which depending on environment settings will massage the command line for a native linker,
Code: [Select]
Environment variables:
    The type of linker we're using. Values: WLINK, VAC365, VAC308, LINK386.
        WLINK    wlink.exe from Open Watcom v1.5 or later.
        VAC365   ilink.exe from IBM C and C++ Compilers for OS/2 v3.6 or later.
        VAC308   ilink.exe from Visual Age for C++ v3.08.
        LINK386  link386 form OS/2 install or DDK.
    Name of the linker to use and optionally extra parameters. Spaces in the
    linker name or path is not supported. Quotes are not supported either.
The default values for these two variables are VAC365 and ilink.exe.
There's also environment variables for rc, run emxomfld without arguments to see all options.
So while it is possible to link directly with wlink, it is tricky and really you should use GCC to link.
Both of these work, (going from memory)
Code: [Select]
gcc -g test.c -o test.o
gcc -g -Zomf test.o -o test.exe
Code: [Select]
gcc -g -Zomf test.c -o test.o
gcc -g -Zomf test.o -o test.exe

With CFLAGS=-Zomf, things can get more complex, static libs use emxomfar instead of ar, ranlib will fail on a omf static lib, do SET AR=emxomfar, SET RANLIB=ECHO for that scenario.
Usually omf libs end in .lib and aout ones in .a

Sorry, I was thinking GCC, for OW, I think you'd want something like this,
Code: [Select]
wlink NAME main SYSTEM os2v2 OPTION symfile=PCM9362_ANETCOM.dbg OPTION MAP=main.watmap debug all lib pmprintf.lib file { main.obj }
Hmm, testing it doesn't seem to work here. Anyways see the SYMFILE option in the OW Linker Guide

Hi Andy, sorry, I didn't realize that you were compiling with OW when I posted.
DBG vs XQS: DBG has more info to find where the error occurred. XQS are small and give enough info much of the time. I feel that it is best to add the XQS files to your package and have the DBG files available if needed. I don't know how well exceptq handles the OpenWatcom debug format.
You should be able to add the symfile directive to your wlink options

I see your linking with wl, wl is for GCC, handles dwarf style debug info. Using wc386, you should probably link with wlink. Perhaps this is your problem producing debug info, '-d2 -dDEBUG_BUILD' is what the screensaver uses.
wc386 only produces HLL debugging info and that's currently it. You have to use the OW debugger.
Might of got confused about debugging styles, GCC -Zomf -g produces files that can be debugged in idebug, OW doesn't so your left with its debugger.

Networking / Re: Squid Cache
« on: January 23, 2022, 09:44:19 am »
Hi Harald, basically a Pentium 4 Northwood and as you can see, no SSE3 support. Paul can explain why squid is using SSE3. The trp report is accurate and this build of squid will not run on your processor.
Gotta say that Intel has crappy CPU naming, especially with Xenon's

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 23, 2022, 01:47:04 am »
Somewhat surprising, my T42 with 1GB of ram is quite stable, takes forever to start SeaMonkey but once running, it's fine.
One thing is to set the size of the swap file as fairly large (1GB?) as growing it can cause problems.
The other day I had to reboot as cpp (the preprocessor) was dying trying to allocate 64 KB's of memory, SeaMonkey was still stable.

OK, use something like 'LDFLAGS=-Zlinker option symfile=xxx.dbg' and -g in both CFLAGS (CXXFLAGS) and LDFLAGS to get the dbg file.

Networking / Re: Squid Cache
« on: January 22, 2022, 06:44:09 pm »
Tried my old squid, which is working fine as I'm posting this using it. The log also has :DNS Socket created at, FD 9" but works. Here's the log for comparison, no invalid arguments, the cache was dirty after 4 years :)

Hardware / Re: Hardware Compatibility Wishlist for 2022
« on: January 22, 2022, 06:24:44 pm »
Thanks, OS4User. RAM disk is not an option, when only 1 GB or less is recognized for the system. AMD systems suffer since a longer time from this, with 1.5 - 2 GB. According to Sigurd, newer Intel (i7) systems have that problem, too.

Virtualization seems to be the only option then.

Are there any newer systems that support 3 GB?

Even with only 1.5GB of actual ram recognized by the system, you still should have about 3.5 GB of memory space, it'll just swap and the swap file can go on the ram disk.
At one point I was using a system with 1.5GB's of ram installed, linking xul.dll required VIRTUALADDRESSLIMIT set to 3072 to avoid running out of memory, the swap file would grow to close to 2 GB (occasionally over which killed the system with a swap file full error, there seems to be a 2GB limit), things would be slow but work.
With 1.5 GB of ram under normal usage you should only see light swapping.

Pages: [1] 2 3 ... 224