<solved> QB64 without its IDE GUI ?

[Fifi]

Hello all,

First of all receive my best wishes for this new year 2023.

Some time ago, I had seen somewhere (I think here) a topic with the title "QB64 without GUI" as project.

Can anyone direct me to this topic?

Moreover, is the QB64PE code sufficiently well documented to quickly and easily remove all the code necessary for the IDE, leaving only the translation in C++, the compilation part and the error messages (and maybe the line numbers concerned) as return in the event of a compilation error?

The goal of such an operation being to produce the smallest possible executable for an embedded system.

The first target would be on a framework of Linux system but I guess that could also be used on OS/X and maybe Windows on tiny computer such as the Pi platform.

Thanks in advance for any suggestions on this subject.

Happy new year 2023.

[mnrvovrfc]

The code for the IDE isn't included in an user's program's executable file, what made you think that it was?

The QB64 IDE was meant for somebody to start straight away to program instead of having to install Geany, NPPP or some other program like that. People have been crying for an IDE for Freebasic that comes directly from those developers. "Where's the blue screen?" I wince everytime I read that from the Freebasic help file.

You will have to look into that other system instead and forget about QB64PE having a "headless" version. Although this is only an opinion.

Even if there was a "QB64 without GUI" thing, it wouldn't be officially supported by the Phoenix Team or by the "qb64-dot-com" folks and you, or anybody else that decided to depend on that project, would be entirely at the mercy of that program's development. Generally it means becoming one of the dedicated contributors.

About making executable files smaller, just give up with 64-bit. When we all have to move up to 128-bit or something like that, even more memory will be required for everything. The "keep it small" mentality that is enforced by 16-bit has to be ditched in favor of progress. Some people aren't going to like it.

The "keep it small" means QB64PE would have to turn into a payware project that resembles M$ Visual Studio in its early versions. In other words, a compiler that directly takes BASIC code, creates object files, combines them with stuff taken from libraries and spits out an EXE file or a Unix-like executable file. Freebasic is close to that reality. QB64(PE) have different goals to set.

[SMcNeill]

The code for the IDE isn't included in an user's program's executable file, what made you think that it was?

The QB64 IDE was meant for somebody to start straight away to program instead of having to install Geany, NPPP or some other program like that. People have been crying for an IDE for Freebasic that comes directly from those developers. "Where's the blue screen?" I wince everytime I read that from the Freebasic help file.

You will have to look into that other system instead and forget about QB64PE having a "headless" version. Although this is only an opinion.

Even if there was a "QB64 without GUI" thing, it wouldn't be officially supported by the Phoenix Team or by the "qb64-dot-com" folks and you, or anybody else that decided to depend on that project, would be entirely at the mercy of that program's development. Generally it means becoming one of the dedicated contributors.

About making executable files smaller, just give up with 64-bit. When we all have to move up to 128-bit or something like that, even more memory will be required for everything. The "keep it small" mentality that is enforced by 16-bit has to be ditched in favor of progress. Some people aren't going to like it.

The "keep it small" means QB64PE would have to turn into a payware project that resembles M$ Visual Studio in its early versions. In other words, a compiler that directly takes BASIC code, creates object files, combines them with stuff taken from libraries and spits out an EXE file or a Unix-like executable file. Freebasic is close to that reality. QB64(PE) have different goals to set.

I know you don't like me correcting you @mnrvovrfc, but you're wrong here.  The IDE is completely separate from the core part of QB64.  If one wants a version of QB64 without the IDE anywhere in the source, all they have to do is go into QB64PE.bas and remark out or remove the two $INCLUDE lines that add in the IDE.

At lines 33 & 34:

Code: (Select All)

'-------- Optional IDE Component (1/2) --------
'$INCLUDE:'ide\ide_global.bas'

At the very last lines in qb64pe.bas:

Code: (Select All)

'-------- Optional IDE Component (2/2) --------
''$INCLUDE:'ide\ide_methods.bas'

Remark those out/remove them.  Recompile to a new version of qb64pe, and you now have a version with absolute no IDE attached to it.

Now as to WHY you'd want a version without the IDE....  I dunno!!  All you're doing is stripping out the possibility of using the IDE if you ever decide to, but it won't affect the EXE you create from the command line in any way whatsoever.  We don't put the IDE into your compiled code.  We never have.  

I honestly can't see any reason why someone would want a version without that option, but if they do, then that's all it is for them to make the changes and make one.  /shrug

