Groups | Search | Server Info | Login | Register

Groups > comp.os.os2.programmer.misc > #1862

Re: loader

Show all headers | View raw

Hi Dave.

Thanks for the explanation.

That seems to be missing DOSOPEN as well as others.

Note that I received an enhancement to exeload.c
overnight which should allow for much more robust
loading of executables and I'll see what it is
capable of later (source has been committed
already though, and makebios.lnp has the
instructions).

Also the pdld author's concerns appear to have been
allayed.

I will add the missing function names to exeload.c,
which is trivial, and see what happens when I load
pdptest.exe built by Watcom.

I would still need to flesh out my doscalls.c, but
that shouldn't be an issue to get pdptest.exe to run.

BFN. Paul.




On 29/02/24 06:04, Dave Yeo wrote:
> Paul Edwards wrote:
>> He seemed annoyed that he couldn't access doscalls
>> functions by name instead of ordinal and asked me if
>> there was a reason for that. Anyone know?
>
> Usual use of ordinals was to save memory. Important when running with
> 4MB's of ram like when I started.
> Usually link to doscall1.dll, rather then directly to the kernel, where
> doscall1.dll does seem to export by name. Just generated a DEF file from
> the SMP version of doscall1.dll,
> ;
> ; doscall1.def (created by emximp)
> ;
> LIBRARY doscall1 INITINSTANCE TERMGLOBAL
> EXPORTS
>   "DOSTIMERASYNC"
>   "DOSTIMERSTART"
>   "DOSTIMERSTOP"
>   "DOSREAD"
>   "DOSWRITE"
>   "DOSERRCLASS"
>   "DOSSEMREQUEST"
>   "DOSSEMCLEAR"
>   "DOSSEMWAIT"
>   "DOSSEMSET"
>   "DOSEXECPGM"
>   "DOSSUBSET"
>   "DOSSUBALLOC"
>   "DOSSUBFREE"
>   "DOSREADASYNC"
>   "DOSWRITEASYNC"
>   "DOSSEARCHPATH"
>   "DOSSCANENV"
>   "DOSSETCP"
>   "DOSCALLBACK"
>   "DOSFSRAMSEMREQUEST"
>   "DOSFSRAMSEMCLEAR"
>   "DOSQAPPTYPE"
>   "DOSSETPROCCP"
>   "DOSLOGREGISTER"
>   "DOSLOGREAD"
>   "DOSCOPY"
>   "DOSPMSEMWAIT"
>   "DOSPMMUXSEMWAIT"
>   "DOSSGQUERYTOPMOST"
>   "DOSSETEXTLIBPATH"
>   "DOSQUERYEXTLIBPATH"
>
> Dave
>

Back to comp.os.os2.programmer.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

loader Paul Edwards <mutazilah@gmail.com> - 2024-02-20 16:10 +0800
  Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-20 17:45 -0700
    Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-21 10:51 +0800
  Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 06:14 +0800
    Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 11:38 +0800
  Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 15:24 +0800
    Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 15:46 +0800
      Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 16:30 +0800
        Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 23:30 +0800
        Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-24 23:28 +0800
          Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-26 06:56 +0800
            Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-27 15:41 -0700
              Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-28 12:50 +0800
                Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 14:04 -0800
                Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-29 06:56 +0800
                Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 19:11 -0800
                Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-02-29 11:46 +0800
                Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 23:02 -0800
                Re: loader Paul Edwards <mutazilah@gmail.com> - 2024-03-01 07:15 +0800
                Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 14:20 -0800
              Re: loader Dave Yeo <dave.r.yeo@gmail.com> - 2024-02-28 13:52 -0800
                Re: loader Peter Flass <peter_flass@yahoo.com> - 2024-02-28 17:43 -0700

csiph-web