Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #634 > unrolled thread

Borlands Tasm5 and data in a DLL

Back to article view | Back to comp.os.msdos.programmer

Contents

  Borlands Tasm5 and data in a DLL "R.Wieser" <address@not.available> - 2012-06-11 22:10 +0200
    Re: Borlands Tasm5 and data in a DLL JJ <jaejunks_at@_googlemail_dot._com> - 2012-06-12 16:54 +0000
      Re: Borlands Tasm5 and data in a DLL "R.Wieser" <address@not.available> - 2012-06-12 19:54 +0200
        Re: Borlands Tasm5 and data in a DLL JJ <jaejunks_at@_googlemail_dot._com> - 2012-06-13 00:14 +0000
          Re: Borlands Tasm5 and data in a DLL "R.Wieser" <address@not.available> - 2012-06-13 10:54 +0200
    Re: Borlands Tasm5 and data in a DLL JJ <jaejunks_at@_googlemail_dot._com> - 2012-06-12 16:57 +0000
    Re: Borlands Tasm5 and data in a DLL Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-06-12 18:54 -0400
      Re: Borlands Tasm5 and data in a DLL "R.Wieser" <address@not.available> - 2012-06-13 10:37 +0200
        Re: Borlands Tasm5 and data in a DLL Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-06-13 13:03 -0400
          Re: Borlands Tasm5 and data in a DLL "R.Wieser" <address@not.available> - 2012-06-14 09:30 +0200
            Re: Borlands Tasm5 and data in a DLL Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-06-14 11:55 -0400
              Re: Borlands Tasm5 and data in a DLL "R.Wieser" <address@not.available> - 2012-06-14 21:49 +0200
                Re: Borlands Tasm5 and data in a DLL Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-06-14 16:21 -0400
                  Re: Borlands Tasm5 and data in a DLL "R.Wieser" <address@not.available> - 2012-06-15 12:18 +0200
                    Re: Borlands Tasm5 and data in a DLL rugxulo@gmail.com - 2012-06-19 18:27 -0700

#634 — Borlands Tasm5 and data in a DLL

Hello All,

I've got a bit of a problem in accessing data stored in a DLL.  I'm using
Borlands Tasm5.0, and (think I) have no idea how to define the data in the
DLL the right way.

What I mean by that is that I cannot use something like

extrn MyData:DWORD

