Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

32-bit MSDOS (Announce)

posted by marcov, 03.07.2021, 16:12

> C90-derived I meant. ie binaries produced
> from C90 source code.
Yes, but a different compiler would produce different C90 binaries. (e.g. mingw vs cygwin). So this is very ambiguous, and only means something in C source code.

> > Let the Pascal code call C.
>
> I don't know how to do that, and I don't have
> control of that anyway, so I just created
> some assembler code that will push the registers
> onto the stack when I figure out how to get it
> to even link.
Note that you can also write the assembler code in pascal. It has an internal assembler that can do both AT&T (GAS) and Intel (TASM) syntax. But it allows you to use unmangled Pascal identifiers rather than using the mangled on the GAS level. More future proof.

See e.g. rtl/i386/i386.inc for some examples. (we still use a lot of AT&T and that is going back to a time when neither GAS nor FPC supported intel style assembler)

> > Ok. Is afaik a function for thread variable (TLS) reasons.
>
> I don't wish to support threads.
Also I think that stdin/stdout/stderr are not fixed constants at all on Windows. https://docs.microsoft.com/en-us/windows/console/getstdhandle

> > This signature doesn't match. shortstrings are complicated beasts. Only
> > replace the final call to the OS (in rtl/win/sysfile).
>
> Ok, I sort of fixed that for now.
Note that you can't change signatures of anything marked as compilerproc AT ALL, (so also not calling convention) since calls to these are generated in code generated automatically by the compiler

Probably anything marked iocheck too.

> I don't wish to use other people's copyrighted
> code in my executable if there is any way around
> it. Even if it takes me 27 years.
Well, that is about the age of FPC as a public project too. (published on internet 1994).

> > I wouldn't go this route, at
> > least not for first steps, let Free Pascal generate the linking. You can
> > tell it to link .o and .a's by doing {$L myobject.o} in the main
> program.
>
> I don't wish to change the main program. It is
> standard Pascal. It's everything else that has
> to change.
I'm probably repeating my self with "pointless" "dead end", as it will not scale to non trivial binaries reusing existing code and standard pascal.

> Here's what I have now. I don't know how to
> resolve the link errors. It both complains
> that the symbols are duplicate and complains
> that they are missing.
Note that some are marked as "fake". Probably mismatch between weak and definitive definitions or so.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 366 users online (0 registered, 366 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum