User language(s)?

[Fifi]

Hello again,

And once again a new (and may be dumb) question:

When using the IDE (that should definitively be separated from the compiler, the first one (the editor) being able to call the compiler "à la vWATCH"), what is for the option "Language"?

http://www.as2.com/qb64/pictures/png/QB64_language_option.png

I guess it's for using different sets of characters inside the IDE, but honestly what are these options?

For me, MICSF_PC_CPxxx doesn't mean any thing!

i.e. what is the option to select to use the french accentued letters in the IDE?

Anyone to explain?

Another (not so dumb) question: is it possible for a program to automatically change the character set used by the program to displaay its messages accordingly to the language used by the system?

i.e.

The classical multi languages Hello World could be like this (please write the code of the SUB and FUNCTION below to explain):
###
Get_Language()

IF $Language = "it" # italian
  THEN
    Change_Language_Setting("it")
    PRINT "Ciao  Mondo"
ELSEIF $Language = "fr" # french
  THEN
    Change_Language_Settting("fr")
    PRINT "Hé, Bonjour le Monde"
ELSEIF $Language = "be" # russian
  THEN
    Change_Language_Settting("be")
    PRINT "Привет мир"
ELSEIF $Language = "pt" # portugese
  THEN
    Change_Language_Settting("pt")
    PRINT "Olá Mundo"
ELSEIF $Language = "??" # any other language you want
  THEN
    Change_Language_Settting("??")
    PRINT "??????????"
ELSE
    Change_Language_Setting("en") # by default when no language is known
    PRINT "Hello World"
END IF

SUB Change_Language_Setting($Language)
...
...
...
END SUB

FUNCTION Get_Language()
...
...
...
$Language = ".." # any idea how to do so?
END FUNCTION
###

Any idea how to do so?

TIA.
Fifi

[SMcNeill]

Why not just ask the user to select a language?  Seems easiest.

For Windows, shell and:  wmic os get locale, oslanguage, codeset

For Linux: echo $LANG

[Fifi]

Hi SMcNeil,

Why not just ask the user to select a language?  Seems easiest.

For Windows, shell and:  wmic os get locale, oslanguage, codeset

For Linux: echo $LANG

Just because I think what a "nice" and true "user friendly" program should do it by itself without asking anything to the user (but this is from my poor point of view in my corner as an old and retired worldwide quite reknown software publisher with over 120 million users of the last product my company provided late in the 90ies including a bundle with OS/2 Warp 4.5 and several OEM releases dealed with small players such as Compuware or ICL or other small firms such as Bank of America, Frito Lay, Yamaha, etc. etc. etc.).

QB64 is a fantastic tool.

