Using LccWin32, inline assembly.

This statement:

    _asm("call  %LoadLibrary");

generates this error:

error:  c:\\lcc\.... 44 (28770) (28770) incorrect register:
'%LoadLibrary'
Error c:\\lcc\... 96 Compiler error (trap). Stopping compilation

It makes no difference what comes before it.
That statement alone errors.

Any ideas ?

Steve

Le 15/10/10 06:04, steve a �crit :
> Using LccWin32, inline assembly.
>
> This statement:
>
>      _asm("call  %LoadLibrary");
>
> generates this error:
>
> error:  c:\\lcc\.... 44 (28770) (28770) incorrect register:
> '%LoadLibrary'
> Error c:\\lcc\... 96 Compiler error (trap). Stopping compilation
>
> It makes no difference what comes before it.
> That statement alone errors.
>
> Any ideas ?
>
> Steve

The error is correct, you have written a wrong register name
called "%loadLibrary"

A call statement should be followed by a function name.

That will not work unless you declare the function or
define it somewhere as extern.

And that will not work with a wrong function name like "LoadLibrary"
since a function with that name doesn't exist.

I strongly suspect that yu have no idea of what you are doing.

In that case just use C

On Oct 15, 5:30=A0am, jacob navia <ja...@jacob.remcomp.fr> wrote:
> Le 15/10/10 06:04, steve a =E9crit :


> The error is correct, you have written a wrong register name
> called "%loadLibrary"
>
> A call statement should be followed by a function name.

Okay,
here is a simple C statement:
    dll_handle =3D LoadLibrary(dllname);

here is what I think is a comparable inline asm statement:
    _asm("pushl $_dllname");
    _asm("call  %LoadLibrary");

how am I wrong here?

> That will not work unless you declare the function or
> define it somewhere as extern.

If the C program can "see" LoadLibrary, can not the inline asm see it
as well ?

>
> And that will not work with a wrong function name like "LoadLibrary"
> since a function with that name doesn't exist.

well, it exists somewhere in the API, no?
All the required #includes are in place.

>
> I strongly suspect that yu have no idea of what you are doing.
> In that case just use C

Jacob, you are correct.
This is my first attempt to use inline assembly with LccWin32.
Jacob, perhaps if your documentation described inline assembly I
wouldn't be asking what appears to you to be a stupid question.
Your documentation doesn't even describe AT&T syntax and it's usage.
I had to go to outside sources to find what I needed to even begin to
use it.

Jacob, does it occur to you that maybe I have a genuine need to use
inline assembly ?
I have been a proponent of LccWin32 for nearly ten years now.
I have based an entire project on it.
People ask me why?
Perhaps you could consider supporting your user-base a little more
positively.

Jacob, my question remains, if I stated LoadLibrary wrongly,
please indicate the correct way in which I might call that function.


Sincerely
Steve

Le 15/10/10 15:32, steve a �crit :
> On Oct 15, 5:30 am, jacob navia<ja...@jacob.remcomp.fr>  wrote:
>> Le 15/10/10 06:04, steve a �crit :
>
>
>> The error is correct, you have written a wrong register name
>> called "%loadLibrary"
>>
>> A call statement should be followed by a function name.
>
> Okay,
> here is a simple C statement:
>      dll_handle = LoadLibrary(dllname);
>
> here is what I think is a comparable inline asm statement:
>      _asm("pushl $_dllname");
>      _asm("call  %LoadLibrary");
>
> how am I wrong here?
>
>> That will not work unless you declare the function or
>> define it somewhere as extern.
>
> If the C program can "see" LoadLibrary, can not the inline asm see it
> as well ?
>
>>
>> And that will not work with a wrong function name like "LoadLibrary"
>> since a function with that name doesn't exist.
>
> well, it exists somewhere in the API, no?
> All the required #includes are in place.
>
>>
>> I strongly suspect that yu have no idea of what you are doing.
>> In that case just use C
>
> Jacob, you are correct.
> This is my first attempt to use inline assembly with LccWin32.
> Jacob, perhaps if your documentation described inline assembly I
> wouldn't be asking what appears to you to be a stupid question.
> Your documentation doesn't even describe AT&T syntax and it's usage.
> I had to go to outside sources to find what I needed to even begin to
> use it.
>

