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 ... 203
Yet, you probably know more then most of us, if only from hacking on the GCC source. There are people who seem to instinctively understand this stuff though, AZ who did the GCC 2.9x ports was one. IBM chased him down and payed him to do the first kLIBC GCC port, 3.22 or so for Mozilla. There was someone else who ported GCC back in the day for fun, a different port then EMX. So much software lost.

Applications / Re: Desktop Enhancement for WPS
« on: May 15, 2021, 04:01:00 am »
Yea, OS/2 will try to invoke WinOS2 to run a PE executable, especially if you have installed Win32s. Usually fails due to 8.3 name issues in the path. I had an extension, downloadthemall or such that kept trying to run a Windows executable, all it did was fill up a log until I removed the executable.
This was one of the reasons that it was ill advised to install win32k.sys from Odin, it might have run hello.exe.
I also remember a browser flaw getting used to try to run C:\Windows\cmd.exe, which failed due to our browser having a bug and most people not having a C:\Windows\cmd.exe accessible. At that I've heard that most Windows malware can be defeated by not installing on C:
As for MS trying to monetize everything, it is a problem with our stock based system demanding endless growth instead of being happy with a good steady income.

Applications / Re: Desktop Enhancement for WPS
« on: May 15, 2021, 01:09:19 am »
The weird thing is that generally our OS/2 files (excepting cmd) won't even load on modern Windows. I guess some DOS programs are LX and might load and be confused.
Anyways the odds of an OS/2 file having a virus is so close to zero that I wouldn't worry about it. So far the only virus I've had was one that infected the MBR that came on a floppy, a driver disk for some hardware I'd bought. WinOS2 actually spotted it and just had to rewrite the MBR. Strictly speaking it wasn't an OS/2 virus as it ran before an OS was installed.

Yeah I tried rebuilding libend with those symbols commented out - it now links but I get the same SIGILL as if I just remove libend.

Might be a problem with the section ordering

I think I was confused when I thought it was working the other day - my hello.lnk had helloworld.obj in it - which was an OMF version of the object file :(

I must have made the same mistake :) Today I fixed your hello.lnk as I had lost my original test after a reboot (ram disk) and then got the error.
Need a compiler expert who understands all these segments and stuff.

Perhaps rebuild libend with those symbols commented out?
I tried but I seem to be missing the ml assembler and building all fails due to missing demangle.h
Looking, it seems they're reserved symbols when the option DOSSEG is specified. Where it is getting specified, I'm not sure unless it is automatic when making an executable. It is possible to override the segment ordering, only recommended for embedded applications without an OS. The segments probably should be ordered in a specific order. Search for DOSSEG in the Open Watcom Linker guide.
Looking at the emxomfld source, I can't quite figure out the whole list of options being passed and why linking OMF doesn't cause the same error.

Thanks everyone... what works here is:

Code: [Select]
gcc -S helloworld.c
as_elf helloworld.s -o helloworld.o
wl @hello.lnk
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited Availability by SHL on Jul  2 2020
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See for details.
loading object files
searching libraries
creating map file
creating an OS/2 and ArcaOS executable

For interest -

I have a day off on Friday, I'll try and think about how to modify GCC to use this stuff....



'tis weird, this worked the other day, today I'm getting the
Code: [Select]
Error! E2026: redefinition of reserved symbol _edata
Error! E2026: redefinition of reserved symbol __edata
Error! E2026: redefinition of reserved symbol _end
Error! E2026: redefinition of reserved symbol __end

- work out how to workaround the lack of elf support in emximp - in order to create import libraries for DLL's - worst case is to use OMF libs
There's the IMPLIB option for wlink to create an implib during linking. Hmm, it actually calls wlib to create the import library.
Wlib also has the option ie to create elf import records and an option to list all symbols found in a library file, including static.
There's other tools available, some from binutils some from OW which could be tweaked to output exports from object files.
Wlink has a variety of way to create a DLL, with def files hardly used though they work. With the screensaver's cairo clock, I imported the symbols directly from cairo2.dll and the makefile has,
Code: [Select]
$(dllname).dll: $(object_files)
    @wlink system 386 lx dll INITINSTANCE TERMINSTANCE name $(dllname) &
    f CaClock f MSGX op MAP=$(dllname) op DESC 'Cairo Clock - ScreenSaver module
' &
    op ELIMINATE op MANYAUTODATA op OSNAME='OS/2 and eComStation' op SHOWDEAD &
    LIBPATH %os2tk%\lib LIBRARY libuls.lib LIBRARY libconv.lib @Imports.lnk @des

!ifdef has_resource_file
    rc $(rcname) $(dllname).dll
!ifdef create_packed_dll
    lxlite $(dllname).dll

If I'm understanding correctly, elf can put the stabs in its own section much like aout does. So it should be possible and with luck might work out of the box. Hopefully it'll fix those warnings about too big stabs that are generated while compiling.

