PureBasic Forums - English

(1) A built-in graphics Text-based replacement for Console. No more dependency on the APIs for the ability to do the following, some of which can't be done now:

(1) Based on a cross-platform graphics package like OpenGL, GTK+, or as noted at http://www.binpress.com/blog/2014/05/14 ... me-engine/
"If you love open-source and want to deploy to many platforms, go for Cocos2D JS"

From http://www.cocos2d-x.org/.
"Cocos2d-X is a suite of open-source, cross-platform, game-development tools used by thousands of developers all over the world"

I'm not harping on one graphic engine here, but open source, cross-platform are important, and 2D rather than 3D simplifies things a bit. But whatever graphics engine is used, it is necessary to write a DLL for PureBasic to replace the functionality of the Console, which is rather restrictive in terms of its features. As a default, the new Console replacement should emulate existing Console settings closely.

(2) Allow for a broader range of colors for characters and background. Also support images or transparent background.

(3) Include the ability to pass Text for display to the new Console in Strings of printable characters. Perhaps allow numbers to be passed as well, as this is common with many Print statements.

(4) Printing is to begin at the current row.column setting, which is determined by font style and size. My preference is for nono-spaced type forms, as this is best for columnising what appears on the screen, but some may opt for something different.

(5) Take keyboard input and render it on the screen at the current row,column location. Have the option to replace displayed characters with "*" to hide passwords.

(6) Allow two different xy designations for the console: The first designation is the number of columns by the number of rows that will be used for the screen memory to hold unicode values. The second set is the number of pixels that the Console window will use, width-by-height. If the console viewport is too small, scroll bars will be added on the right side and/or bottom to move the viewport over the screen memory's contents. If the viewport is too large, the apparent size of the viewed characters can be increased accordingly.

(7) Add the ability to designate a specific font and size for use with the Console window. I debated whether to allow a mix of font types and/or sizes, but the Console is not intended to be a showcase. It really serves as a utility for program development. So this should be kept in mind, at least during preliminary development.

I also considered some of the possible alternatives to using a graphics engine. These have merit, but may involve other side issues. Like scripting HTML or RTF on the fly and showing those results in what appears to be a Console window. I'm flexible in this matter. I have found that the Windows version of 5,31 installs, loads, and runs properly in a linux wine environment, but that nothing Console-related appears on the screen, though no error is given. A further limitation of Wine, but I thought it worth mentioning.

What you are requesting has little to do with a console app.
A console app should be working in the same way as other console apps on the same OS.
It should not be replaced by something else which does not output to the standard console.

I'm not sure I understand what role graphics needs to play in a console. A console is a very utilitarian tool and when I'm coding for it I rarely if ever even use EnableGraphicalConsole(). People used to make games on the console back in the day before there were better technologies available for the purpose but in 2015 we're well past that.

A console reads and executes commands and their parameters from STDIN, writes results to STDOUT and STDERR and it's hard to see why you need more than a text interface for that. But assuming you can see further than I, if you want to create a souped-up graphics-enabled console you need look no further than the canvas gadget. It supports quick and clean 2D rendering and handles every event you could possibly want. There's almost nothing you can't make out of a canvas.

I agree with wilbert and netmaestro.

I was making the argument for a cross-platform version of Console, rather than specifically going for a graphical version. But you want to go cross-platform, you need to build on something that is already in place, and an accepted graphics package is as good a place to start as any. I also thought about going with a standard mark-up language like HTML or RTF. Later, I asked myself, why not just incorporate elements of the PureBasic editor? That would work as well.

The thing is, the present Console statements just don't work everywhere. Maybe they do if you only take into account what you normally see, but I will put a case before you where that is the outcome.

Somebody writes a PureBasic program and makes use of Console. They post the executable online. Somebody wlse downloads it. Because the executable is an EXE file, and the downloader is using some version of Linux instead, they attempt to run it with Wine. It runs, vut there is no Console output. Why? Because the Wine version of XP's kernel32 does not support the Console,
Can this be dealt with? Hard to say. I've done some research on adding "native" DLLs to Wine, and it's a try and tweak process. Seems a lot to go through with little gain. It's mostly done to get Windows games to play well under Linux.

What is see here is a problem best solved at it's source. But the program originator is not going to install Linux on his PC and add the Linux version of PureBasic to it just to recompile this one program for this one person. But that is what he has to do to get a Linux executable, right? Either that or give the source code away.

