News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Problems with creating a Struct in MASM32.

Started by Shooter, February 15, 2011, 09:08:59 PM

Previous topic - Next topic

dedndave

well - there are a few issues there
first - you have much of that stuff declared elsewhere
second - you're on the drive E:
is that the drive where you have MASM32 installed ?
third - i noticed you have no paths in your INCLUDE's
i guess you have the LIB and INCLUDE environment variables set ?

finally - have a look in the file \masm32\include\masm32rt.inc
you can see what it does   :U

Shooter

Quote from: dedndave on February 19, 2011, 08:46:58 PM
well - there are a few issues there
first - you have much of that stuff declared elsewhere
second - you're on the drive E:
is that the drive where you have MASM32 installed ?
third - i noticed you have no paths in your INCLUDE's
i guess you have the LIB and INCLUDE environment variables set ?

finally - have a look in the file \masm32\include\masm32rt.inc
you can see what it does   :U

Yup, everything is on my thumb-drive, E:. Yup, my environment is already established to those paths. Huh? Declared elsewhere? How does that keep a file from being read in? I should've received a different error, right?
Never use direct references to anything ever. Bury everything in
macros. Bury the macros in include files. Reference those include
files indirectly from other include files. Use macros to reference
those include files.

dedndave

as i said - have a look inside that file
you have most of the stuff it includes elsewhere in your source (your ReadRegKey.inc file)

at any rate - you should assemble from the same drive as masm32 is installed
and - the masm32 folder must be in the root
then - specify paths like i did in the example code

the entire library is set up to work that way
not how i would have done it - but that is how it is   :P

dedndave

here is the EXE for you to play with Scott
later on, when i have some time, i will make a proper version using structures...

Shooter

Quote from: dedndave on February 19, 2011, 09:13:59 PM
here is the EXE for you to play with Scott
later on, when i have some time, i will make a proper version using structures...


Thank you very much, especially for your efforts. There's a lot more data than I thought there'd be, or is that just a result of ECX=128?
Never use direct references to anything ever. Bury everything in
macros. Bury the macros in include files. Reference those include
files indirectly from other include files. Use macros to reference
those include files.

dedndave

i just didn't know how much to display
after all, it is an 8 Kb buffer - it can hold 2048 dwords
on my machine, of the 128 dwords shown, most are 0's at the end
it looks like only a couple structures worth of stuff

but - you can see what the values are by looking at the corresponding names in the structure

MichaelW

When you see C statements like:

MIB_IPADDRROW table[ANY_SIZE];

It generally means that you need to allocate memory dynamically because you don't know at assembly time what the required buffer size will be. Accessing the buffer in assembly is a little more difficult than it is in C, but still not a problem.

The attachment contains the Microsoft example from here, in C and in assembly (MSDN was inaccessible at the time I posted this, but the link was working earlier).

eschew obfuscation

Shooter

Dave,
I modified to your code example for the purpose of my program:
        mov     edx,offset BigAssBuffer
        mov     ecx,16

loop00: push    ecx
        push    edx
        mov     eax,[edx]
;        print   uhex$(eax),32
        pop     edx
        pop     ecx
        add     edx,4
        loop    loop00
        lea eax, BigAssBuffer
        invoke inet_ntoa,eax
        mov DWORD PTR [lpbSubnetMask], eax
        mov eax, DWORD PTR [BigAssBuffer]+16
        invoke inet_ntoa,eax
        mov DWORD PTR [lpbDNSAddress], eax

and I get two addresses that are not showing up on my LAN Status dialog: 78.88.64.0 and 1.0.0.0. I'll need to do some research to identify where in that BigAssBuffer the Subnet Mask (should be 255.255.0.0) and Default Gateway (should be 172.17.1.1) are supposed to be.

Michael,
I tried that link, but I get
QuoteThe specified CGI application encountered an error and the server terminated the process.
Not sure what's going on there.

-Shooter
Never use direct references to anything ever. Bury everything in
macros. Bury the macros in include files. Reference those include
files indirectly from other include files. Use macros to reference
those include files.

dedndave

#38
Scott
does the program Michael posted work for you ?
it works ok here - i really can't improve on it - lol
it is a port of the msdn example - which is what i planned on doing
well - a little mysterious that one structure is 24 bytes, one is 28 bytes, the function requires 300, and i only have 2 devices - lol

but - we have to get your installation working correctly
if you cannot assemble the example programs posted, you are working with one hand tied behind your back

the print macro requires:
        INCLUDE    \masm32\include\masm32.inc
        INCLUDE    \masm32\macros\macros.asm
        INCLUDELIB \masm32\lib\masm32.lib


notice the path of macros.asm - in my earlier PM, i think i had it wrong

MichaelW

I was thinking that perhaps the explanation for the 300 byte buffer size was that there were other entries that were not included in the dwNumEntries count, but when I alter the code to display the next entry I get:

        Interface Index[2]:     0
        IP Address[2]:          0.0.0.0
        Subnet Mask[2]:         0.0.0.0
        BroadCast[2]:           0.0.0.0 (0)
        Reassembly size[2]:     0
        Type and State[2]:

eschew obfuscation

dedndave

i think the 300 bytes is some sort of "minimum size" or something for this function
it may be usable by other API's that rely on this function as a prerequisite - like what was it - AddIPAddress, etc

dedndave

Scott,
let's get this working...
you should be able to assemble and run this program
        INCLUDE    \masm32\include\masm32rt.inc

        .CODE

_main   PROC

        print   chr$('Hello World'),13,10
        inkey
        exit

_main   ENDP

        END     _main

Shooter

Sorry guys. I went to a college bar last night and, well... I'm gonna need a few hours to get my head back on level. The ole' grey matter ain't what it used to be. :red
Never use direct references to anything ever. Bury everything in
macros. Bury the macros in include files. Reference those include
files indirectly from other include files. Use macros to reference
those include files.

Shooter

Dave,
I've manually edited the "masm32rt.inc" file to remove any path reference, which works just fine for all the .lib .inc references, but the environmental settings do not include a path for .asm files (macros.asm is in this file)... not really sure how to get RadASM to play nice with that.

Michael,
Is it safe to assume that "Interface Index
  • " will always be the NIC that's actively connected to a network? I don't see a reason to go beyond reading any more info if that's the case. All of the computers I'll be dealing with will only have one NIC and unless there's a problem connecting to the domain, that's the only set of addresses I need.

    Truth be told, I'm not sure what the other indexes are referring to.

    Also, I noticed that your example did not come up with the Default Gateway address. Is that a shortcoming of doing it this way, or did I miss something?

    Thanks,
    -Shooter
Never use direct references to anything ever. Bury everything in
macros. Bury the macros in include files. Reference those include
files indirectly from other include files. Use macros to reference
those include files.

dedndave

well - that's not a very good fix - lol
you might try assembling with the /X switch (ML)

(after restoring the paths in masm32rt.inc)