• Please review our updated Terms and Rules here

new VNC client in quickbasic.. video demo, and also question!

Sorry mike, been busy on other tasks to do much debugging, but here's where I'm at:

I moved some of the source around so the program would immediately load the .bin file and try calling it.

I compiled the program to an .exe

it ran, loaded the bin file into memory, in my case it was at 8e80:72. The data appeared to be fine, so the program is able to load in direct binary.

I then traced through the program til it crashed and I discovered that the code it tried to call in memory was no where near 8e80:72. So it looked like the setup for the call absolute isn't getting setup and it's just calling some random chunk of memory. It's really strange.

I then restarted it, and changed the call routine to 8e80:72 by hand, and it successfully jumped into our code and returned back to the basic program without a problem, so the retf 2 at the end is exactly what it should be.

Unfortunately the dstSeg of a000h didn't show up, nor did any of the other variables we tried to get set up prior to the call, so basically the entire call absolute routine was a complete failure- no parameter passing and not calling the correct segment or offset in memory.

There's certainly a possibility that I broke it when I tried to make the program as simple as possible, so if you'd be willing to write up a new program that does nothing else than load the bin and then execute it, that could be handy for me to continue with, otherwise I don't know what to say.


(BTW, if you ever want to make a program hacker-unfriendly, code it in basic. It SUCKS trying to trace through it-lots of weird interrupt calls which confuse soft-ice)

-jeff!
 
I hate to keep harping on this but there are many quickbasic sites on the web that have solved this problem (marrying assembly with quickbasic), have you checked them? It's much more simple than you're making it.

I'll ask a quickbasic friend of mine to give me a quick example.
 
yeah, i've been looking around the web a bit. not much uber-detailed info that i've found. i haven't worried about it much recently, but i need to figure it out still.

that said, it should be a non-issue soon enough!

thanksmike.jpg
 
Sorry mike, been busy on other tasks to do much debugging, but here's where I'm at:

I moved some of the source around so the program would immediately load the .bin file and try calling it.

I compiled the program to an .exe

it ran, loaded the bin file into memory, in my case it was at 8e80:72. The data appeared to be fine, so the program is able to load in direct binary.

I then traced through the program til it crashed and I discovered that the code it tried to call in memory was no where near 8e80:72. So it looked like the setup for the call absolute isn't getting setup and it's just calling some random chunk of memory. It's really strange.

I then restarted it, and changed the call routine to 8e80:72 by hand, and it successfully jumped into our code and returned back to the basic program without a problem, so the retf 2 at the end is exactly what it should be.

Unfortunately the dstSeg of a000h didn't show up, nor did any of the other variables we tried to get set up prior to the call, so basically the entire call absolute routine was a complete failure- no parameter passing and not calling the correct segment or offset in memory.

There's certainly a possibility that I broke it when I tried to make the program as simple as possible, so if you'd be willing to write up a new program that does nothing else than load the bin and then execute it, that could be handy for me to continue with, otherwise I don't know what to say.


(BTW, if you ever want to make a program hacker-unfriendly, code it in basic. It SUCKS trying to trace through it-lots of weird interrupt calls which confuse soft-ice)

-jeff!

thanks for all that testing jeff! maybe i could write a small memory scanner util that looks for exactly what it's written for the absolute call and then print me out info on it..
 
Now that is too funny ...

Get off the damn QB and start using C!


:)
 
Now that is too funny ...

Get off the damn QB and start using C!


:)

i'm reading the manual as i type this. :D

i don't think i'm going to come out with a C++ IRCd for my first program, but learning takes time... eventually i will be rocking the C hardcore.

speaking of damn QB, take a look at my e-mail client if you haven't. :p it's in the vintage software section.
 
Here is what my qbasic friend replied with in terms of how to interface asm with qb:

Check out:

http://doorknobsoft.com/tutorial/combining-asm-and-qbasic-code/

http://www.petesqbsite.com/sections/tutorials/zines/qbnews/3-asm.txt