[mnrvovrfc]

I am only a student.

I wrote what I did because it surprised me that somebody is requesting QB64PE without an IDE, while people with another programming system have been groveling for one for many years. Another thing is there are a lot of editors with source code available out there but none of them could be fixed in a short time to be a substitute for the QB64 IDE. I mean, a replacement IDE which is part of QB64PE.

The QB64 IDE is an amazing thing despite its differences from the QuickBASIC one. Such as the most annoying one, its complaining as soon as something is typed which is a syntax error or something else only because I didn't finish typing in the line! The Free Pascal developers did a nice job with the IDE that apes the one in Turbo Pascal which is also cross-platform.

The thing about 64-bit and EXE file sizes is harder to tackle. Must make sure there is enough space. Never mind that Linux distros are still being built which image is 16MB, and forget what the Linux From Scratch book says about reducing it, to get anything like MS-DOS Shell v4 working!

[aurel]

I know you don't like me correcting you @mnrvovrfc, but you're wrong here

i must say that i agree with SMc

and i don't know that is really easy to make qb64 version without IDE..
personally i never liked that type of DOS-like editors ..so i use my own

FB people complain about editor because id not shipped with compiler not because
not built in...

well
Maybe i will try to recompile it without IDE!

[Fifi]

The code for the IDE isn't included in an user's program's executable file, what made you think that it was?

The QB64 IDE was meant for somebody to start straight away to program instead of having to install Geany, NPPP or some other program like that. People have been crying for an IDE for Freebasic that comes directly from those developers. "Where's the blue screen?" I wince everytime I read that from the Freebasic help file.

You will have to look into that other system instead and forget about QB64PE having a "headless" version. Although this is only an opinion.

Even if there was a "QB64 without GUI" thing, it wouldn't be officially supported by the Phoenix Team or by the "qb64-dot-com" folks and you, or anybody else that decided to depend on that project, would be entirely at the mercy of that program's development. Generally it means becoming one of the dedicated contributors.

About making executable files smaller, just give up with 64-bit. When we all have to move up to 128-bit or something like that, even more memory will be required for everything. The "keep it small" mentality that is enforced by 16-bit has to be ditched in favor of progress. Some people aren't going to like it.

The "keep it small" means QB64PE would have to turn into a payware project that resembles M$ Visual Studio in its early versions. In other words, a compiler that directly takes BASIC code, creates object files, combines them with stuff taken from libraries and spits out an EXE file or a Unix-like executable file. Freebasic is close to that reality. QB64(PE) have different goals to set.

I know you don't like me correcting you @mnrvovrfc, but you're wrong here.  The IDE is completely separate from the core part of QB64.  If one wants a version of QB64 without the IDE anywhere in the source, all they have to do is go into QB64PE.bas and remark out or remove the two $INCLUDE lines that add in the IDE.

At lines 33 & 34:

Code: (Select All)

'-------- Optional IDE Component (1/2) --------
'$INCLUDE:'ide\ide_global.bas'

At the very last lines in qb64pe.bas:

Code: (Select All)

'-------- Optional IDE Component (2/2) --------
''$INCLUDE:'ide\ide_methods.bas'

Remark those out/remove them.  Recompile to a new version of qb64pe, and you now have a version with absolute no IDE attached to it.

Now as to WHY you'd want a version without the IDE....  I dunno!!  All you're doing is stripping out the possibility of using the IDE if you ever decide to, but it won't affect the EXE you create from the command line in any way whatsoever.  We don't put the IDE into your compiled code.  We never have.  

I honestly can't see any reason why someone would want a version without that option, but if they do, then that's all it is for them to make the changes and make one.  /shrug

Thank you SMcNeill for your explanation.
This is exactly what I was looking for.
BTW, I never ever said that the IDE was included in the executable that QB64PE produces.
I sure was not precise enough when I wrote "The goal of such an operation being to produce the smallest possible executable for an embedded system" and not saying "The goal of such an operation being to produce the smallest possible compiler executable for an embedded system".

