Re: It's all about running old code

> Whether you have a 32-bit or 64-bit system, they should work as intended.

The crux of the discussion here seems to be that providing a mechanism, say _PEEK/_POKE, to address 32-/64- bit memory alongside PEEK/POKE is confusing at best, and at worst probably a terrible idea, particularly in a BASIC.

I agree that QB64's claim to fame is all about QB- and x86/DOS- code-compatibility, which is why I think these kinds of issues are difficult to work out while having a language that is straight-forward, safe and not confusing. I doubt Galleon wants to write a full real-mode DOS emulator to support 16-bit external libraries used by old QB apps, so I can assume that by external libraries he means to add support for linking against native 32-/64- bit object code, and nearly all C libraries that are useful (like the Windows API, for one) expose 32-/64- bit memory addresses, so naturally there needs to be a way to reference that memory.

I hope Galleon doesn't try to marry his emulated world with the OS' virtual world, I just don't think they can get along. What do you think ?

> Trying to PEEK and POKE DOS-specific memory locations could be emulated; the SCREEN 13 poke technique is a good candidate for that and there aren't many others I would consider terribly important.

DOS' conventional memory is already emulated, and text mode and graphics mode 13 screen page memory is already used for display purposes. There could be other memory-mapped locations used, but I haven't dug deeply enough.