The problem is, inline asm is badly supported in lcc-win, and you have 
to know a lot more NORMAL assembly to use it.

(1) Why you put the "%" before LoadLibrary?
(2) The correct name is "LoadLibrary@4" since it is a stdcall
     function. That means the name is followed by "@" and then
     the number of bytes pushed by the arguments in the stack.


In general please write a C program.

THEN
compile it with

lcc -S foo.c

This will generate a foo.asm file with ALL the hard work done by the
compiler, extern declarations, name mangling as above, etc etc.

THEN

Modify it as you wish and assemble it with:

lcc foo.asm

This will generate a foo.obj file that you can link with.

This is better than inline asm, that I never finished correctly.

jacob

You are right that my answer was very stupid

I apologize for that. Sorry

These are inline API call examples from:
John Findlay's winasm.c program:

	_asm("call  %memset");
	_asm("call  %LoadIconA");
	_asm("call  %LoadCursorA");
	_asm("call  %RegisterClassA");
	_asm("call  %CreateWindowExA");
	_asm("call  %sprintf");
	_asm("call  %MessageBoxA");
	_asm("call  %EndDialog");
	_asm("call  %MessageBeep");
	_asm("call  %DialogBoxParamA");
	_asm("call  %PostMessageA");
	_asm("call  %BeginPaint");
	_asm("call  %GetClientRect");
	_asm("call  %DrawTextA");
	_asm("call  %EndPaint");
	_asm("call  %PostQuitMessage");
	_asm("call  %DefWindowProcA");
	_asm("call  %DispatchMessageA");
	_asm("call  %GetMessageA");

and they all work,

LccWin32 still will not accept:

        _asm("call  LoadLibrary@4");
-or-
        _asm("call  %LoadLibrary");

Steve

P.S.
I've been programming in Assembly Language longer than I've been
programming in LccWin32.

On Oct 15, 7:45=A0am, jacob navia <ja...@jacob.remcomp.fr> wrote:
> You are right that my answer was very stupid
>
> I apologize for that. Sorry

[snip]
>>And that will not work with a wrong function name like "LoadLibrary"
>>since a function with that name doesn't exist.
[snip]

These are inline API call examples from:
John Findlay's winasm.c program:

	_asm("call  %memset");
	_asm("call  %LoadIconA");
	_asm("call  %LoadCursorA");
	_asm("call  %RegisterClassA");
	_asm("call  %CreateWindowExA");
	_asm("call  %sprintf");
	_asm("call  %MessageBoxA");
	_asm("call  %EndDialog");
	_asm("call  %MessageBeep");
	_asm("call  %DialogBoxParamA");
	_asm("call  %PostMessageA");
	_asm("call  %BeginPaint");
	_asm("call  %GetClientRect");
	_asm("call  %DrawTextA");
	_asm("call  %EndPaint");
	_asm("call  %PostQuitMessage");
	_asm("call  %DefWindowProcA");
	_asm("call  %DispatchMessageA");
	_asm("call  %GetMessageA");

and they all work,

LccWin32 still will not accept:

        _asm("call  LoadLibrary@4");
-or-
        _asm("call  %LoadLibrary");

Steve

P.S.
I've been programming in Assembly Language longer than I've been
programming in LccWin32.

Le 15/10/10 17:28, steve a �crit :

The right call is
_asm("call _LoadLibrary@4");


I think the page from John is VERY old.
(From 2005)

Please can you tell me why do you need inline asm?
This feature is very badly supported.

Thanks

