Now that my Visual Basic 6 PSet() and Point() test is complete and produced
valid results, much optimization and speed is required.

Nineteen lines of assembly have been written to replace the nested for-next
pset/point loops.

Research indicated that nasm-0.98.39-win32 is the compiler to use. It
functions well.

link.exe v 6.0.8447.0 from Microsoft always produces errors regarding symbols.

LNK2001: Unresolved External Symbol

With common reference to "__DllMainCRTStartup@12"

Searching for an answer over 4 hours was the biggest waste of time. I found
answers easily enough but there was always reference to items which I know
nothing about. Researching these items and terms led to more esoteric
references. Often I would come back to the page I started with having learned
nothing. You cannot explain idea A with reference to idea B if idea B is
based soley on item A. This produces headaches.

Approach two:

What the hell amd I doing in Microsoft Visual C++ 6.0? I must be crazy.

New dynamic link library project with __asm { } function embedded in the
export function created for me. Absolutely nothing else was changed. Simple
insertion of 19 assembly commands. Looks easy enough.

Let's build the project and examine the result. There are 19 files and 1
folder measuring 2.23 meg in size. WTF?
There is a folder named 'debug' which contains my .DLL but it is 217kb in
size.
A disassembly of the library produces a 40,000 line document! (that's
excluding the CC and 00 padding at the end) WTF?
There are 4 functions listed which have names resembling my function and a
jump table.
But I cannot see my function anywhere. Nothing looks anything like what I
wrote. Where is it?

============================
In the beginning I started with Z80 chips. Eventually I wrote my own program
to hand assemble programs. You know, poke the actual 8 bit opcode into ram,
dump the memory block to a file and, bingo, one executable. Then 68000 came
along and I wrote some very nice 16 bit assembly programs ranging from a 45
byte directory lister, to a complete accountancy package.
Now on a 'pc' I can hardly understand how to move the 'hello world' text
into an output buffer. This sucks.
============================

Here are two listings. Visual Basic and assembly. How can I possibly get
them both together???

' *** Visual Basic
Private Declare Function fnLifeParse Lib "lifeParse.dll" Alias "lifeParse"
(ByVal width As Long, ByRef srcBuff As Long, ByRef destBuff As Long) As Long

Private Sub Command1_Click()
Dim dAry(10, 1) As Long, rVal As Long

rVal = process(4, dAry(0, 0), dAry(0, 1))

End Sub

; *** Assembly
    SEGMENT code USE32
    GLOBAL    DllMain
DlllMain:
    mov    eax,1
    ret    0ch

;Sub process (byVal width As Long, ByRef srcBuff As Long, ByRef destBuff As
Long)
    GLOBAL process
process:
    mov    ecx,[ebp+8]
    mov    esi,[ebp+12]
    mov    edi,[ebp+16]
lp:
    mov    eax,[esi]
    xor    eax,[esi+04]
    xor    eax,[esi+08]
    mov    ebx,eax
    push    eax
    shl    eax,1
    xor    ebx,eax
    pop    eax
    shr    eax,1
    xor    eax,ebx
    xor    eax,[esi+04]
    mov    [edi],eax
    add    esi,4
    add    edi,4
    dec    ecx
    jne    lp
    ret    0008

    ENDS

Clarification: I was attempting to be as generic as possible but forgot to
modify the function names in the Visual Basic source:

' *** Visual Basic
Private Declare Function process Lib "process.dll" Alias "process"
(ByVal width As Long, ByRef srcBuff As Long, ByRef destBuff As Long) As Long

Private Sub Command1_Click()
Dim dAry(10, 1) As Long, rVal As Long

rVal = process(4, dAry(0, 0), dAry(0, 1))

End Sub

On Sat, 24 Feb 2007 18:40:07 -0800, =?Utf-8?B?RHJhY28gTWVyZXN0?=
<DracoMer***@discussions.microsoft.com> wrote:

Show quoteHide quoteYour DLL's calling convention must be StdCall

You might be better off writing your entire DLL in pure MASM
http://www.masm32.com

If your DLL is in the same directory as the VB source then do
ChDir App.Path
DhDrv App.Path
as the first thing in the VB program while running in the IDE

Thank you for taking the time to reply to my question. But...

I know that my DLL's calling convention must be a StdCall. The continual
errors tell me so.
The main problem here is, what HELL is a StdCall?

"The calling convention options determine the order in which arguments
passed to functions are pushed onto the stack; which function, calling or
called, removes the arguments from the stack; and the name-decorating
convention that the compiler uses to identify individual functions."

So what does it look like in order for me to place it into my raw assembly?

The entire DLL code was written in plain text and the Nasm compiler was
used. Is there a difference between this and MASM? I will research this in a
minute. Hopefull it will be 100% compatible with everything else. (Written in
MASM? Does it come with an editor? That would be nice.)

My DLL is not in the same directory as the VB source becaue I do not have a
DLL yet.
But when I do have a DLL it will be placed into the same folder as the VB
executable.
The VB source will be in a projects folder somewhere else.

I am confused. app.path returns the path of the current application.
Changing to that path seems redundant.
And this should be the first thing in the VB program where?
Do you mean I should place these two commands as part of the Form_Load() sub?
Glossary says IDE is a computer cable connector and programming
environment... I guess you mean the latter.
(Yes, in all honnesty, I needed to research your definition of IDE)

Thank you for suggesting I try MASM, I hope it will help.

Apologies for my sarcasm but lack of clear meaning is why I am stuck in this
predicament.

Draco Merest.

Show quoteHide quote

On Sat, 24 Feb 2007 23:40:05 -0800, =?Utf-8?B?RHJhY28gTWVyZXN0?=
<DracoMer***@discussions.microsoft.com> wrote:

The parameters are pushed oin the stack from right to left
- but I think that the name decoration is the critical bit

Well if you download that MASM32 then you'll get a load of samples
including a sample DLL

IDE - Interactive Development Environment

When compiled, the first place VB looks for a DLL is in App.Path

When running in the IDE (like when you press [Ctl F5] )  VB
inexplicably looks first in the VB directory for a DLL
- and that directory is unlikely to be the one containing your source
or the DLL - it is insane, but that is the way it is.

Personally I generally build DLLs in Delphi although that MASM32 stuff
is very interesting - and I have played with it so I know it works.

Thank you very much.

MASM32 works exactly as it should.

The explanations were succinct. A DLL was compiled first attempt.
MASM produce a 3k DLL file which seems to contain only my assembly.

Draco Merest

On Sun, 25 Feb 2007 00:19:03 -0800, =?Utf-8?B?RHJhY28gTWVyZXN0?=
<DracoMer***@discussions.microsoft.com> wrote:

Excellent !

Now what you need to do is make absolutely sure that the parameters
you pass down are what you think you are passing down

VarPtr  gives the address of a variable
StrPtr   gives the address of the first byte of a string

Both are undocumented.

The trick is to pass variables down, modify them in the DLL and check
what comes out - obviously you can only modify things that are ByRef
with the exception of Strings where ByVal puts the StrPtr on the
stack.

If your DLL is a Function then make sure your VB declaration is typed,
otherwise it will expect a Variant and put an extra hidden parameter
on the Stack.

Good Luck

Database connection problem on VB6.0
There seems to be a bug in Vista's file sharing that causes the ADO Database open command to hang if
Localized Error Messages
Shell on Vista
MS Winsock Control ports don't free up
How to open a CMD Line exe as hidden and wat for it to finish
Have a problem that is stumping me.
Full Control to Users programmatically
Help in translating C to VB
Find Coords within X Radius