However, even used on different countries, nothing is done to spread it because of some limitations such as how to use it on different language systems but pure and limited english, a misconception of the IDE and Compiler in the same program, and so on (and I've a lot to say about its purpoted compatibilty with QB 4,5 which was its mantra.

i.e. can you include or link assembly code and do peek and poke?

I've thousand of code lines writen in QB 4.5 from products we sold by thousands in the late 80ies (BTW compatible with both Turbo Basic and PDS 7) that will never ever be compiled with QB64!

Meanwhile, I love QB64, but please, let it stay where it is: a very nice and interesting cross-platform BASIC compiler tool but that's it. Not a real QB 4.5 contender.

BTW, do you have a response about my question with regard to  the sub menu "Language..." option of the menu "Options" of the IDE and what are supposed to do the multiple MICS_PC_CPxxx settings?

BTW, I'm a poor coder and I assume that since that never ever was my job (I was only the designer of all our products as well as the writter of the user manuals, and the President & CEO mainly in charge of the marketing and sales worldwide). So, don't blame me for my poor code samples.

However, won't you agree to this phrase: "Let's make our BASIC great again" ?

I still have a bunch of close connexions including at a top level with MSFT and they could enjoy it.

TIA
Fifi

Note: I don't use Windows but for Outlook 2007.

[FellippeHeitor]

Hello again,

And once again a new (and may be dumb) question:

When using the IDE (that should definitively be separated from the compiler, the first one (the editor) being able to call the compiler "à la vWATCH"), what is for the option "Language"?

http://www.as2.com/qb64/pictures/png/QB64_language_option.png

I guess it's for using different sets of characters inside the IDE, but honestly what are these options?

For me, MICSF_PC_CPxxx doesn't mean any thing!

i.e. what is the option to select to use the french accentued letters in the IDE?

Anyone to explain?

These numbers are Code Page numbers, and are the same since MS-DOS days, except for the extended (> 1000) numbers, which have been introduced with Windows. I clearly recall having to MODE CON CP=860 to have Brazilian Portuguese characters in my MS-DOS computer. More on code pages both on our wiki: https://qb64.org/wiki/Code_Pages and on Wikipedia: https://en.wikipedia.org/wiki/Code_page

Now, how does that work in QB64's IDE?

First: you must set a custom font. The builtin emulated VGA font you get with QB64 (_FONT 8 and _FONT 16) is limited to Code Page 437. That's the default original ASCII table (and extended ASCII characters) you see around. We even rely on it to build our nostalgic TUI (Text User Interface).

Head to Options->Display:

 [ You are not allowed to view this attachment ]  

Then toggle the Custom Font checkbox. In the textbook immediately below it, specify the font file you want to use. In my example I'm using Courier New.

 [ You are not allowed to view this attachment ]  

Notice I typed a sentence using latin characters, but they don't show up fine. What in Portuguese are characters like ã, á, é, etc, are just special symbols in the default ASCII table. How do I get these to show properly? I make QB64 use _MAPUNICODE internally to map the characters to the proper UNICODE entry points so that my custom font can display them:

 [ You are not allowed to view this attachment ]  

But the drawback is: extended ASCII characters are also used to draw the interface. So you have to decide if displaying these special characters is so important for your *editing* that you can give up a pretty looking nostalgic TUI. Go to Options->Language and choose the proper codepage for your language. For me, it's CP-1252 (the same I give support to in InForm):

 [ You are not allowed to view this attachment ]  

Now look at my sentence! Pretty in Portuguese. But look at the interface... those lines are now other Portuguese Characters too.

 [ You are not allowed to view this attachment ]  

That's basically it. You can have your own programs also display proper characters for your language provided you use a custom font and do the proper _MAPUNICODE mapping (as per the wiki) - and also provided you don't use line drawing characters, as these are also assigned to special letters with diacritics.

Another detail: I get to *type* accented letters by entering the accent (~) and the desired letter (a) real fast. That results in ã for me. Your mileage may vary.

[SMcNeill]

i.e. can you include or link assembly code and do peek and poke?

PEEK and POKE are dead and gone.  In the past, they gave direct access to memory available on a PC, which specific codes having unique effects based on the brand of PC and which BASIC it came with.  ATARII BASIC and C64 BASIC didn't always have the same memory addresses for what did what, for example.  You needed a list of memory addresses for what was what, before PEEK/POKE could be the least bit useful for you.

https://www.atariarchives.org/mapping/memorymap.php   <---  A link to the old ATARII memory map.

On the ATARII, you could PEEK(18), PEEK(19), and PEEK(20) to basically get the same information TIMER gives us...

Now, on modern OSes, those addresses aren't going to be anything like that.  In fact, most modern OSes work hard to keep the user from accessing memory outside that which is allocated specifically for their program.  Anytime you see PEEK/POKE referenced nowadays, it's emulated to "fake" the results which it used to give back in the days of DOS...

If you have a specific program which uses POKE/PEEK, and it doesn't work as it used to, chances are it can be modified to work on modern systems.  (Such as PEEK(18) can be emulated with a simple TIMER and some basic division to get HOURS.)  Some PEEK locations will NEVER work again -- like some of the old SCREEN modes where it's impossible to run again, or like the addresses for those old tape drives or card punches.

QB64 emulates many of the common addresses which programs used to use, and it can be extended to emulate even more -- as long as people agree what result a given address is supposed to do, and as long as it's a change somebody feels motivated enough to worry about making.  If one person on the forums needs PEEK(18) to get the HOUR on the forums, it's simply easier for them to modernize their code, than it is to expect one of the volunteers who are developing the language to implement changes, when it'll never be used by anybody else.  If lots of folks start sharing code with the same PEEK/POKE addresses used, somebody will probably see about adding those addresses to the ones we emulate -- but it's never been an issue yet.

[FellippeHeitor]

I still have a bunch of close connexions including at a top level with MSFT and they could enjoy it.

Please don't get us in trouble. We closely mimic their product's interface and it's not one that's in public domain. If you know someone top level with MSFT, for God's sake leave them out of the game.

[FellippeHeitor]

I've a lot to say about its purpoted compatibilty with QB 4,5 which was its mantra.

i.e. can you include or link assembly code and do peek and poke?

Just to make things clear on this matter: We strive for compatibility with QB4.5, not with DOS since we aim for Windows/Linux/macOS. For that we're practically done (with the exceptions we keep in the open in the proper help/wiki page). That rules out being able to access low level areas of the machine as explained by Steve above.

[Petr]

Let me also comment about non-English languages in IDE. I've been making some attempts to find out why it does not work in IDE. I've found that the IDE apparently uses a text screen, and that's the main reason why it do what to Fellippe show us here.

I took the MAPUNICODE, FONT, LOADFONT commands and set my locale in screen 0. The print was done correctly. But then I set the original environment and as expected the originally correctly written text was automatically converted into an illegible text. This is probably due to the nature of the text screen, which allows only 256 information per cell and 256 color information. Therefore, when you change the ASCII table, everything will be overwritten. This is exactly what the IDE is doing.

However, if I use a graphic screen, the original text that is correctly mapped is right always on the screen, the automatic change does not occur because the graphics screen keeps the information differently. So, the solution for national non-American characters in the IDE is switch to graphic mode. This of course means complete overwriting of the IDE. I suppose it means a huge amount of work that no one wants to do. Regarding backwards compatibility ... well, yeah, it's nice, but QB 4.5 never supported unicode and therefore did not have to deal with it.

[SMcNeill]

Let me also comment about non-English languages in IDE. I've been making some attempts to find out why it does not work in IDE. I've found that the IDE apparently uses a text screen, and that's the main reason why it do what to Fellippe show us here.

I took the MAPUNICODE, FONT, LOADFONT commands and set my locale in screen 0. The print was done correctly. But then I set the original environment and as expected the originally correctly written text was automatically converted into an illegible text. This is probably due to the nature of the text screen, which allows only 256 information per cell and 256 color information. Therefore, when you change the ASCII table, everything will be overwritten. This is exactly what the IDE is doing.

However, if I use a graphic screen, the original text that is correctly mapped is right always on the screen, the automatic change does not occur because the graphics screen keeps the information differently. So, the solution for national non-American characters in the IDE is switch to graphic mode. This of course means complete overwriting of the IDE. I suppose it means a huge amount of work that no one wants to do. Regarding backwards compatibility ... well, yeah, it's nice, but QB 4.5 never supported unicode and therefore did not have to deal with it.

I actually rewrote the whole IDE once before, a few years back, to run in graphics mode -- it doesn't work.  QB64 IDE relies on several of those almost never used commands (VIEW, WINDOW, ect), while also using multiple screens (4 or 5 pages at least), and then swaps them all into view in a cacophony of confusion. 

SCREEN , , 3, 4 and SCREEN , , 0, 3 and other odd syntax makes changing the source hard to follow, but IF you go through the trouble of making it all work....   It'll then run so slowly as to be completely unresponsive.  :(

I ended up changing QB64 IDE to run in 256 color mode, thinking it'd be 1/4th the resource hog as 32-bit color modes, and it didn't matter one bit.  The IDE, as it currently exists under the hood, with syntax checking and page refreshing with EVERY user keystroke, simply bogs down and becomes unresponsive with longer programs.  It was to the point where editing QB64.BAS would require several seconds to process every keypress -- which made it 100% unusable.

***************************

Now, one caveat here:  Since my last time trying to change the QB64 IDE to graphic mode, I made and pushed a TON of improvements to how it performs.  Changing all the LINE INPUT file statements from OPEN... INPUT to OPEN... BINARY really helped out a lot with IDE response times, and other small modifications improved things even more since then.  Whether changing to graphical mode would be possible now, or not, I'm uncertain about...   We've had some nice performance optimizations done, but I also remember how large a performance hit the older version took by swapping to graphics mode...

With the uncertainty of the outcome (in my mind, at least), and the certain knowledge of knowing just how damn irritating it was to try and change all the proper places and color statements so graphic mode works, *I* personally won't be bothering to try and swap us back over from a text IDE to a graphical one, anytime soon.  Heck, before I bothered to try that experiment again, I'd go the route of just making a whole new IDE from scratch, for my use...

[Fifi]

Hi all,

Thank you for all the clear explanations.

This drives me definitly to say that the IDE and the Compiler should be two different files, the IDE (whatever it is) being able to call the Compiler "à la mode de vWATCH".

@Fellippe: QB 4.5 is an "abandonware" that you can download for free from a bunch of web sites, and as far as I know its user interface never ever was registered (or Phlippe Kahn, Bob Zale and Borland would have had a lot of problems with the MSFT lawyers late in the 80ies, and that was not the case - been there, done that). So why do you think MSFT nice old folks wouldn't like to promote a new open source cross platform "BASIC" tool and even help with its development, then stay out of the game? Please explain clairly what are your fears.

@Fellippe & @SMcNeil: Sorry but QB 4.5 was a genuine DOS develoment tool, not a Windows one when its Windows "counterpart" was later VB. Since the QB64 mantra is to be compatible with QB 4.5, then it should support all the QB 4.5 functions including the MASM includes and PEEK/POKE functions.

@SMcNeil: Please let me know if you want a complete product sample sources (TurboDB written with QB 4.5) to see how QB64 emulates calls to its external btrieve library.

BTW, I truly like QB64.

Cheers.
Fifi

[FellippeHeitor]

I don't believe Microsoft has declared QB 4.5 to have entered public domain. I could be wrong. That said, we do infringe on their design. I could be wrong.

PEEK/POKE: all that Steve said, clear enough.

This drives me definitly to say that the IDE and the Compiler should be two different files, the IDE (whatever it is) being able to call the Compiler "à la mode de vWATCH".

The compiler can be used in the command line and the IDE will never be launched. Here are the command-line switches:

C:\qb64>qb64 -h
QB64 COMPILER V1.2

USAGE: qb64 [switches] <inputs>

OPTIONS:
  <file>                  Source file to load
  -c                      Compile instead of edit
  -x                      Compile instead of edit and output the result to the
                             console
  -p                      Purge all pre-compiled content first
  -z                      Generate C code without compiling to executable
  -o <file>               Write output executable to <file>
  -e                      Enables OPTION _EXPLICIT, making variable declaration
                             mandatory (per-compilation; doesn't affect the
                             source file or global settings)
  -s[:switch=true/false]  View/edit compiler settings
  -l:<line number>        Starts the IDE at the specified line number

I still haven't read an argument strong enough to justify having two executables, one for the IDE, one for the compiler, instead of one.

That said, though, you can open qb64.bas in QB64, remove just *two* lines, and hit F11. You'll end up with qb64(2).exe that is the compiler alone. The IDE has been modularized a while back and is just that simple to remove.

The lines to look for are:

'$INCLUDE:'ide\ide_global.bas'

and

'$INCLUDE:'ide\ide_methods.bas'

[Fifi]

Hi Fellippe,

Thanx again for your post.

I don't believe Microsoft has declared QB 4.5 to have entered public domain. I could be wrong. That said, we do infringe on their design. I could be wrong.

I never ever said that QB 4.5 has entered in the public domain. However, the similar (even not identical) "look and feel" (of the QB64 editor Vs. QB 4.5) was fixed long time ago by several courts as non infrigement since the late 80ies (e.g. Borland Vs. Lotus or MSFT Vs. Apple).

So,  I don't see any chance for MSFT starting a trial for look and feel infrigement since QB64 isn't QB 4.5. And I won't bet a dime on it!

The compiler can be used in the command line and the IDE will never be launched.

I know that now for a long time since I've requested so many times the -x argument that tooks over 3 years to work (LoL).

I still haven't read an argument strong enough to justify having two executables, one for the IDE, one for the compiler, instead of one.

Just because for any project having two so different purposes (i.e. the editor and the compiler), it's always the smart way to have two different and separated sets of source files.

Doing so also avoids a bunch of conflicts.

This just makes sens like the K.I.S.S. abbreviation (been there, done that for a while with my own and nice development team).

Further, this motivates others (external to the project) to propose different versions of the editor (whatever they could be GUI or text based) and to bundle their own derivative solutions wihout being obliged to carry the complete QB64 "stuff".

BTW, didn't QB 4.5 integrated a debugger (along with the editor, the compiler and the linker) ?

So, why don't you integrate vWATCH64 directly into QB64 since it's completely tied to it?

Would this makes sens for you? I guess not!

That's exactly my view point about why separing the editor from the compiler is a good and smart choice and I think that using the sample of vWATCH64 is very a strong argument.

Just my two cents.

Cheers my friend.
Fifi

[SMcNeill]

I know that now for a long time since I've requested so many times the -x argument that tooks over 3 years to work (LoL).

The -x and -c switch have always worked.  What you were so demanding over was the -z switch so the code would simply generate c output alone.

[FellippeHeitor]

I think what Fifi kept requesting was -o to be able to specify the output path, wasn't it?

[Fifi]

Hi Fellippe,

I think what Fifi kept requesting was -o to be able to specify the output path, wasn't it?

Yep! I didn't specify -x -o since, for "me", the -o is nothing but a standard argument of the -x on any de facto standard compiler such as gcc, isnt it?

Just too bad we had to wait for over 3 years to have it working as expected since we lost a nice opportunity to get QB64 supported by the web server G-WAN like the 15 other programming langues it does.

I'm still hoping this to be done one of these day since, when installed with my multi tongue script, QB64 can be invoked from anywhere on Linux systems (i.e. you don't have to go in the QB64 folder anymore. Just open a terminal session and simply type: "qb64").

Idem to call from any terminal session both UiEditor with the command "inform" and vWATCH64 with the command "vwatch").

And again, why G-WAN? Just because it's the unique web server that would be able to create complete web applications (or even web sites) using QB64 and not the boring Java or the crippled PHP.

When I see this, I still dream of QB64 being in the list:

http://www.as2.com/pictures/png/gwan-languages.png

Anyone wanting to help me to convince the G-WAN folks to support of QB64 by their web server (they said this would require  less than one hour of work for QB64 to be called by G-WAN)? Please send me an e-mail to give you the complete context.

Cheers.
Fifi