On Oct 15, 9:43=A0am, jacob navia <ja...@jacob.remcomp.fr> wrote:
> Please can you tell me why do you need inline asm?
> This feature is very badly supported.

C does not provide a means of direct control of the stack.
I need to be able to dynamically push arbitrary data types onto the
stack "at runtime",
like : dyncall, libffi, ffcall, c/invoke.

These data types are not known at compile-time, neither are the
function names.
I've tried doing this in plain C and I will not work.
C has no mechanism for dynamically passing arbitrary data types or
arbitrary numbers of parameters at runtime.

It appears, this is best done in asm.
Examples I've seen did it using inline assembly.
I may have to do the assembly in Masm or Nasm and link the .obj file.

Steve

steve <blunt.axe.basic@gmail.com> wrote:
(snip)

> C does not provide a means of direct control of the stack.
> I need to be able to dynamically push arbitrary data types onto the
> stack "at runtime",
> like : dyncall, libffi, ffcall, c/invoke.
 
> These data types are not known at compile-time, neither are the
> function names.
> I've tried doing this in plain C and I will not work.
> C has no mechanism for dynamically passing arbitrary data types or
> arbitrary numbers of parameters at runtime.

Well, you can pass a struct containing an array long enough
for the longest combination of data that you want to pass.
C doesn't provide the length of the argument list to the caller,
so it wouldn't be a problem if it was too long.

Copy everything into an array of unsigned char.
 
> It appears, this is best done in asm.
> Examples I've seen did it using inline assembly.
> I may have to do the assembly in Masm or Nasm and link the .obj file.

-- glen

On Oct 15, 11:48=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

> Well, you can pass a struct containing an array long enough
> for the longest combination of data that you want to pass.
> -- glen

Well that won't work either.
For instance, let's say I create a struct or a union:

union MyData
{
   int myint;
   float myfloat;
   char mystring[20];
};
union MyData param[4];

I have previously declared a generic function pointer: FuncPtr,
which points to "MessageBoxA",

now, I decide I want to call MessageBox: (shorthand version),
1) param[0].int =3D hwnd;
2) param[1].mystring =3D "hello world";
3) param[2].mystring =3D "Hello";
4) param[3].int =3D MB_OK;

5)      FuncPtr(params[0].int, param[1].mystring, param[2].mystring,
param[3].int);

Line 5 is the problem.
To do this is C, I would have to have enumerable templates, with all
the possible combinations of parameters.

In assembly, I would simply push each parameter value or it's address
onto the stack and call the function.
[code]

    invoke LoadLibrary, addr LibName
    .if eax =3D=3D NULL                  ; error handler
        <snip>
    .endif
    mov hLib, eax
    invoke GetProcAddress, hLib, addr FunctionName
    .if eax =3D=3D NULL                  ; error handler
        <snip>
    .endif
    mov MssgBoxAddr, eax    ; push 4 vars
    push mtype
    mov eax, offset caption
    push eax
    mov eax, offset text
    push eax
    push handl
    call [MssgBoxAddr]

[/code]

Doing this in assembly is the only way I know that works.
I've tried every way possible in C, but, by using C alone it just
doesn't work.
By using assembly, all I have to do is parse the variable types and
push them onto the stack.
Then, using a function pointer,  call the function.

Steve

steve <blunt.axe.basic@gmail.com> wrote:
(I wrote)
 
>> Well, you can pass a struct containing an array long enough
>> for the longest combination of data that you want to pass.
 
> Well that won't work either.
> For instance, let's say I create a struct or a union:
 
> union MyData
> {
>   int myint;
>   float myfloat;
>   char mystring[20];
> };
> union MyData param[4];
 
> I have previously declared a generic function pointer: FuncPtr,
> which points to "MessageBoxA",
 
> now, I decide I want to call MessageBox: (shorthand version),
> 1) param[0].int = hwnd;
> 2) param[1].mystring = "hello world";
> 3) param[2].mystring = "Hello";
> 4) param[3].int = MB_OK;
> 
> 5)      FuncPtr(params[0].int, param[1].mystring, param[2].mystring,
> param[3].int);
 
