Login

Recent searches

No recent searches

Search options

Only available when logged in.
fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

9.9K
active users

fosstodon.org: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#watcom

0 posts0 participants0 posts today
Public *
The Last Psion | Alex

Mini-rant ahead:

I'm delving into #cmake to try to make it build a compile_commands.json file to work with #retrocomputing C header files, specifically the #Psion SIBO C SDK (from the early 90s).

I don't actually want cmake to do anything but tell clangd what to do, so that I've got a working language server in NeoVim.

I don't need it to build any Makefiles, I don't need it to tell a compiler what to do. I just want clangd to treat my old 16-bit real mode code correctly, and that the header files are in ~/dosbox/sibo-c/SIBOSDK/include/.

Note that I can't point it at the compiler, because the compiler (TopSpeed) runs in DOSBox. There is no modern compiler that will work.

So... Do I have to fake it somehow? For example, do I have to tell cmake that it's actually using a different compiler (e.g. #Watcom) to make it behave correctly? And if I do, will that matter to clangd?

Public
GateLinker

I liked the simplicity of library github.com/ricmoo/QRCode and wanted to use it in my projects too.

But due to my "special" (old) compilers, some changes were required. With the back-port to C90, it builds for :msdos: via .
adds shared Win/Linux libraries, CTest unit tests and a small `qrgen` command line tool.

One task is still open: Check if the original target is still working ...

However, results are now on
codeberg.org/gatelinker/QRCode

GitHubGitHub - ricmoo/QRCode: QR code generation library in C, optimized for low-power devices, such as Arduino.QR code generation library in C, optimized for low-power devices, such as Arduino. - ricmoo/QRCode
Public
GateLinker

🥰 O-M-G! I love .

It helped me to find a stupid bug in my framebuffer code that slowed down clearing images.
Coding and compiling was done with and ,
and execution in DOSBox showed immediately what failed.

We don't see such bugs on Windows or Linux with our GHz CPUs anymore.
But with good old on an emulated 386 33 MHz host it made a jump from 2 to 18 FPS after fixing.

That's true optimization nobody cares about today. before must have been real fun.

Public
GateLinker

And again: Grandpa knows why.

Compiling with for showed me some code-bloat in my hardcoded static C v-tables. The referenced v-table methods cannot be eliminated by the optimizer when those structures are not used.

But shifting the initialization of v-tables into separate functions
gives compilers the option to discard all unnecessary stuff.

This seems to be true for MSVC and GCC too.

However ... smaller executables are more important on DOS than on or .

Public
Bernd Böckmann

I made significant progress in porting Ranish Partition Manager from #Borland #C and #TASM to #Watcom C and #NASM.

All the C files and about half the assembler files are translated. The Watcom built executable is running and a few quick tests revealed no unexpected behaviour. Thoroughly testing has still to be done after the remaining files are translated.

codeberg.org/boeckmann/ranish

Codeberg.orgranishfork of the last public domain version of Ranish Partition Manager
Public
Bernd Böckmann

Implementation defined behaviour in #C: Folgendes packt #Borland C einen char, #Watcom in einen int:

unsigned start_sect:6;
unsigned start_cylH:2;

Daher Struktur unter Borland 16 bytes und unter Watcom 18 🤡

Es muss leider ein char sein. Watcom erlaubt folgendes, um es gerade zu biegen:

unsigned char start_sect:6;
unsigned char start_cylH:2;

Nicht erlaubt laut Standard: "A bit-field shall have a type that is a qualified or unqualified version of one of int, unsigned int, or signed int."

Public
peron
Si bien existieron muchos productos capaces de solucionar las limitaciones de memoria de DOS, sobresalen dos compañías en particular, en una mancomunidad ganadora. La unión virtuosa del compilador de C de #Watcom International Corporation y el "Extensor de DOS" #DOS/4GW de Rational Systems permitía correr programas en Modo PROTEGIDO, a la vez que retenían en acceso a las funciones en Modo REAL de 16 bits del DOS. Las aplicaciones se la pasaban conmutando entre modo real y protegido. Esto constituía un problema en las CPUs 286 porque Intel nunca imaginó que un programa podría querer conmutar ida y vuelta entre MODO REAL y MODO PROTEGIDO. Extensor #DOS/4GW Si bien el problema era volver, en los Intel pasar de MODO REAL a MODO PROTEGIDO era simple. Solo tenías que usar 6 instrucciones mnemónicas oara colocar el Registro de Control del bit 0 al 1 y activarlo. La manera normal para realizar una "llamada de sistema" en DOS era usar una instrucción de interrupción de software con el parámetro 21H. En programación C, esto constituía una abstracción del encabezado DOS.H - encargado de llevar a cabo todo el trabajo de bajo nivel del sistema operativo. El extensor permitía hacer esto de manera más simple y transparente para el programa. Ambos mundos tenían que estar "puenteados" para permitir que un programa corriese en uno de los Modos de procesador y el sistema operativo lo hiciera en el otro. Para ello se instituía una capa intermedia denominada "Extensor DOS" - la cual era capaz de correr en ambos modos, biejecutble - y se la insertaba entre el programa y el sistema operativo. Cuando inicializabas el Extensor DOS, este colocaba llamadas en la Tabla de Vector de Interrupción del Sistema Operativo, y allí metía sus propias rutinas. Desde el punto de vista de la aplicación todo resultaba transparente, y no tenías que alterar ningún código. Para disparar las llamadas de sistema que no estaban enlazadas al Extensor (por ejemplo, si querías usar la INT33H para leer el registro del mouse), el Extensor te ofrecía la interfaz especial llamada DPMI, en la cual el interruptor 31H que se encargaba de traducir los pedidos de registros de 32 bits a 16 bits, tal que las rutinas de la Tabla de Vector de Interrupción las entendiesen. Cuando el extensor interceptaba una llamada de sistema operativo, traducía las llamadas, conmutaba la CPU al modo real y reenviaba la llamada al DOS, y recogía el resultado, y pasaba al modo protegido de nuevo, para continuar. Watcom El Extensor DOS era mágico, pero bastante difícil de presentar como producto integrado real. Lo que realmente se necesitaba era disponer de un ambiente integrado en el cual el compilador y en enlazador se encargasen de embutir tanto al extensor y como a la aplicación en sí dentro de un fichero ejecutable. La solución vendría del extremo norte. En 1979 en la Universidad de Waterloo en Ontario, Canadá comenzaron a desarrollar un compilador multiuso llamado #Watcom. Para 1987 integró el primer compilador C de DOS para la 386. Para 1993 habían alcanzado mejoras considerables: el Watcom C/386 daba código al menos el doble de velocidad que los compiladores de Borland o Microsoft, (usualmente mas). El combo Watcom/Extensor tornaba simple la programación y también resultaba en soft veloz, pero lo mas importante fue permitir la portabilidad del #código C extendido. No sólo podía programarse en C en modo real en DOS, sino portar a otras plataformas.
ExploreLive feeds
About