The weakness is not being able to steer around certain OS dependencies, yet that is what the PB compiler is able to do for itself via extensive planning and programming effort. But Console functions in produced statements will lock you into a platform dependency because it requires Windows kernel32 if it appears in a produced EXE file.

The exceptional programming in PureBasic shows that by looking at how to do it and having solved that problem, maybe all that is needed is to show that migrating Console off the kernel32 requirement would benefit some users over time. You want something to shoot for? That would maybe be a help.

Each platform-specific version of PureBasic is intended to produce an executav;e for that one platform. But from decades back, Commander Grace Hooper and her crew made and used Cross-Assemblers and Cross-Compilers to deal with the hodge-podge network of borrowed time on a variety of machines all over the Washington DC area.

The idea that an assembler or compiler could produce executables targeted at other machines may have originated with her efforts. I don't know, and history is too fragmented to learn for sure. They also had to deal with a mixure of programming languages, hardware, and operating systems. It was so bad that the then Secretary of the Navy ordered CDR Hooper to have the industry standardize the COBOL language. She did, and that was one standard that remained under Navy control when all others were transferred to the National Institute of Standards and Technology.

BureBasic has done a lot to move us away from OS dependency by making a compiler that works well with consistent source code. I't can't produce a compiler that gives us one kind of executable file that runs under all OSes, because each has its own requirements, and these conflict with each other. But history shows that it is possible to create a compiler that can produce executables for a variety of platforms, so that I could have a Windows PB Compiler that can produce my choice of a Windows (default), MacOS, or Linux executables.

I'm not pushing the matter that far. But towards that eventual end, assuming you see merit in it (I'm sure not many will agree with me), you would need to find a way to standardize everything created by the compile process for it's eventual output.

But just think of the net gain. No more writing separate compilers for each OS, the AmigaOS crowd could have the latest and greatest, you could look at targeting more platforms and OSes, and users would have more potential customers for what they produce.

My real goal, like I said, was to point out that Console dependency on the Kernel32 routines can be eliminated. Ever since Vista, Microsoft has been moving Windows away from the frozen APIs in Win32 and towards WinRT. I don't know WinRT, and I really doubt I will devote time to it. But it's going to be a wedge against writing programs that work under XP and earlier versions of Windows, separating any future development for Win8 and on beyond. It's MS's intent to resell into a saturated market, and they do this by making existing software obsolete by comparison.

oldefoxx wrote:the program originator is not going to install Linux on his PC and add the Linux version of PureBasic to it just to recompile this one program for this one person

The way I see it, for a console application that is the only right way to do it. You can't blame PureBasic for something Wine doesn't support.
Linux and VirtualBox are both free to get and if you have a PB license you can use the Linux version of PureBasic as well.
If you really want to support Linux, you need to create a Linux application, not rely on something as Wine.

It would be really strange if I would create a console application for OSX with PureBasic, open the console, run it and it would start some graphical application that kind of simulates the console.
That wouldn't be a console application anymore and probably get a lof of negative feedback from users.

If you want to create a graphical application that looks like a DOS program, you could probably use the Screen library or CanvasGadget and create a module with procedures like Locate, Cls, Print, Input etc.

As for cross compiling, maybe LLVM could help.
Fred mentioned somewhere he was lookig into LLVM.

I think Wilbert is right on the money with his comments. The console is a text device and should remain so.

The approach that Purebasic takes with support for different platforms is the best one.
When I'm developing for one platform, I don't want to be bothered with all the cross-platform cruft.
What would be the advantage of putting all the separate platform / OS stuff into a single compiler?

How could the Purebasic team (great though they are) expect to support such a behemoth?
Let's stay real.

Forget the graphics approach. It was just an initial thought on the matter, and I was drawing on a limited store of general knowledge about efforts to get graphic libraries/engines to work on multiple platforms.

Doing a bit more searching, this time going for Terminal Emulation, I hit a new vein. I found a thread where several people responded with the same answer: ncurses.
I looked it up, and ncurses is available for Linux, the Mac, and there is a port called pdcurses for windows. Sounds promising.

I also found a C example of using ncurses. I am supplying the URL: http://tldp.org/HOWTO/NCURSES-Programmi ... ndows.html

It's been decades since I've had anything to do with C, and I am not really motivated to get into it again. But someone else might give it a shot. Fact is, I'm back to say I tried to compile the example given using gcc -o c_ncurses_1 c_ncurses_1,c, and got errors. Nothing could be resolved. I need to look at the example more closely. I might need some advice as well.

There is a new release of ncurses out. You can read about it here: http://www.gnu.org/software/ncurses/