> Line 5 is the problem.
> To do this is C, I would have to have enumerable templates, with all
> the possible combinations of parameters.
 
> In assembly, I would simply push each parameter value or it's address
> onto the stack and call the function.
> [code]

The suggestion was to create a struct containing a large
unsigned char array, and pass that.  C will push the whole struct
onto the stack.  You can then memcpy() addresses or values into
the struct with appropriate offsets.  It will, of course, be
non-portable, though a little more than assembly language.
Among others, you have to do the appropriate stack alignment
and padding of smaller values.

Loop down the char array, incrementing by sizeof(each item),
and memcpy() the item in place, or a pointer to it.
 
>    invoke LoadLibrary, addr LibName
>    .if eax == NULL                  ; error handler
>        <snip>
>    .endif
>    mov hLib, eax
>    invoke GetProcAddress, hLib, addr FunctionName
>    .if eax == NULL                  ; error handler
>        <snip>
>    .endif
>    mov MssgBoxAddr, eax    ; push 4 vars
>    push mtype
>    mov eax, offset caption
>    push eax
>    mov eax, offset text
>    push eax
>    push handl
>    call [MssgBoxAddr]
> 
> [/code]
 
> Doing this in assembly is the only way I know that works.
> I've tried every way possible in C, but, by using C alone it just
> doesn't work.
> By using assembly, all I have to do is parse the variable types and
> push them onto the stack.
> Then, using a function pointer,  call the function.

-- glen

Le 15/10/10 23:49, steve a �crit :
> Doing this in assembly is the only way I know that works.
> I've tried every way possible in C, but, by using C alone it just
> doesn't work.
> By using assembly, all I have to do is parse the variable types and
> push them onto the stack.
> Then, using a function pointer,  call the function.
>
> Steve

Look Steve I understand your problem but my problem is that inline asm
supportis not very good.

I told you how to call LoadLibrary. Now, at least THAT works.
Please tell me of any other problems you may encounter.

jacob

On 15/10/2010 05:04, steve wrote:
> Using LccWin32, inline assembly.
>
> This statement:
>
>      _asm("call  %LoadLibrary");
>
> generates this error:
>
> error:  c:\\lcc\.... 44 (28770) (28770) incorrect register:
> '%LoadLibrary'
> Error c:\\lcc\... 96 Compiler error (trap). Stopping compilation
>
> It makes no difference what comes before it.
> That statement alone errors.
>
> Any ideas ?
>
> Steve

Steve, use the ANSI or UNICODE versions.

i.e.

   _asm("call   %LoadLibraryA");


John

On Oct 16, 12:24=A0am, jacob navia <ja...@jacob.remcomp.fr> wrote:
> Le 15/10/10 23:49, steve a =E9crit :
> Look Steve I understand your problem but my problem is that inline asm
> supportis not very good.
>
> I told you how to call LoadLibrary. Now, at least THAT works.
> Please tell me of any other problems you may encounter.
>
> jacob

Jacob,
Thanks for all your help.
I understand the issues with trying to use inline asm in LccWin.
And, after trying it further, I see what you mean in that it is poorly
supported.
When I look at the asm code generated after using even the simplest
statement,
Lcc seems to corrupt the inline statement in a way that it doesn't
work.
Here is an example of just adding these three lines:
        _asm("pushl  $_dllname");
        _asm("call   _LoadLibraryA@4");
        _asm("movl   %eax, %hLib");

and this is the result (main.asm file) after compile:

	.line	30
pushl  $_dllname
	.line	38
call   _LoadLibraryA@4
;   39         _asm("call   _LoadLibraryA@4");
	.line	39
movl   %eax, _hLib
;   40         _asm("movl   %eax, %hLib");


which fails, with the following error:

"Error main.obj: Undefined (*UND*). Symbol _LoadLibraryA@4"