Hi Paul, really first it needs to be checked out whether OMF is needed for debugging or whether ELF can handle it along with wl.exe putting it into the executable. Currently debugging works fine with our aout-->omf-->linker-->exe/dll.
I'd suggest testing and possibly it might work or wl.exe can be altered for it to work.
There's also the weak linker to consider. Reading up on it, it is probably seldom used and can be ignored for now.

@os4user I'm not disagreeing with you, but if we don't convert to omf, how do we debug on OS/2?

I am not familiar with this matter and have no idea why object files are needed for debugging.

The real question is the amount of support for our stabs (dwarf?) debugging data in elf object files and whether the linker can put that data in the executable.
Currently, my understanding is that aout supports stabs and emxomf transfers the stabs to the omf intermediate objs and then the linker transfers them to the executable or a dbg file. Not sure if our debuggers support dbg files, exceptq does.

I would also vote to get "" (Latest freeware) - (or even - older) installed there but the "no fixpacks" in Warp 3 may be an issue.

As I said, SNAP doesn't support that old card, here's what is supported,
Code: [Select]
0 1013:00D0 cirr546x.drv.Jul.26.2000.20.24.21   ; Cirrus Logic Laguna 5462
0 1013:00D4 cirr546x.drv.Jul.26.2000.20.24.21   ; Cirrus Logic Laguna 5464
0 1013:00D6 cirr546x.drv.Jul.26.2000.20.24.21   ; Cirrus Logic Laguna 5465
0 1013:00A8 cirrus.drv.Jul.11.2003.18.37.08     ; Cirrus Logic CL-GD5434
0 1013:00AC cirrus.drv.Jul.11.2003.18.37.08     ; Cirrus Logic CL-GD5436
0 1013:00A0 cirrus.drv.Jul.11.2003.18.37.08     ; Cirrus Logic CL-GD5440
0 1013:00B8 cirrus.drv.Jul.11.2003.18.37.08     ; Cirrus Logic CL-GD5446
0 1013:FF0C cirrus.drv.Aug.07.2001.17.59.27     ; Cirrus Logic CL-GD7543 LCD
0 1013:0040 cirrus.drv.Mar.10.2000.13.04.48     ; Cirrus Logic CL-GD7555 LCD
Taken from x:\os2\drivers\snap\graphics.bpd

Hi Charles, the fixpaks are cumulative, so just the latest is needed, though at one point IBM split the device drivers into their own fixpak and the 2nd device driver fixpak had the USB support removed, so if you want USB, you need to install the 1st and then the 2nd device driver fixpak.
You really need at least fixpak 17 for the SIQ fix and the device driver fixpak will give support for much newer hardware like Hard drives, though that is easy to add by itself
There are also fixes for other stuff such as the network stack, which can actually be used to getting networking (beyond the internet kit) working on plain OS/2 V3 or earlier.

As for your video card, you might be able to easily find a newer VLB card then you have. Even the next generation Cirrus Logic looks better.

@Ibrahim, the VT isn't necessary, just nice to have. As for 3D graphics, I wonder if it needs host video driver support or can be brute forced.

@Martin, yes, I don't really see much issue with using the OS4 kernel, but Lewis seems fairly worried about upsetting IBM so I'll err on the cautious side. As Ibrahim sayss, things should work on the stock kernel, even ones not distributed by Arca Noae, though reboots will be needed more often to recover memory.

Reading the readme from the driver, I guess you could try to hunt down the DOS drivers which seem to include the monitor utility, it likely would run on OS/2's Dos session. Or there might be a generic monitor that is good enough like SuperVGA or IIRC, Warp came with a generic SuperVGA driver, which, while not accelerated, would at least give more colours and 800x600 resolution.
The driver also mentions the display.log and dspinstl.log if you want to look and perhaps remove any files that were added during the aborted driver install.

Hi Dariusz, before monitors supported EDID, you really did have to set things up manually for your monitor, and depending on the monitor specs you entered, the screen object would have shown the possibilities I assume. I only had a VGA monitor back in the Warp v3 days and don't remember the screen object.
Needed a Win3.1 video driver too before GRADD.
From XF86Config for example,
Code: [Select]
# Any number of monitor sections may be present

Section "Monitor"

#    Identifier  "AST svga-lr"

# HorizSync is in kHz unless units are specified.
# HorizSync may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.

#    HorizSync   30-70

#    HorizSync  30-64         # multisync
#    HorizSync  31.5, 35.2    # multiple fixed sync frequencies
#    HorizSync  15-25, 30-50  # multiple ranges of sync frequencies

# VertRefresh is in Hz unless units are specified.
# VertRefresh may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.

#    VertRefresh 50-130


Some video drivers such as the ATI Mach 64 would probe the monitor and try to figure it out. This blew up my original VGA monitor by over driving and breaking the fly cable, looked like a lightning storm in the back of the monitor.

Pages: [1] 2 3 ... 203