Instructions on writing programs using ncurses: http://invisible-island.net/ncurses/ncurses-intro.html

A beginner's tutorial: http://edlinuxeditor.blogspot.com/p/ncu ... orial.html

Getting ncurses for Windows (up to and including XP): http://gnuwin32.sourceforge.net/packages/ncurses.htm

Another example program (short one): https://hackage.haskell.org/package/ncurses
Tried to compile this one next. Code looks odd, in that the code keeps indenting and does not come back as it shouls. Anf the IMPORT statement is rejected. I'm sure a C programmer can make some sense of it.

Description of ncurses functions: http://php.net/manual/en/book.ncurses.php

There are a series of ncurses tutorials on YouTube, starting at: https://www.youtube.com/watch?v=2tWN6ntNo4w

I can't view them myself. I may try with a different browser later. oops! There it goes. I'll watch it later.

There is at least one book on programming using ncurses. Here is a related web page: http://www.c-for-dummies.com/ncurses/

There is even some discussion of game programming using ncurses. I noted in passing that the new ncurses goes beyond 16 colors, which would be a nice change from the Console approach.

That's about it for now. Time for the real C and PureBasic programmers to step in.

I found an example program of ncurses in use on a different site. This one provided the compiler instructions as well, so I got this one right. I did not know to include a linker argument, though now that it is brought to my attention, I suppose I should have known it. Here is the compiler instruction first:
But before I could use it, I had to copy and paste the following code from the web site into a file named curhello.c using gedit, and save that file in my home directory (not /home, but /home/username/, which shows up as Home Folder in the GUI).

