• Please review our updated Terms and Rules here

the horrors of quickbasic... need help with simple C routine

M

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
(please excuse this, it's a bit long but i had to explain exactly whats wrong)

ok, so development on leetIRC has been pretty much exponential in the last week or so. the entire client is now more or less finished. i've even got DCC file transfers working, with one (major) caveat.

my problem is that good ol' quickbasic's largest numerical data type is a 32-bit long integer. BUT, it doesnt go up to 4.2 billion since it allows for negative values... this means the range is -2.1 bil to +2.1 bil.

now, in the IRC DCC send spec the sender gives the recipient the info to connect to (IP and port of sender) in this format: DCC SEND <ip to connect to> <port>

but instead of it sending the IP as a xxx.xxx.xxx.xxx string, it sends it as a single, non-period-delimited, numerical string based on using each of the four IP xxx value sections as a binary byte and converting those 4 bytes into an unsigned 32-bit integer. i'm not explaining this well, so here's an example:

i know this is an invalid IP, but say your IP was 0.0.1.0
that would make the numerical string "256" - does that make sense?

here's a real world example. my IP is 68.184.216.98 (plz dont haxx0r me thanks)
in the DCC SEND format, it gets sent as this numerical string: "1152964706"

so what i have my program do is turn that numerical string back into a 4-byte binary value, and then single out each byte and reconstructing the xxx.xxx.xxx.xxx format that way. for an IP like mine starting with 68 that works just fine in QB. the problem is if the IP is greater than 128.0.0.0 then QB simply can't put a number over 2.1 billion into it's native long integer type format.

SOO, the simplest solution i can think of is to make a small little "helper" executable in another language like C. it would have to let me feed it the huge numerical string in the command line or through a file, and then it would simply subtract 2,147,483,648 and drop the new value into a file or somewhere in memory for quickbasic to read and then go from there with the newly valid long integer.

is there anybody who would be able to offer me some assistance with this? did i even explain my problem well enough? lol. i would really appreciate any help at all!

i have made a resolution that when i'm completely through writing this IRC client, i am DITCHING QUICKBASIC and i'm gonna learn a decent language like C++ or C#!!!! i'm sick of little project-killers like this, not to mention the horrible speed of QB apps. QB doesn't even allow you to make a byte array. the closest thing you can do it dimension a string and chop it apart constantly to emulate a byte array. (or use PEEKs to read each value as if it were an array, but surprisingly enough that's not really any faster)
 
Last edited:
I'm no programmer, so I can't help with your current problem, but I can still offer ya that Turbo C++ for Dos, for shipping cost (~10 lbs, from MI, 48449), if ya want it (no, not $4000.00 either). Pm me...

--T
 
Last edited:
The King of QB, giving up? & after all the "you can do pretty much anything in QB" talk?

I have only 1 thing to say: If you port leetIRC to C or C++ it will be a sure hit! (even more sure than it already is a hit)
 
QB has no ability to do anything other than 32 bit math?

I'd do it using the text strings. Seriously. You can do the 2nd, 3rd, and 4th bytes using an integer and come up with a value. Add that value to the first byte * (256*256*256) one digit at a time simulating the way a human does it.

For example, 68.184.216.98:

184*(256*256) + 216*(256) + 98 = 12114018

That part can always be done using regular integer math because it always fits.

68*(256*256*256) = 1140850688

This number might not fit because it is too big.

So create an ASCII string with both numbers - 12114018 and 1140850688. Start from the right side of the numbers, and add just like you would on pencil and paper. Except instead of using a + operator, you are generating another ASCII digit.
 
Are you using q basic (comes with DOS), Quickbasic 4.5, or MS Professional basic 7.1 (Quickbasic with a few other things added)?
 
Unknown_K said:
Are you using q basic (comes with DOS), Quickbasic 4.5, or MS Professional basic 7.1 (Quickbasic with a few other things added)?
Click to expand...

i am using QuickBASIC 4.5 - QBasic wouldn't work since my TCP routines involve interrupt calls to the trumpet tcpdrv tsr. (which means i have to use the QB.QLB quicklibrary file)
 
mbbrutman said:
QB has no ability to do anything other than 32 bit math?

I'd do it using the text strings. Seriously. You can do the 2nd, 3rd, and 4th bytes using an integer and come up with a value. Add that value to the first byte * (256*256*256) one digit at a time simulating the way a human does it.

For example, 68.184.216.98:

184*(256*256) + 216*(256) + 98 = 12114018

That part can always be done using regular integer math because it always fits.

68*(256*256*256) = 1140850688

This number might not fit because it is too big.

So create an ASCII string with both numbers - 12114018 and 1140850688. Start from the right side of the numbers, and add just like you would on pencil and paper. Except instead of using a + operator, you are generating another ASCII digit.
Click to expand...

yup, i do know about the (256*256*256) etc stuff. i've had to use methods like that before. i didnt think about the ASCII string method though! good idea, i'm going to give that a shot.

btw mike, if you'd like to try the program so far i can ZIP up what i currently have and e-mail it to you. i don't know if you downloaded what i posted in that other thread i made a week ago or so, but that version was just done enough to function mostly correctly.

as it is now, it's complete other than that little(big) DCC issue. full drop down menus are there and everything.

it does work ok on my 8088 when i set it for 4.77 MHz, btw. sluggish screen updates, but definately useable. right now i'm using it on my 286 12Mhz and it's nice and fast. (you can still see the screen update, but it goes fast enough that it doesn't matter and it's not a nuisance. it takes about 1/5 or 1/6 of a second.)


atari2600a said:
The King of QB, giving up? & after all the "you can do pretty much anything in QB" talk?

I have only 1 thing to say: If you port leetIRC to C or C++ it will be a sure hit! (even more sure than it already is a hit)
Click to expand...

heh... well you CAN do pretty much anything. there'll always be a method to do what you want (however slow it may be) as mbbrutman just reminded us :)

once i start learning C i think i will remake the client with it once i know enough of the language. i feel i have enough of a grasp on coding techniques from all my quickbasic/visual basic experience to just pick up the syntax and get to work after some practice with simpler stuff.

also atari2600a, i remember we were talking about leetirc on the #vc irc channel and you were wondering about using it under windows. there is a virtual packet driver for win NT/2K/XP that lets you run native DOS network apps in the windows command prompt. if you're still interested in trying it, the offer i gave to mike b about trying what i have done goes to you too.

edit: i forgot to tell you the name of that virtual packet driver. it's called swsvpkt. just put that into google and it's the first page that comes up.
 
Last edited:
Mike Chambers said:
i am using QuickBASIC 4.5 - QBasic wouldn't work since my TCP routines involve interrupt calls to the trumpet tcpdrv tsr. (which means i have to use the QB.QLB quicklibrary file)
Click to expand...
I have Pro basic 7.1 and was wondering if it had the same problem.

Programming for DOS/WIn 3.1 was something I wanted to get into so I have been buying some old boxed apps. So far I have the MS Pro 7.1 basic, and VB 3 Pro. Next on the list would be Borland C++ 3.1, after that I start programming (if and when I can find one cheap).

One of my first projects is going to be programming a DSP chip on an ISA card I should be getting soon.
 
mbbrutman said:
QB has no ability to do anything other than 32 bit math?
Click to expand...

here's a copy and paste of the data types section of QB's internal help system.

Code: 
Data Type                 Declaration      Maximum          Minimum
◄Strings►                       $           32,767 chars.    0 chars.
◄Integers►                      %           32,767          -32,768
◄Long Integers►                 &           2,147,483,647   -2,147,483,648
◄Single (7-digit) precision►    !          ±3.402823 E+38    ±1.401298 E-45
◄Double (15-digit) precision►   #          ±1.7976931 D+308  ±4.940656 D-324
◄User-Defined Data Types►

yup... QB is pretty weak :mad:
 
Last edited:
Can you not use floats with single or double precision? :) ASCII math as suggested by Mike is cool too, it will let you work with much larger "numbers" than you otherwise would be able to.

