Classic VB still ranks on the TIOBE index
Xojo doesnt
That says something
3 Likes
That is coz the IDE and the compiler are stable and it generated true executable.
It still generates. That’s it.
na… you forgot VBRUN.DLL
I wonder if it is still included in every Ad-System named “Windows”?
1 Like
But does not mean that VB6 does not generate true executable.
Even VC requires a set of runtime libraries for applications built in it to run.
Even Xojo is dependent on VS runtime.
The runtime is needed. But that is also the case for many others. Xojo delivers many stuffs with it’s applications while needed to run it on the target platform. That is acceptable. The times where we had only to get the exe file passed by (actually I never had that kind of time while developed many Apps with C on Unix and had always to include a bunch of libraries).The Idea that an App has to be delivered as one file application is ended. We have to get used to it even if we don’t want to.
Even on Linux there are many prerequisites to install for running Xojo. On MacOS not but they deliver with the distribution.
As an answer to the question if VB6 is still supported on Windows 11 there is a statement of MicroSoft last acutalized in 2023:
1 Like
if any runtime (or middle-ware, etc.) is needed then you hardly cannot speak from “real executables”, can you? These “executables” in most cases are nothing but a stub to some kind of framework.
“Real” in my humble understanding are executables running without any dependency. And they are not run inside any kind of Container (like PyInstall creates). Just a plain small .exe, in many cases not larger than some KB.
Like this example. I’ve made in Freebasic. A 52 KB small Exe with a memory-footprint of only 550 KB for automatically restarting crashed services.
1 Like
I can do that in C if you want. And I can do it with Java and GralVM. But it makes no differences if I do it in this wise or not. Where is the problem with an executable with dependencies? Nowhere. We could speak about in old times. When 1 MB was causing 5 minutes transfer time in old medom times. But today? Not really, really not. By the way. Even RUST produces single file executables. But for complex GUI programs? Where is the sense behind? Xojo has to do it cause the Libs are mostly open source licensed. And there licenses are with classpath exeption. Means: no including into the executable but dynamic linking. So or so: if it would make any sense to compile single file executables…but there is really NO sense.
We can do a competition. Freebasic, Rust, C, C++ (with external Files and runtimes), Java (with JRE) and Java (compiled to single file executable). What is faster. You may see: there is no such big difference between Java, C++, V and Rust but to freebasic. That’s more interesting cause it touches performance. All other things: not from any interest.
Safety critical application could be statically linked to minimize the attack surface, otherwise I see no compelling reason to do it.
We spoke about that: it is possible to do with languages like C, C++, Rust. But not with Xojo. Therefore it is not recommended to use Xojo with high security requirements. So using it for aviation, shipbuilding, tanks or things like that isn’t a good Idea. But hey, who needs security. Most XoJo users does not need any kind of security. And many may not have even an Idea about.
Of course you can - no doubt about that, but you are missing the point.
We are talking about the definition of “real” executables. And from my vantage point any language/ IDE/ Framework, unable to create a single executables without linked dependencies, is kind of handicapped and therefore crap.
Of course I should be able to link against other DLLs like the GTK or other kind of (visual) frameworks and this is what modern software does.
We can do a competition (…) What is faster.
it’s not about speed aswell. I want my software as simple and as small as possible following the UNIX principles
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
So MS Excel isnt a “real executable” ? Or anything else in the MS Office suite ?
They all include many many dll’s
Open Office ?
Statically linking in everything you might need is simply not viable now
Nor is it desirable since it consumes vastly more system resources than you might actually need - EVERYTHING is loaded when the app starts
And it will make your app start up slower
2 Likes
Perhaps I have expressed myself in a misleading way. We are talking about programming languages and IDEs. If such a programming language requires a more or less bloaty non-open-source runtime, generates non-reproducible builds, even for the smallest CLI or HelloWorld apps, then I consider it as not powerful nor professional.
Xojo or Realbasic never have been that, its advantage was RAD.
1 Like
Java graalvm makes what you want to. Jpackage also. One executable file that’s it. And many more. But what you say is java, c#, c++ are not professional languages? That’s far away from true sir
While I might quibble with the “real executables” phrasing as I dont think its the crux of the issues Xojo has
All these tools, Xojo included, generate actual proper PE32+ executables for Windows - and proper executables for the other platforms they target
IMHO the big failing Xojo has its its lack of attention to, or ability to address, the bugs in their runtimes. Something other tools dont have as much of an issue with for whatever reasons (larger teams, narrower focus, more money, or other factors)
4 Likes
Because the CEO has no ambition with the product and the CEO is in charge of product development. Xojo could easily be a much better product, heck I was willing to put the work in to do it (for a fee of course), but my skills and efforts are not needed because Xojo is exactly how it should be.
My guess is that Xojo doesn’t have the cash, it is basically on tick over until the last person leaves. Each and every passing year, Xojo become less and less competitive, I mean it’s great that they’re adding pre-emptive threading, but there’s so much that they’d need to do to catch up with the rest of the industry.
As for their attitude to bugs, I can tell you that’s doing them no favors. I know of the dev who recently came to me because they couldn’t get a solution from Xojo support of the forums. Last time I spoke with them, they’re talking about re-writing the app they just created in a different tool, but of the bugs and not always available workarounds.
On real executables:
Thats part of the job of an operating system, isn’t it?: providing a base for software to be developed on, abstracted from the hardware?
The way ‘real’ executables are being referred to here implies software should be like spinrite. But for similar reasons to why Real Basic started, we have operating systems and the APIs and runtimes they provide to build applications on.
Sometimes those runtimes are decoupled from the OS and you have .Net, the redistributables, dlls, etc. Sometimes they are built outside of an OS. But regardless, all of them can to some extent be considered real executables.
If you draw the line at bytecode type things like .net, java, etc. it’s good to remember that everything written is targeting some kind of intermediary code like that. It’s just some of it is cross platform. Most of us don’t write in binary or assembly anymore. Unless we’re writing spinrite or a boot loader, we’re not compiling down to a level of exe we might idealize.
1 Like
The Way Microsoft uses Visual C++ with the CRT abstracted in a separated DLL, yes that’s IMHO not professional.
AFAIK 20 years ago they did not do this and other C/C++ compilers do not do this either.
But this seems to be a Windows only problem based on the fact, that it is build on multi-decade long technical debts. Try to create a file named CON and say Hello to CP/M.
All these tools, Xojo included, generate actual proper PE32+ executables for Windows (…)
Agree. They are executables. They do start, including their linked Libs. But that’s valid for every kind of PE-Container format, even for “compiled” Batch-Skripts, which basically do the same: At start, they are extracted and thrown against some sort of runtime either included in the exe or linked outside.
A “real” (or should I better say “native”?) executable does not do this.
Modern software needs dependencies and is linked to external libs, Of course, nothing wrong with this. But a Dev must have the freedom the decide. For a small handy CLI tool or a system service/daemon I do not want to be pushed to use a bloaty framework consuming lots of MB in RAM and diskspace per user on a system.
what do you mean by this? I was compiling and linking to libraries on the Vax with the monochrome amber screens and all