Any way...,at this point it looks like, which ever part of the
compiler that scans the asm code, thinks that _LoadLibrary is a
"label" and not a function.
Now maybe this is a fixable bug, or, this is just the way Lcc works, I
don't know.

When I take the same code and manually insert it into a compiled,
empty main.asm and recompile it like so:

Lcc main.asm

it does compile correctly and it runs, but, the file size is 101 Kb in
size, as opposed to 31 Kb.
What's that all about ?

Unless Lcc can be adjusted to accept inline _asm statements, (without
corrupting them), it looks like I'm just going to have to use Masm or
Nasm to build LIB file and add it to the link list.

Steve

On Oct 16, 2:13=A0am, John <u...@example.net> wrote:
> On 15/10/2010 05:04, steve wrote:
>
>
>
>
>
> > Using LccWin32, inline assembly.
>
> > This statement:
>
> > =A0 =A0 =A0_asm("call =A0%LoadLibrary");
>
> > generates this error:
>
> > error: =A0c:\\lcc\.... 44 (28770) (28770) incorrect register:
> > '%LoadLibrary'
> > Error c:\\lcc\... 96 Compiler error (trap). Stopping compilation
>
> > It makes no difference what comes before it.
> > That statement alone errors.
>
> > Any ideas ?
>
> > Steve
>
> Steve, use the ANSI or UNICODE versions.
>
> i.e.
>
> =A0 =A0_asm("call =A0 %LoadLibraryA");
>
> John- Hide quoted text -
>
> - Show quoted text -

Hey John,

I've tried that.
After examining the asm code that Lcc generates, it's not the method I
use to call LoadLibrary.
It's what Lcc does to inline asm statements during the compile phase.
See the previous post.

Thanks,
Steve

On 17/10/2010 00:15, steve wrote:
> On Oct 16, 2:13 am, John<u...@example.net>  wrote:
>> On 15/10/2010 05:04, steve wrote:
>>
>>
>>
>>
>>
>>> Using LccWin32, inline assembly.
>>
>>> This statement:
>>
>>>       _asm("call  %LoadLibrary");
>>
>>> generates this error:
>>
>>> error:  c:\\lcc\.... 44 (28770) (28770) incorrect register:
>>> '%LoadLibrary'
>>> Error c:\\lcc\... 96 Compiler error (trap). Stopping compilation
>>
>>> It makes no difference what comes before it.
>>> That statement alone errors.
>>
>>> Any ideas ?
>>
>>> Steve
>>
>> Steve, use the ANSI or UNICODE versions.
>>
>> i.e.
>>
>>     _asm("call   %LoadLibraryA");
>>
>> John- Hide quoted text -
>>
>> - Show quoted text -
>
> Hey John,
>
> I've tried that.
> After examining the asm code that Lcc generates, it's not the method I
> use to call LoadLibrary.
> It's what Lcc does to inline asm statements during the compile phase.
> See the previous post.
>
> Thanks,
> Steve
>
>

This compiles without error.

    _asm("pushl  $_dllname");
    _asm("call   %LoadLibraryA");
    _asm("movl   %eax, %hLib");

John

On Oct 16, 11:08=A0pm, John <u...@example.net> wrote:
> This compiles without error.
>
> =A0 =A0 _asm("pushl =A0$_dllname");
> =A0 =A0 _asm("call =A0 %LoadLibraryA");
> =A0 =A0 _asm("movl =A0 %eax, %hLib");
>
> John

Hey John,
I'm using the latest version of LccWin32, updated this past week.

here is a simple inline listing:
[code]
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

   void * (__stdcall *stdcall_func)();

    char dllname[20]=3D"user32.dll";
    char functionname[20]=3D"MessageBoxA";

    HWND hwnd=3D0;
    UINT utype=3D1;
   char text[] =3D "Hello Windows!";
   char strng[] =3D "Winasm";
   HMODULE hLib=3D0;