From the command line. the the initial current directory looks like computername:~, and you can reference it using either "~/" or "./". The difference is, that ~ always points to your home folder, while . is just a reference to the current directory, which the cd command can change when it suits you. You want to get back to your home folder? Just do cd ~ and you are there. But now here is the curhello.c example code:
[code
/*

CURHELLO.C
==========
(c) Copyright Paul Griffiths 1999
Email: mail@paulgriffiths.net

"Hello, world!", ncurses style.

*/


#include <stdlib.h>
#include <stdio.h>
#include <unistd.h> /* for sleep() */
#include <curses.h>


int main(void) {

WINDOW * mainwin;


/* Initialize ncurses */

if ( (mainwin = initscr()) == NULL ) {
fprintf(stderr, "Error initialising ncurses.\n");
exit(EXIT_FAILURE);
}


/* Display "Hello, world!" in the centre of the
screen, call refresh() to show our changes, and
sleep() for a few seconds to get the full screen effect */

mvaddstr(13, 33, "Hello, world!");
refresh();
sleep(3);


/* Clean up after ourselves */

delwin(mainwin);
endwin();
refresh();

return EXIT_SUCCESS;
}[/code]

Paul also offers an example which adds color to the screen, but rather than another copy and paste, let me just give you his URL: http://www.paulgriffiths.net/program/c/curses.php

I think it is sort of obvious that ncurses make the job comparitively easy, which is probably why it is recommended. The trick might be replacing C code with PureBasic code and seeing how far it can be stretched. For instance, a Console screen is expected to scroll up as you extend the view downwards.

oldefoxx wrote:The trick might be replacing C code with PureBasic code and seeing how far it can be stretched.

On OSX ncurses is already present in the OS itself. The code you posted converted to PB looks like this With color

Neat. I copied and pasted your PB conversions into hello1.pb and hello2.pb files and placed them in the example folder. But when I tried to compile and run them, I got this message back:

The debugged executable quit unexpectedly

. I had to retype the message by hand, as I could not do a copy-and-paste of the original. That would be a nice feature to add to the PB Editor.

I also loaded and ran the Font.pb file that clearly shows that it's in reach to have a console version that uses different fonts and text sizes. Plus I adjusted the font and size of the PB Editor today, picking a mono font and 12 for better readability. And I noted that the editor self-adjusts to the screen size set for the system, which means it reads the system metrics. Have I access to the system metrics via PureBasic? Is that documented somewhere?

And of course Font.pb shows that I can specify both font and size, which I can then use by loading them. Trouble is, what fonts are available, and what are the size ranges? Do I have access to that information as well?

It seems like all the pieces are there. They just haven't been properly arranged yet into a viable replacement for Window's Console, which is so limited. And the specifics of how to do this must be in peoples' heads, because I don't know how to do it, and I don't see it written down anywhere.

I don't even know what to do about fixing your broken code examples. Except to call this to your attention. Why would the word "debugged" even come up? I've not compiled it with the debugger enabled. More mysteries, more questions yet unanswered.

In Font.pb, the command for text placement puts it on the screen based on a row,column reference. But pixel-count for determining row,column reference is largely dependent on the font size, which as Font.pb shows, does not have to always be the same on any one screen. I'm assuming of course that row and column are related to the present or last font size selected.

Then there are the matters of determining if a character or specific attribute exists at a certain row and column. Windows provided a means to check either of these via a Screen() command that involved row and column. Mixed font sizes on the same screen would mess something like that all up. you technically could mix fonts, or text that is regular, bold, italic, or underscored, but you would likely want to maintain a consistent size with mono-spaced fonts. And consistent sizing is also important when it comes to vertical line scrolling, something a terminal or console window must support. Plus a cursor reference point that shows where your keyboard input will appear.
Also,if no input is requested, the cursor does not appear in the window. I mean we all know how it is suppose to behave, so I'm just putting words to it. We can see elements of all this in what we already have.

You probably know that web browsers generically support the ability to zoom a page via keyboard entry? Crtl++ means zoom in, and Ctrl+- means zoom out. Some browsers offer a scaling feature so that you can permanently set the zoom for all pages as they load. But did you know that that there are some other programs that also support this same keyboard zoom-on zoom-out feature? LibreOffice, gedit, and PB Editor don't. Thunderbird does. Might be a good add-on feature for displaying a console or terminal window.

Oh, I just tried to compile and run console.pb using PB's Linux 64 version 5,31. I get just a hint of a console window, and it's gone. The program is still running, but the Console does not stay up. I would have to say at this point that PB's Console.pb appears Windows specific, while the example code for ncurses and Font.pb are not.

The brief view of a console window may actually be tied to the compiler doing its job, not the running of the program. Hard to judge, The program apparently is awaiting input, because it does not end, I tried entering some characters followed by the Enter key, but it still does not end. I had to kill it.

oldefoxx wrote:Neat. I copied and pasted your PB conversions into hello1.pb and hello2.pb files and placed them in the example folder. But when I tried to compile and run them, I got this message back:

The debugged executable quit unexpectedly

I got my two converted examples to work on windows with the pdcurses library ( http://wmcbrine.com/pdcurses/ ) and changing the import statement to Make sure to set the executable format to 'Console'.

I looked at the ability to work with the Debugger. I don't quite understand it. I've worked with other debuggers, and they give you the ability to watch variables and step through program execution so that you can see what happens. You can step into calls, over calls, or resume running until you exit a call. This debugger gives me some of that, but not the step feature. I guess it all has to be managed with breakpoints.

Oops! I got part of it. You compile with debugger, but the program starts running immediately. you either kill the program (click on small red X), or open the Debugger window and click on stop. If you kill the program, you have to start over. You can't control where it stops, because you need a breakpoint for that, But you can't set a breakpoint until it is already compiled with debugger, is running, and you click on stop.

What is missing is the ability to compile without going right into run (at least not go right into run after compiling with debugger), or the ability to set breakpoints in the source code before you compile with debugger. If you do manage to stop the program in time, or somehow have a breakpoint enabled to stop you, you do have the iptions to step into, step ovet, or step out of a function/sub. But these are controlled by specific function jeys, and that does not work well for me.

The problem is, that with this laptop (an HP Envy 17), the function keys all do double duty. You have to hold down a Fn key on the bottom row while pressing an F-key on the top row to get it to send the right key code. Then you want me to add the Ctrl key to the mix in some cases. And if I am stepping through the program, I have to do this repeatedly.

Why nor let me (and others) pick our own keys for these tasks? I might pick Page Down to go into a function, Page up to get out, and the right arrow or down arrow to keep stepping. Or I might see if I can substitute the other key code when the same function key is pressed without holding the Fn key down.

What is missing is the ability to compile without going right into run (at least not go right into run after compiling with debugger), or the ability to set breakpoints in the source code before you compile with debugger. If you do manage to stop the program in time, or somehow have a breakpoint enabled to stop you, you do have the iptions to step into, step ovet, or step out of a function/sub. But these are controlled by specific function jeys, and that does not work well for me.

"! int 3" as the first line in your source code?

Keya wrote:"! int 3" as the first line in your source code?

It looks like int 3 isn't cross platform.
But you can simply set a breakpoint with F9 or through the debug menu.

If you don't want to use function keys or the debug menu, the functionality is also accessible through toolbar icons.