@mnrvovrfc, more, I never ever asked to remove the IDE from the QB64PE project nor to replace it by another Editor even if I wish some modification such as a good support of the mouse in the IDE under macOS (yes, it's a pity to use the IDE with a mouse on a iMac witn macOS). BTW, why a gqb64pe or simply gqb (the compiler alone without any IDE) would become a payware project? I feel that's insane to compare such use to any M$ product good or bad. QB64PE is an open source project and I hope it will stay as is forever.

Thanks again SMcNeill for the info.
Cheers. 
Fifi

[mnrvovrfc]

Maybe I wasn't clear enough with what I said.

A few people in the Unix/Linux world make such a big deal about how much memory a program takes, whether it's stored on disk or it's loaded into RAM. By its very nature, QB64(PE) is unable to create an executable file small enough to satisfy those people. This is even with using console-only stuff. Therefore they have to do it in C++ or assembly language, and if that doesn't make them comfortable, they buy a programming system suite. They are willing to compromise efficiency but not too much, if it could be made smaller at both ends.

The compiler itself doesn't have to be very small, indeed. The MS-DOS target for Freebasic mostly requires programs compiled on a system more sophisticated than the target of the user program. There's too much needing for the sake of extended memory, for peripherals such as printers and USB devices, and there's even begging for Internet Wifi functionality. Maybe I don't know what I'm saying but...

Let's go back to what I have read on other forums, about the protesting that it's "too big". Coding in assembly language is difficult and doesn't guarantee cross-platform but the one who could do it correctly benefits from memory and speed improvements. This is essential for a setup which doesn't have a lot of RAM; not everybody is on 64-bit with 16GB RAM. A portable phone is most suspect to memory limitations. Definitely it has to run fast and faster.

For those situations which have enough memory, magic is being done with Python such as the famous "archinstall" for Arch Linux which didn't work on my computer LOL because I have too many partitions on my HDD and it wanted to pick one at random.

BASIC as a replacement for the mind-boggling Bash command processor language would be great, but it would be one bloated complex program replacing another.

[Fifi]

Maybe I wasn't clear enough with what I said.

A few people in the Unix/Linux world make such a big deal about how much memory a program takes, whether it's stored on disk or it's loaded into RAM. By its very nature, QB64(PE) is unable to create an executable file small enough to satisfy those people. This is even with using console-only stuff. Therefore they have to do it in C++ or assembly language, and if that doesn't make them comfortable, they buy a programming system suite. They are willing to compromise efficiency but not too much, if it could be made smaller at both ends.

The compiler itself doesn't have to be very small, indeed. The MS-DOS target for Freebasic mostly requires programs compiled on a system more sophisticated than the target of the user program. There's too much needing for the sake of extended memory, for peripherals such as printers and USB devices, and there's even begging for Internet Wifi functionality. Maybe I don't know what I'm saying but...

Let's go back to what I have read on other forums, about the protesting that it's "too big". Coding in assembly language is difficult and doesn't guarantee cross-platform but the one who could do it correctly benefits from memory and speed improvements. This is essential for a setup which doesn't have a lot of RAM; not everybody is on 64-bit with 16GB RAM. A portable phone is most suspect to memory limitations. Definitely it has to run fast and faster.

For those situations which have enough memory, magic is being done with Python such as the famous "archinstall" for Arch Linux which didn't work on my computer LOL because I have too many partitions on my HDD and it wanted to pick one at random.

BASIC as a replacement for the mind-boggling Bash command processor language would be great, but it would be one bloated complex program replacing another.

No offence at all @mnrvovrfc, but yes, obviously you're only a student and jump into my thread and respond to my question without having a damn clue of what I'm looking for and, more importantly why. [url=https://qb64phoenix.com/forum/member.php?action=profile&uid=192][/url]

Meanwhile, happy new year and long life to QB64PE with and without its IDE.

[mnrvovrfc]

At your service. I deserved that "damn" and that tongue emoticon.

I was trying to make an edit but this web browser went crazy and rejected my post edit. Anyway I didn't "jump" into this thread. It was supposed to be in "General Discussion", if I were mod I would have moved it there since this does have to do with QB64(PE), doesn't it? Don't at-sign me anymore, I'm going to let them sit.

[Fifi]

At your service. I deserved that "damn" and that tongue emoticon.

I was trying to make an edit but this web browser went crazy and rejected my post edit. Anyway I didn't "jump" into this thread. It was supposed to be in "General Discussion", if I were mod I would have moved it there since this does have to do with QB64(PE), doesn't it? Don't at-sign me anymore, I'm going to let them sit.

No offence again mnrvovrfc, the at-signe went alone with this crazy web bowser. I'll do my best to avoid it again.
BTW, may I fairly suggest that you give a look at my bio on my profile. 
I'm a native speaking French and sometimes my english is not good enough to explain my ideas without conflictual terms.
Cheers.
Fifi