int main()
{
        _asm("pushl  $_dllname");
        _asm("call   _LoadLibraryA@4");
        _asm("movl   %eax, _hLib");

        _asm("pushl  $_functionname");
        _asm("pushl  %hLib");
        _asm("call   _GetProcAddress@8");
        _asm("movl   %eax, _stdcall_func");

        _asm("pushl  _utype");
        _asm("pushl  $_strng");
        _asm("pushl  $_text");
        _asm("pushl  _hwnd");
        _asm("call   *_stdcall_func");

    FreeLibrary(hLib);

    system("pause");
    return 0;
}
/*--------- end main ----------*/
[/code]
It produces this error message:
Error main.obj: Undefined (*UND*). Symbol _LoadLibraryA@4

This is the "asm" listing generated:
[asm]
;   19 int main()
	.type	_main,function
_main:
;   20 {
	.line	20
pushl  $_dllname
;   21         _asm("pushl  $_dllname");
	.line	21
call   _LoadLibraryA@4
;   22         _asm("call   _LoadLibraryA@4");
	.line	22
movl   %eax, _hLib
;   23         _asm("movl   %eax, _hLib");
	.line	23
pushl  $_functionname
;   24
;   25         _asm("pushl  $_functionname");
	.line	25
pushl  _hLib
;   26         _asm("pushl  %hLib");
	.line	26
call   _GetProcAddress@8
;   27         _asm("call   _GetProcAddress@8");
	.line	27
movl   %eax, _stdcall_func
;   28         _asm("movl   %eax, _stdcall_func");
	.line	28
pushl  _utype
;   29
;   30         _asm("pushl  _utype");
	.line	30
pushl  $_strng
;   31         _asm("pushl  $_strng");
	.line	31
pushl  $_text
;   32         _asm("pushl  $_text");
	.line	32
pushl  _hwnd
;   33         _asm("pushl  _hwnd");
	.line	33
call   *_stdcall_func
;   34         _asm("call   *_stdcall_func");
;   35
;   36     FreeLibrary(hLib);
	.line	36
	pushl	_hLib
	call	_FreeLibrary@4
;   37
;   38     system("pause");
	.line	38
	pushl	$_$131
	call	_system
	addl	$4,%esp
;   39     return 0;
	.line	39
	movl	$0,%eax
_$130:
;   40 }
	.line	40
	ret
_$132:
	.size	_main,_$132-_main
	.globl	_main
	.bss
	.globl	_stdcall_func
	.align	2
	.type	_stdcall_func,object
	.comm	_stdcall_func,4
	.extern	_FreeLibrary@4
	.extern	_system
	.data
_$131:
; "pause\x0"
	.byte	112,97,117,115,101,0
_$129:
; "://\x0"
	.byte	58,47,47,0
[/asm]

As you can see, all the inline instructions are now all left aligned.
No indentation.
That may be part of the problem.

Steve

On 17/10/2010 17:08, steve wrote:
> It produces this error message:
> Error main.obj: Undefined (*UND*). Symbol _LoadLibraryA@4
> Steve


I did not use this

_asm("call   _LoadLibraryA@4");


I used this

_asm("call   %LoadLibraryA");

Try it.

John

On Oct 17, 9:28=A0am, John <u...@example.net> wrote:
> On 17/10/2010 17:08, steve wrote:
>
> > It produces this error message:
> > Error main.obj: Undefined (*UND*). Symbol _LoadLibraryA@4
> > Steve
>
> I did not use this
>
> _asm("call =A0 _LoadLibraryA@4");
>
> I used this
>
> _asm("call =A0 %LoadLibraryA");
>
> Try it.
>
> John

Hey John,
Okay, I was sure I tried that before.
I must not have, because that does work!
You are the "inline" expert !   ;-)

I find it odd, that the C generated version generates
"_LoadLibrary@4",
but will not accept that statement when used inline.
I also had to change _GetProcAddress@8 to %GetProcAddress.