to directly access the data in the DLL ("mov eax,[MyData]" won't work).
When I look at where, in this case, MyData points at I see a FF 25 <dword
address> (which is the same as for a PROCDESCed function, and quite
unexpected).

This means I first have to remove the indirection myself to actually acccess
the data I need, which is quite unexpected to me.

mov  eax,[MyData+WORD]    ;Get the pointer
mov  eax,[eax]                         ;Follow the pointer into the DLL
mov  eax,[eax]                         ;actually get the DWORD

So my question is: Have I missed something here ?  What do I have to do to
use externally defined data the normal, direct way ?  Can I actually do that
?

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#635

Since the variable resides in an external DLL, the variable can't be 
moved elsewhere. This is because it belongs to that DLL and not yours or 
other modules.

Accessing an DLL variable use the same mechanism as importing a DLL 
function.

What you get from a DLL function is the pointer to that function. This 
is exactly the same with a DLL variable. You get the pointer to that 
variable.


"R.Wieser" <address@not.available> wrote in
news:4fd6504d$0$6942$e4fe514c@news2.news.xs4all.nl: 

> Hello All,
> 
> I've got a bit of a problem in accessing data stored in a DLL.  I'm
> using Borlands Tasm5.0, and (think I) have no idea how to define the
> data in the DLL the right way.
> 
> What I mean by that is that I cannot use something like
> 
> extrn MyData:DWORD
> 
> to directly access the data in the DLL ("mov eax,[MyData]" won't
> work). When I look at where, in this case, MyData points at I see a FF
> 25 <dword address> (which is the same as for a PROCDESCed function,
> and quite unexpected).
> 
> This means I first have to remove the indirection myself to actually
> acccess the data I need, which is quite unexpected to me.
> 
> mov  eax,[MyData+WORD]    ;Get the pointer
> mov  eax,[eax]                         ;Follow the pointer into the
> DLL mov  eax,[eax]                         ;actually get the DWORD
> 
> So my question is: Have I missed something here ?  What do I have to
> do to use externally defined data the normal, direct way ?  Can I
> actually do that ?
> 
> Regards,
> Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#637

JJ,

> What you get from a DLL function is the pointer to that
> function.

True, but (normally) the address your own code calls (to access the function
in that DLL) is not the address of that function.  Instead, it calls into a
special table which holds a jump command and the real address of that DLL
function.

> This is exactly the same with a DLL variable.
> You get the pointer to that variable.

I'm sorry, did you see the code I posted (those three lines) ?   The first
line shows you that the pointer is not at the adress pointed to by the
"MyData" label (but two bytes beyond it).   The second line shows you that
there is a second indirection.

In short : I'm not getting a pointer to that variable.   *Thats the whole
problem*

Regards,
Rudy Wieser


-- Origional message:
JJ <jaejunks_at@_googlemail_dot._com> schreef in berichtnieuws
XnsA070F37A1B56Djaejunksgooglemailco@0.0.0.29...
> Since the variable resides in an external DLL, the variable can't be
> moved elsewhere. This is because it belongs to that DLL and not yours or
> other modules.
>
> Accessing an DLL variable use the same mechanism as importing a DLL
> function.
>
> What you get from a DLL function is the pointer to that function. This
> is exactly the same with a DLL variable. You get the pointer to that
> variable.
>
>
> "R.Wieser" <address@not.available> wrote in
> news:4fd6504d$0$6942$e4fe514c@news2.news.xs4all.nl:
>
> > Hello All,
> >
> > I've got a bit of a problem in accessing data stored in a DLL.  I'm
> > using Borlands Tasm5.0, and (think I) have no idea how to define the
> > data in the DLL the right way.
> >
> > What I mean by that is that I cannot use something like
> >
> > extrn MyData:DWORD
> >
> > to directly access the data in the DLL ("mov eax,[MyData]" won't
> > work). When I look at where, in this case, MyData points at I see a FF
> > 25 <dword address> (which is the same as for a PROCDESCed function,
> > and quite unexpected).
> >
> > This means I first have to remove the indirection myself to actually
> > acccess the data I need, which is quite unexpected to me.
> >
> > mov  eax,[MyData+WORD]    ;Get the pointer
> > mov  eax,[eax]                         ;Follow the pointer into the
> > DLL mov  eax,[eax]                         ;actually get the DWORD
> >
> > So my question is: Have I missed something here ?  What do I have to
> > do to use externally defined data the normal, direct way ?  Can I
> > actually do that ?
> >
> > Regards,
> > Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#639

I forgot that it's an explitic import, so it's a pointer of a pointer to 
actual code/data. It's how the import table is implemented. We can't 
change that unless you implicit import via GetProcAddress.

The only way to make it the simplest is to keep using explicit import 
and "fix" the MyData address.

;init part
mov eax, [MyData] ;get ptr to import table entry
mov edx, [eax] ;get actual address of imported data
mov [eax], edx ;replace the address

;usage part
mov eax, [MyData] ;will get actual value

As for why the address of off by a WORD...
Are you sure the exported variable is not a structure?


"R.Wieser" <address@not.available> wrote in
news:4fd781dc$0$6975$e4fe514c@news2.news.xs4all.nl: 

> JJ,
> 
>> What you get from a DLL function is the pointer to that
>> function.
> 
> True, but (normally) the address your own code calls (to access the
> function in that DLL) is not the address of that function.  Instead,
> it calls into a special table which holds a jump command and the real
> address of that DLL function.
> 
>> This is exactly the same with a DLL variable.
>> You get the pointer to that variable.
> 
> I'm sorry, did you see the code I posted (those three lines) ?   The
> first line shows you that the pointer is not at the adress pointed to
> by the "MyData" label (but two bytes beyond it).   The second line
> shows you that there is a second indirection.
> 
> In short : I'm not getting a pointer to that variable.   *Thats the
> whole problem*
> 
> Regards,
> Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#641

Hello JJ,

> ;init part
> mov eax, [MyData] ;get ptr to import table entry
> mov edx, [eax] ;get actual address of imported data
> mov [eax], edx ;replace the address

Nope.   As in my example-code the pointer is two bytes beyond the address
"MyData" is pointing to.

> ;usage part
> mov eax, [MyData] ;will get actual value

Nope, it will only get the pointer (MyData points to the pointer.  [MyData]
gets that pointer, not the data itself).  All you code does in removing a
single indirection.

To have this (my request) working all all references to "MyData" need to be
replaced with the pointer to the actual data.  And that should be a task for
Windows EXE-loader.  As it does not (cannot?) do that I seem to be
out-of-luck :-\

Regards,
Rudy Wieser


-- Origional message:
JJ <jaejunks_at@_googlemail_dot._com> schreef in berichtnieuws
XnsA07149C1EA08Fjaejunksgooglemailco@0.0.0.29...
> I forgot that it's an explitic import, so it's a pointer of a pointer to
> actual code/data. It's how the import table is implemented. We can't
> change that unless you implicit import via GetProcAddress.
>
> The only way to make it the simplest is to keep using explicit import
> and "fix" the MyData address.
>
> ;init part
> mov eax, [MyData] ;get ptr to import table entry
> mov edx, [eax] ;get actual address of imported data
> mov [eax], edx ;replace the address
>
> ;usage part
> mov eax, [MyData] ;will get actual value
>
> As for why the address of off by a WORD...
> Are you sure the exported variable is not a structure?
>
>
> "R.Wieser" <address@not.available> wrote in
> news:4fd781dc$0$6975$e4fe514c@news2.news.xs4all.nl:
>
> > JJ,
> >
> >> What you get from a DLL function is the pointer to that
> >> function.
> >
> > True, but (normally) the address your own code calls (to access the
> > function in that DLL) is not the address of that function.  Instead,
> > it calls into a special table which holds a jump command and the real
> > address of that DLL function.
> >
> >> This is exactly the same with a DLL variable.
> >> You get the pointer to that variable.
> >
> > I'm sorry, did you see the code I posted (those three lines) ?   The
> > first line shows you that the pointer is not at the adress pointed to
> > by the "MyData" label (but two bytes beyond it).   The second line
> > shows you that there is a second indirection.
> >
> > In short : I'm not getting a pointer to that variable.   *Thats the
> > whole problem*
> >
> > Regards,
> > Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#636

This should be in a windows group, BTW.


"R.Wieser" <address@not.available> wrote in
news:4fd6504d$0$6942$e4fe514c@news2.news.xs4all.nl: 
    
> Hello All,
> 
> I've got a bit of a problem in accessing data stored in a DLL.  I'm
> using Borlands Tasm5.0, and (think I) have no idea how to define the
> data in the DLL the right way.

[toc] | [prev] | [next] | [standalone]

#638

R.Wieser <address@not.available> wrote:
>So my question is: Have I missed something here ?  What do I have to do to
>use externally defined data the normal, direct way ?  Can I actually do that
>?

You can't access the externally defined data directly, you have to
go through a pointer in the import table.  Only the pointer in the
import table gets updated to reflect the address where your data value
got loaded.  The Windows loader won't modify your code to point at the
correct address, so you can not directly reference another DLL's data
(or code).

However you can remove an unneccessary level of indirection from your
code.  Instead of accessing the jump stub intended to be used by code, you
can access the pointer in the import table directly.  Something like this:

	extern __imp_MyWord:DWORD

	mov 	eax,[__imp_MyWord]
	mov	eax,[eax]

I doubt there's away for the assembler to do this indirection
automatically for you.  It would have to clobber a register wouldn't
work in the general case.

Note that you can also access the import table directly to remove a
level of indirection from calls to another DLL:

	extern __imp_MyProc:DWORD

	call	[__imp_MyProc]

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#640

Ross,

> You can't access the externally defined data directly, you
> have to go through a pointer in the import table.  Only the
> pointer in the import table gets updated to reflect the address
> where your data value got loaded.

I guessed as much, but could not find anything in regard to it in Borlands
handbooks (that kame with the assembler).  Googeling did not turn up
anything either.  Bummer.

I must say its quite nasty that I can define an external variable, only to
have to jump thru hoops to actually access it.   One slip of the mind and
assuming that "MyData" works the same as for/is local and you are in deep
sh*t. :-(

> Something like this:
>
> extern __imp_MyWord:DWORD
>
> mov eax,[__imp_MyWord]
> mov eax,[eax]

Are you sure ?   In my example-code I had to use a "+WORD" in the first line
(to skip the FF 25  (a jump command ) preceeding the actual address).  How
come you do not need it ?

> I doubt there's away for the assembler to do this indirection
> automatically for you.

Believe me, it doesn't.  (I've got a bit of experience with calling methods
in COM-style objects)

> It would have to clobber a register wouldn't
> work in the general case.

Exactly that is what bothers me.

Regards,
Rudy Wieser


-- Origional message:
Ross Ridge <rridge@csclub.uwaterloo.ca> schreef in berichtnieuws
jr8hc3$u8o$1@rumours.uwaterloo.ca...
> R.Wieser <address@not.available> wrote:
> >So my question is: Have I missed something here ?  What do I have to do
to
> >use externally defined data the normal, direct way ?  Can I actually do
that
> >?
>
> You can't access the externally defined data directly, you have to
> go through a pointer in the import table.  Only the pointer in the
> import table gets updated to reflect the address where your data value
> got loaded.  The Windows loader won't modify your code to point at the
> correct address, so you can not directly reference another DLL's data
> (or code).
>
> However you can remove an unneccessary level of indirection from your
> code.  Instead of accessing the jump stub intended to be used by code, you
> can access the pointer in the import table directly.  Something like this:
>
> extern __imp_MyWord:DWORD
>
> mov eax,[__imp_MyWord]
> mov eax,[eax]
>
> I doubt there's away for the assembler to do this indirection
> automatically for you.  It would have to clobber a register wouldn't
> work in the general case.
>
> Note that you can also access the import table directly to remove a
> level of indirection from calls to another DLL:
>
> extern __imp_MyProc:DWORD
>
> call [__imp_MyProc]
>
> Ross Ridge
>
> --
>  l/  //   Ross Ridge -- The Great HTMU
> [oo][oo]  rridge@csclub.uwaterloo.ca
> -()-/()/  http://www.csclub.uwaterloo.ca/~rridge/
>  db  //

[toc] | [prev] | [next] | [standalone]

#642

R.Wieser <address@not.available> wrote:
>Are you sure ?   In my example-code I had to use a "+WORD" in the first line
>(to skip the FF 25  (a jump command ) preceeding the actual address).  How
>come you do not need it ?

Because my example code bypasses that extra level of indireciton.
The import library that you link your assembler code implements the
import linkage with something like this:

		PUBLIC	MyData,__imp_MyData

		SEGMENT	.text
	MyData:
		jmp	[__imp_MyData]
		ENDS

		SEGMENT	.idata$5
	__imp_MyData DD	?
		ENDS

It's the __imp_MyData variable that gets fixed up by Windows to point at
the correct address, not the jump instruction.  You don't need to use
the jump instruction to find this variable, just use the __imp_MyData
label access it directly instead.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#643

Hello Ross,

> The import library that you link your assembler code
> implements the import linkage with something like this:
>
> PUBLIC MyData,__imp_MyData

I think I have a problem here.  You see, looking with  TDUMP (at either the
.DLL or the .LIB) I do not see that second variable:

Exports from dlldata.DLL
  2 exported name(s), 2 export addresse(s).  Ordinal base is 1.
    Ordinal RVA       Name
    ------- --------  ----
    0001    0000201b  MyData
    0000    0000102c  MyProc

I created MyData like this:

PUBLICDLL MyData
MyData dd 12345678h

Getting my hands on a true pointer does appeal to me (maybe I can even drop
the "MyData" label and only keep the "__imp_MyData" one ?), so how do you
define the data (in the DLL) so that it generates both those labels ?

And if it matters, I'm extracting the library from the DLL using, ofcourse,
Borlands "ImpLib".

Regards,
Rudy Wieser


Ross Ridge <rridge@csclub.uwaterloo.ca> schreef in berichtnieuws
jrah5p$die$1@rumours.uwaterloo.ca...
> R.Wieser <address@not.available> wrote:
> >Are you sure ?   In my example-code I had to use a "+WORD" in the first
line
> >(to skip the FF 25  (a jump command ) preceeding the actual address).
How
> >come you do not need it ?
>
> Because my example code bypasses that extra level of indireciton.
> The import library that you link your assembler code implements the
> import linkage with something like this:
>
> PUBLIC MyData,__imp_MyData
>
> SEGMENT .text
> MyData:
> jmp [__imp_MyData]
> ENDS
>
> SEGMENT .idata$5
> __imp_MyData DD ?
> ENDS
>
> It's the __imp_MyData variable that gets fixed up by Windows to point at
> the correct address, not the jump instruction.  You don't need to use
> the jump instruction to find this variable, just use the __imp_MyData
> label access it directly instead.
>
> Ross Ridge
>
> --
>  l/  //   Ross Ridge -- The Great HTMU
> [oo][oo]  rridge@csclub.uwaterloo.ca
> -()-/()/  http://www.csclub.uwaterloo.ca/~rridge/
>  db  //

[toc] | [prev] | [next] | [standalone]

#644

R.Wieser <address@not.available> wrote:
>Getting my hands on a true pointer does appeal to me (maybe I can even drop
>the "MyData" label and only keep the "__imp_MyData" one ?), so how do you
>define the data (in the DLL) so that it generates both those labels ?

With Microsoft's tool (or the GNU tools) the __imp_MyData labels are
generated automatically in the import libraries that you use link into
your library.  (They don't exist in the DLLs themselves though.)

It looks like Borland's tools do it differently, and don't generate the
__imp_ labels.  It handles code import differently from data imports.
When importing data the variable in the import table gets called "MyData".

>And if it matters, I'm extracting the library from the DLL using, ofcourse,
>Borlands "ImpLib".

This might be the problem.  I don't think the implib utility can tell the
difference between data and code being exported from a DLL so generates
only code imports.  Try using the import library created by the linker
with the -Gi flag instead.  Then just use the MyData label with only
one level indirection:

	mov	eax,[MyData]
	mov	eax,[eax]

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#645

Hello Ross,

> This might be the problem.  I don't think the implib utility can
> tell the difference between data and code being exported from
> a DLL so generates only code imports.

That is why I was looking for more info to the 'PublicDLL' spec.  I had
hoped that I could either add some info or use anoither like it so ImpLib
would know the provided label was not a procedure, but data.

In absence of such a specific data-export related command ImpLib could do a
"best guess" depending on the label being in a code or data segement.

> Try using the import library created by the linker
> with the -Gi flag instead.

Alas, I'm using Borlands tools, and they do not seem to have such a switch.

Regards,
Rudy Wieser


-- Origional message:
Ross Ridge <rridge@csclub.uwaterloo.ca> schreef in berichtnieuws
jrd1i5$1od$1@rumours.uwaterloo.ca...
> R.Wieser <address@not.available> wrote:
> >Getting my hands on a true pointer does appeal to me (maybe I can even
drop
> >the "MyData" label and only keep the "__imp_MyData" one ?), so how do you
> >define the data (in the DLL) so that it generates both those labels ?
>
> With Microsoft's tool (or the GNU tools) the __imp_MyData labels are
> generated automatically in the import libraries that you use link into
> your library.  (They don't exist in the DLLs themselves though.)
>
> It looks like Borland's tools do it differently, and don't generate the
> __imp_ labels.  It handles code import differently from data imports.
> When importing data the variable in the import table gets called "MyData".
>
> >And if it matters, I'm extracting the library from the DLL using,
ofcourse,
> >Borlands "ImpLib".
>
> This might be the problem.  I don't think the implib utility can tell the
> difference between data and code being exported from a DLL so generates
> only code imports.  Try using the import library created by the linker
> with the -Gi flag instead.  Then just use the MyData label with only
> one level indirection:
>
> mov eax,[MyData]
> mov eax,[eax]
>
> Ross Ridge
>
> --
>  l/  //   Ross Ridge -- The Great HTMU
> [oo][oo]  rridge@csclub.uwaterloo.ca
> -()-/()/  http://www.csclub.uwaterloo.ca/~rridge/
>  db  //

[toc] | [prev] | [next] | [standalone]

#646

In article <4fda3fd6$0$6920$e4fe514c@news2.news.xs4all.nl>,
>Hello Ross,
>
>> This might be the problem.  I don't think the implib utility can
>> tell the difference between data and code being exported from
>> a DLL so generates only code imports.
>
>That is why I was looking for more info to the 'PublicDLL' spec.  I had
>hoped that I could either add some info or use anoither like it so ImpLib
>would know the provided label was not a procedure, but data.
> Try using the import library created by the linker
> with the -Gi flag instead.

R.Wieser <address@not.available> wrote:
>Alas, I'm using Borlands tools, and they do not seem to have such a switch.

That's the switch my copy of Borland's ILINK32 (from the free Borland
C++ 5.5 distrubution) uses to generate an import library at link time.
You might try using that version of the linker.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#647

Hello Ross,

> That's the switch my copy of Borland's ILINK32 (from the
> free Borland C++ 5.5 distrubution) uses to generate an
> import library at link time.

Ah, that might be the difference: I'm using Borlands Tasm v5.0, which
contains Tasm32, TLink32, TDump, etc.

> You might try using that version of the linker.

Although I'm not looking for link-time generation, I don't think it would
hurt to take a look at it.  Thanks

Regards,
Rudy Wieser


-- Origional message:
Ross Ridge <rridge@csclub.uwaterloo.ca> schreef in berichtnieuws
jrdh3t$4cl$1@rumours.uwaterloo.ca...
> In article <4fda3fd6$0$6920$e4fe514c@news2.news.xs4all.nl>,
> >Hello Ross,
> >
> >> This might be the problem.  I don't think the implib utility can
> >> tell the difference between data and code being exported from
> >> a DLL so generates only code imports.
> >
> >That is why I was looking for more info to the 'PublicDLL' spec.  I had
> >hoped that I could either add some info or use anoither like it so ImpLib
> >would know the provided label was not a procedure, but data.
> > Try using the import library created by the linker
> > with the -Gi flag instead.
>
> R.Wieser <address@not.available> wrote:
> >Alas, I'm using Borlands tools, and they do not seem to have such a
switch.
>
> That's the switch my copy of Borland's ILINK32 (from the free Borland
> C++ 5.5 distrubution) uses to generate an import library at link time.
> You might try using that version of the linker.
>
> Ross Ridge
>
> --
>  l/  //   Ross Ridge -- The Great HTMU
> [oo][oo]  rridge@csclub.uwaterloo.ca
> -()-/()/  http://www.csclub.uwaterloo.ca/~rridge/
>  db  //

[toc] | [prev] | [next] | [standalone]

#648

Hi,

On Friday, June 15, 2012 5:18:06 AM UTC-5, R.Wieser wrote:
> 
> > That's the switch my copy of Borland's ILINK32 (from the
> > free Borland C++ 5.5 distrubution) uses to generate an
> > import library at link time.
> 
> Ah, that might be the difference: I'm using Borlands Tasm v5.0, which
> contains Tasm32, TLink32, TDump, etc.
> 
> > You might try using that version of the linker.
> 
> Although I'm not looking for link-time generation, I don't think it would
> hurt to take a look at it.  Thanks

I realize that this might not be directly helpful (as I've never messed with .DLLs ... yet!), but if you want to see how it's done, check out other peoples' code. Specifically, I'm referring to WDOSX and HX. At least WDOSX used TASM for .DLLs, so it should probably provide some insight (I hope!). HX uses JWasm (formerly MASM 6) for its .DLLs.

P.S. That also brings this on-topic, though you never actually said what OS you're targeting.  ;-)

http://tippach.business.t-online.de/wdosx/
http://www.japheth.de/HX.html

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.programmer

csiph-web