FreeBasic compatibility issue

[Z!re]

Whining, not. Making a statement, yes.

I don't see the difference here. If you want to grab the source, feel free and implement those QB commands you're wanting, because - and I'm guessing - you're the only one who wants them.

Quoted for emphasis

[na_th_an]

Whining, not. Making a statement, yes.

I don't see the difference here. If you want to grab the source, feel free and implement those QB commands you're wanting, because - and I'm guessing - you're the only one who wants them.

Quoted for emphasis

Yeah

[Sterling Christensen]

@styler: Call me lazy, but here is how compatible I think it should be: open a QB source and run it in FB, regardless of the commands.

In QB a variable has a 16 bit address (VARPTR) and a 16 bit segment (VARSEG). In FB a variable has a 32 bit address and no segment.
So how do you propose we make QB programs that use VARSEG work in FB?

In QB you could use INTERRUPTX to call DOS interrupts. Windows and Linux programs can't do that.
I suppose FB should emulate DOS to make this work?

QB programs use CALL ABSOLUTE to call 16 bit real mode assembler... which won't work in 32 bit mode.

[DrV]

Whining, not. Making a statement, yes.

I don't see the difference here. If you want to grab the source, feel free and implement those QB commands you're wanting, because - and I'm guessing - you're the only one who wants them.

Quoted for emphasis

Yeah

I have to agree, too.

If you can point out any particular feature of QB that is not implemented in FB *and* which has a modern-day counterpart, we can certainly look at implementing it. However, in my opinion, FreeBASIC has already implemented every useful feature of QB and gone on to add quite a few more. I personally don't want a "QB emulator" or full QB compatability - if you want this, you must either use QB itself, or write your own QB clone that, as you would see if you tried, would end up being tied to 16-bit DOS. What would you gain by this?

[anarky]

Perhaps I was mistaken. I was under the impression that FB was to be 100% compatible. So VARSEG, CALL ABSOLUTE and INTERRUPTX can't be used in a 32 bit environment. I suppose this can't be implimented.

The fact I wrote this post at some ungodly hour of the morning when I should have been asleep for agt least 3 hours doesn't help matters. Maybe I went overboard trying to get some answers.

Oh well.

>anarky - 2 Bit.

[KiZ]

I was under the impression that FB was to be 100% compatible. So VARSEG, CALL ABSOLUTE and INTERRUPTX can't be used in a 32 bit environment. I suppose this can't be implimented.

Nope, noone ever said it was 100% compatible. Its just not sensible to support the old 16bit commands. There is a little thing called obsoletion. Despite this, FB is actually amazingly compatible, considering the switch to 32 bit.

The point is, you can do everything you could do in QB still, and do it better, and you dont need to use out of date techniques!

[anarky]

So for those games which use the obselete commands, what needs to be done to port a program to FreeBasic?

>anarky

[KiZ]

So for those games which use the obselete commands, what needs to be done to port a program to FreeBasic?

>anarky

Well it depends what they are doing. Sometimes it is simply modifying the syntax slightly, other times it is rethinking the concept with new commands available.

For instance, instead of using all that crazy ASM to handle the mouse, you just need to use getmouse in FB

Here is a small reference list:

CALL ABSOLUTE Stmt (reason: use inline ASM instead, much easier)
COM Statement (reason: user mode apps can't access IO ports directly)
CALL INTERRUPT Stmt (reason: services are not the same; not needed with shared libs)
CVDMBF Function (reason: old and useless proprietary format)
CVSMBF Function (reason: old and useless proprietary format)
CALLS Statement (reason: same as CALL)

DEF FN Statement (reason: use real functions instead, or macros)
DEF SEG Statement (reason: segments are not needed in 32-bit flat mode)

ERDEV Function (reason: )
ERDEV$ Function

FILEATTR Function (reason: depends on internal tables)
FILES Statement (reason: use dir$ instead)
FIELD Statement (reason: most hacked stmt ever, use records instead)

IOCTL Statement (reason: devices aren't accessed so simply by 32-bit apps)
IOCTL$ Function (reason: ditto)

KEY(n) Statement (reason: no "faked" events)
KEY Statement (reason: ditto)

LIST
LPOS Function (reason: no direct printing, use proper API's instead)
LPRINT Statements (reason: ditto)

MKSMBF$ Function (reason: old and useless proprietary format)
MKDMBF$ Function (reason: ditto)

ON UEVENT Statement (reason: no "faked" events)
OFF (reason: ditto)
ON (but GOSUB/GOTO) (reason: ditto)
ON COM(n) Statement (reason: ditto)
OPEN COM Statement (reason: user mode apps can't access IO ports directly)
ON event Statements (reason: no "faked" events)
ON KEY(n) Statement (reason: ditto)
ON PEN Statement (reason: ditto)
ON PLAY(n) Statement (reason: ditto)
ON STRIG(n) Statement (reason: no "faked" events)
ON TIMER(n) Statement (reason: ditto)

PEN Function (reason: can't access devices directly)
PEN Statement (reason: ditto)
PLAY(n) Function (reason: use real sound libraries instead)
PLAY (Music) Stmt (reason: ditto)
PLAY (Event Trapping) (reason: no "faked" events)

STICK Function (reason: can't access devices directly)
SETMEM Function (reason: un-needed, there are plenty of free mem to use)
STRIG Function (reason: can't access devices directly)
STRIG Statements (reason: ditto)
SIGNAL (reason: seldom if ever used)
SOUND Statement (reason: use real sound libraries instead)
SEG (reason: segments are not needed in 32-bit flat mode)

TIMER Statement (reason: no "faked" events)
TROFF Statement (reason: use a real debugger)
TRON Statement (reason: ditto)

UEVENT Statement (reason: no "faked" events)

VARSEG Function (reason: segments are not needed in 32-bit flat mode)
VARPTR$ Function (reason: no PLAY, not needed)

[ShadowWolf]

KIZ your slightly wrong on one thing there

OPEN COM Statement (reason: user mode apps can't access IO ports directly)


OPEN COM works under .15 thanks to MJS

also IN and OUT work as well thanks to lillo. but you must have admin status on the system your on so lillo system drive can be installed and loaded.

[marinedalek]

Also, IIRC LPRINT works correctly now also.