I was trying to use the C generated asm code as a guide, but, I guess
I can't do that and expect it to work.
Besides Winasm.c, where can I find a listing of any other
idiosyncrasies in using inline asm with LccWin32 ?

You are the man !
Steve

On 17/10/2010 18:03, steve wrote:
>
> Hey John,
> Okay, I was sure I tried that before.
> I must not have, because that does work!
> You are the "inline" expert !   ;-)
>
> I find it odd, that the C generated version generates
> "_LoadLibrary@4",
> but will not accept that statement when used inline.
> I also had to change _GetProcAddress@8 to %GetProcAddress.
>
> I was trying to use the C generated asm code as a guide, but, I guess
> I can't do that and expect it to work.
> Besides Winasm.c, where can I find a listing of any other
> idiosyncrasies in using inline asm with LccWin32 ?
>
> You are the man !
> Steve

As Jacob said inline asm is not well supported so you are
on your own - except anything you can find on my web site
or anywhere else on the internet.

However having said that you should have no trouble now with
Windows API's and standard library functions.

If something doesn't work, try it another way, you might be
surprised how much you can get done.

John

Le 17/10/10 01:11, steve a �crit :
> On Oct 16, 12:24 am, jacob navia<ja...@jacob.remcomp.fr>  wrote:
>> Le 15/10/10 23:49, steve a �crit :
>> Look Steve I understand your problem but my problem is that inline asm
>> supportis not very good.
>>
>> I told you how to call LoadLibrary. Now, at least THAT works.
>> Please tell me of any other problems you may encounter.
>>
>> jacob
>
> Jacob,
> Thanks for all your help.
> I understand the issues with trying to use inline asm in LccWin.
> And, after trying it further, I see what you mean in that it is poorly
> supported.
> When I look at the asm code generated after using even the simplest
> statement,
> Lcc seems to corrupt the inline statement in a way that it doesn't
> work.
> Here is an example of just adding these three lines:
>          _asm("pushl  $_dllname");
>          _asm("call   _LoadLibraryA@4");
>          _asm("movl   %eax, %hLib");
>
> and this is the result (main.asm file) after compile:
>
> 	.line	30
> pushl  $_dllname
> 	.line	38
> call   _LoadLibraryA@4
> ;   39         _asm("call   _LoadLibraryA@4");
> 	.line	39
> movl   %eax, _hLib
> ;   40         _asm("movl   %eax, %hLib");
>
>
> which fails, with the following error:
>
> "Error main.obj: Undefined (*UND*). Symbol _LoadLibraryA@4"
>


You should add at the beginning of the file
	.extern   _LoadLibraryA@4

Normally, the compiler will add those lines automatically for all 
external functions that it sees. Since you use inline asm it will not 
and the link fails.


> Any way...,at this point it looks like, which ever part of the
> compiler that scans the asm code, thinks that _LoadLibrary is a
> "label" and not a function.

No, it is that you have to declare your externals youself.

> Now maybe this is a fixable bug, or, this is just the way Lcc works, I
> don't know.
>

It is fixable but... I am afraid that it will not be the last problem
we see.

But anyway, for your purposes (just making some pushes) it could work.

Please tell me any new problem you encounter.

On Oct 17, 11:42=A0am, John <u...@example.net> wrote:
>
> As Jacob said inline asm is not well supported so you are
> on your own - except anything you can find on my web site
> or anywhere else on the internet.
>
> However having said that you should have no trouble now with
> Windows API's and standard library functions.
>
> If something doesn't work, try it another way, you might be
> surprised how much you can get done.
>
> John- Hide quoted text -
>
> - Show quoted text -

Thanks John

Steve

On Oct 14, 9:04=A0pm, steve <blunt.axe.ba...@gmail.com> wrote:
> Using LccWin32, inline assembly.