The short of it, either running Call Absolute on a string with machine language, or linking the ASM code (.obj) into a Quick Library (.qlb) for within QB and a library (.lib) for EXE compiling, and calling it as a function/sub from QB. I've used 3rd party QLB/LIB functions made from ASM code.
 
yeah absolute is the way i'd rather do it

Code:
mov ax, [bp+6] ; get the color
mov dx, [bp+8] ; get y value
mov cx, [bp+10] ; get x value

jeff was right about where the values should be. i wonder what the problem is.
 
just to prolong your delve into C, here's a qbasic program that prints strings directly to the screen. I started with the call absolute example program and then tweaked it 'til I was able to figure out how to pass in all the goodies.

Code:
'$INCLUDE: 'qbx.bi'

'AsmBytes is a label; nASMBYTES is a symbolic constant.
CONST nASMBYTES = 36
DEFINT A-Z
DIM AsmProg(1 TO (nASMBYTES / 2))
CLS

'The machine-language program stored as data to read into the array.
AsmBytes:
'DATA &hcc              :' int 3 - use for debugging
DATA &H55              : 'PUSH BP        Save base pointer.
DATA &H8B, &HEC        : 'MOV  BP,SP     Get our own.
DATA &h06              : 'push es
DATA &h1e              : 'push ds
DATA &h8b, &h4e, &h06  : 'mov cx, [bp+6] 'length
DATA &h8b, &h5e, &h08  : 'mov bx, [bp+8] 'destSeg
DATA &h8b, &h56, &h0a  : 'mov dx, [bp+a] 'srcSeg
DATA &h8b, &h7e, &h0c  : 'mov di, [bp+c] 'destOff
DATA &h8b, &h76, &h0e  : 'mov si, [bp+e] 'srcOff
DATA &h8a, &h46, &h10  : 'mov ah, [bp+10]'color/attributes
DATA &h8e, &hda        : 'mov ds, dx  ; set destination segment
DATA &h8e, &hc3        : 'mov es, bx  ; set source segment
DATA &ha4              : 'movsb       ; copy character of string
DATA &haa              : 'stosb       ; put color/attribute
DATA &he2, &hfc        : 'Loop back   ; do it again
DATA &h1f              : 'pop ds
DATA &h07              : 'pop es
DATA &H5D              : 'POP  BP        Restore base pointer.
DATA &HCA, &H02, &H00  : 'RET  2         Pop argument off stack
			 '               and make far return.

'Get the starting offset of the array.
P = VARPTR(AsmProg(1))
'Poke the machine-language program into the array.
DEF SEG = VARSEG(AsmProg(1))   'Change the segment.
FOR i = 0 TO nASMBYTES - 1
   READ J
   POKE (P + i), J
NEXT i

' print a sample
msg$ = "This is a message to display"


srcSeg% = SSEG(msg$) ' point to the physical address of this string
srcOff% = SADD(msg$)

destSeg% = &HB800   ' point to the destination (upper left corner)
destOff% = 0

length% = LEN(msg$) ' get the size
attrib% = &H30      ' make it black on blue.

'Execute the program.
CALL Absolute(BYVAL attrib%, BYVAL srcOff%, BYVAL destOff%, BYVAL srcSeg%, BYVAL destSeg%, BYVAL length%, VARPTR(AsmProg(1)))
DEF SEG   ' Restore the segment.



END

This should (it does for me) print "This is a message to display" in black on light blue in the upper left corner of the screen. I was able to compile it, and even run the .exe file under XP's dos shell.

Hopefully this will work for too, in case you need it.

-jeff!
 
Jeff Dude ! Stop feeding these guys so that they can finally get to a real language!
 
hehe, I know, I know!

I was just feeling guilty that I hadn't fully explored why it didn't work when I knew that it was possible, and I was bored at work yesterday. I didn't want to work on anything, but did want to look busy. :)

(I get a LOT of stuff done this way)

-jeff!
 
Back
Top