Remember that when you switch to C or C++, use unsigned data types, or otherwise you will get stuck in the same problem.
 
Hmm, of course the one I just paid 15.52 for plus s/h (c++ for DOS) has already arrived here! Oh well, still should be fun to play with.
 
'ASCII math' isn't that far different from Binary Coded Decimal. There are many situations where the numbers being represented are larger than the data types available, or greater precision is necessary.

Talk to a COBOL guy about banking applications and they'll shake their head vigorously in the horizontal plane if you mention floating point or binary data types.

My 'ASCII' math idea will get you close enough. It doesn't have to be fast, you are just doing one calculation.
 
hahaha i can't believe this, i just got it working... WITHOUT using ascii strings.
apparently i can use these large numbers with double precision data type. this code got it working:

Code: 
first = FIX(VAL(LEFT$(DCCreq$, xp - 1)) / 16777215#)
DCCip$ = MKL$(VAL(LEFT$(DCCreq$, xp - 1)) - 2147483648#)
tmpip$ = CHR$(first) + MID$(DCCip$, 3, 1) + MID$(DCCip$, 2, 1) + LEFT$(DCCip$, 1)
DCCip$ = Conv2IP(CVL(tmpip$))

i've been testing this thoroughly this morning and have not had an error or wrong number yet! :cool:
(to be clear, in the code, the DCCreq$ string simply contains the number string received from the sender)
 
Last edited:
mbbrutman said:
If you use double precision, make sure a decimal point and fraction doesn't leak in. Double precision is imprecise ...

http://en.wikipedia.org/wiki/IEEE_floating-point_standard
Click to expand...

when doing the division in the line where it comes up with the variable called first it does leak in a decimal point + fraction, but the FIX function removes it. i've tested all sorts of IP values with it so far spanning pretty much the whole valid range, and there hasn't been any problem. :)
 
Chuck "the COBOL guy", shaking his head in a horizontal direction --- When I was doing Payroll Apps in FORTRAN I had to use double precision INTEGERS for everything. Fortunately, I never needed totals over the 21,474,836.47 positive integer maximum. I also had a whole bunch of purchased "double integer" subroutines to use so I didn't have to write them all myself. Business apps in FORTRAN is a super PAIN, let me tell you.
 
Last edited:
Was there an obvious reason why you had to use that language? Did it have to interface with some more scientific modules of the computer system, or due to some one programming language policy?
 
Yes, IBM hadn't managed to make a COBOL compiler available when the thing was started. Your only choice was FORTRAN. Later, I converted the whole thing into COBOL.
 
carlsson said:
Was there an obvious reason why you had to use that language? Did it have to interface with some more scientific modules of the computer system, or due to some one programming language policy?
Click to expand...

because i don't know any other languages well enough to make a program like this. i do have lots of visual basic experience, but i wanted to make this client for DOS so i can use it on my really old machines. i used to know some C but i didnt stay in practice and have forgotten it all by now.

QB is bad/slow/limited, i know. when i complete this program, i'm going to start learning C.
 
You must log in or register to reply here.
Back
Top