Does anyone know a "download" link for the docs or manual for the Gas
assembler ?
AT&T syntax is what I'm looking for.
I can find it for online viewing, but, I prefer to download it.

Steve

Le 17/10/10 18:08, steve a �crit :
> /*--------- end main ----------*/
> [/code]
> It produces this error message:
> Error main.obj: Undefined (*UND*). Symbol _LoadLibraryA@4
>
You have to declare the functions you use as
	.extern	_LoadLibraryA@4
as I said in another message

Le 18/10/10 00:32, steve a �crit :
> On Oct 14, 9:04 pm, steve<blunt.axe.ba...@gmail.com>  wrote:
>> Using LccWin32, inline assembly.
>
> Does anyone know a "download" link for the docs or manual for the Gas
> assembler ?
> AT&T syntax is what I'm looking for.
> I can find it for online viewing, but, I prefer to download it.
>
> Steve

Note that lcc-win assembler is NOT gas. It is a new assembler that has 
with gas only
SOME compatibility (because there was already a machine description 
written in GAS) but it is missing probably 70% of GAS features...

My objective was just to have a backend assembler, not to build a GAS clone.

On Oct 18, 3:26=A0am, jacob navia <ja...@spamsink.net> wrote:
> Le 18/10/10 00:32, steve a =E9crit :
>
> > On Oct 14, 9:04 pm, steve<blunt.axe.ba...@gmail.com> =A0wrote:
> >> Using LccWin32, inline assembly.
>
> > Does anyone know a "download" link for the docs or manual for the Gas
> > assembler ?
> > AT&T syntax is what I'm looking for.
> > I can find it for online viewing, but, I prefer to download it.
>
> > Steve
>
> Note that lcc-win assembler is NOT gas. It is a new assembler that has
> with gas only
> SOME compatibility (because there was already a machine description
> written in GAS) but it is missing probably 70% of GAS features...
>
> My objective was just to have a backend assembler, not to build a GAS clo=
ne.

Ok, thanks jacob.

steve wrote:
> On Oct 14, 9:04 pm, steve <blunt.axe.ba...@gmail.com> wrote:
>> Using LccWin32, inline assembly.
> 
> Does anyone know a "download" link for the docs or manual for the Gas
> assembler ?
> AT&T syntax is what I'm looking for.
> I can find it for online viewing, but, I prefer to download it.

The "official" resource has long been a 38-page draft done by ISC while
developping the real AT&T assembler back in 1986. It has been published
on Usenet <news:902@bigfoot.first.gmd.de>, still available at
http://groups.google.com/groups?selm=902@bigfoot.first.gmd.de

Nowadays, Sun (which inherited the actual work) keeps it up to date in
"x86 Assembly Language Reference Manual", and makes it available in PDF
form from http://docs.sun.com/ (817-5477 is the last published version,
corresponding to Solaris 10; 82 p.)


As Jacob highlighted, this is the real "AT&T syntax", and lcc-win32/64
does not have to strictly adhere to this syntax (neither has to, nor
does, the GNU assembler, which over the years gained a lot of features).


Antoine

On Oct 20, 3:23=A0am, Antoine Leca <r...@localhost.invalid> wrote:
> The "official" resource has long been a 38-page draft done by ISC while
> developping the real AT&T assembler back in 1986. It has been published
> on Usenet <news:902@bigfoot.first.gmd.de>, still available at
> http://groups.google.com/groups?selm=3D...@bigfoot.first.gmd.de
>
> Nowadays, Sun (which inherited the actual work) keeps it up to date in
> "x86 Assembly Language Reference Manual", and makes it available in PDF
> form fromhttp://docs.sun.com/(817-5477 is the last published version,
> corresponding to Solaris 10; 82 p.)
>
> As Jacob highlighted, this is the real "AT&T syntax", and lcc-win32/64
> does not have to strictly adhere to this syntax (neither has to, nor
> does, the GNU assembler, which over the years gained a lot of features).
>
> Antoine

Thanks Antoine

Steve