PureBasic Forums - English

Didn't look at RealBasic for some years but here is how they could do it and I assume PB can do it as well (any volunteers?):

• Suppose they created a native runtime DLL for each system (compiled it natively on each OS) and deliver it with their compiler.
  This runtime takes care of all os calls, gui calls, network calls etc; so RealBasic compiled programs cannot talk to the OS directly but always have to go through the OS specific DLLs.
  (and RealBasic compiled programs need to have that DLL in order to run)
  
  Now with a cross compiler you just have to link against a library that has all calls for a certain OS specific DLL.
  
  Done.
  Now they can call this animal a native program because it is.

XBASIC had/has a runtime DLL for Windows and Linux. It's not a cross compiler, but the same code can be compiled on both OS.

This means if somebody comes along and creates a DLL for PureBasic on each OS (Windows, OSX, Linux) that has the OS/GUI functions wrapped-up (similar to the well known GTK-Server DLL) and then in his programs he never uses "native_" OS API functions but always goes through this DLL it should be possible to do it. (given the PureBasic compiler would be a cross compiler )

One thing for sure though: the OS specific DLLs would be huge
.

Your kind of damned if you do and damned if you don't, when it comes to the desktops
you either need to have all the dependencies of all the target systems on the host system or build platform specific runtimes dll's.
But with llvm you don't have to do any linking to compile your program to bitcode you just pull in the target specific archives which
will then be compiled on the users machine during installation. That way you can ship any specific dependences along with the
assembler and linker. It solves the issue of having the entire foreign system on the host, plus you won't have any legal issues
to worry about either from using and distributing GPL tools specifically gnu as and ld.
Though you probably wouldn't need to do that for linux and mac and for windows it should be possible to use fasm and polink
since the llvm assembler can spit out both AT&T and Intel formats

fsw wrote:Suppose they created a native runtime DLL for each system

Then PureBasic wouldn't be PureBasic anymore. One of the major features of PureBasic (for application programming) is that it creates 100% standalone executables, with no other DLLs or runtime files needed. Just ship a single ".exe" to your customers and that's it. Suddenly requiring a runtime DLL makes it far less attractive, and makes people start comparing PureBasic to other runtime-based languages. After all, if all BASICs use a runtime, then PureBasic just becomes equal to them with no advantages whatsoever.

MachineCode wrote:

fsw wrote:Suppose they created a native runtime DLL for each system

Then PureBasic wouldn't be PureBasic anymore. One of the major features of PureBasic (for application programming) is that it creates 100% standalone executables, with no other DLLs or runtime files needed. Just ship a single ".exe" to your customers and that's it. Suddenly requiring a runtime DLL makes it far less attractive, and makes people start comparing PureBasic to other runtime-based languages. After all, if all BASICs use a runtime, then PureBasic just becomes equal to them with no advantages whatsoever.

While this may be true, the fact is that it would not be a major undertaking to make it an option for those who want it their choice, rather than forced upon them. It would open PB up to a larger market.

The problem with the virtual system is: MacOs - it is not allowed to use it in a virtual machine (only on macs) - i don't have on.

Tenaja wrote:

MachineCode wrote:

fsw wrote:Suppose they created a native runtime DLL for each system

Then PureBasic wouldn't be PureBasic anymore. One of the major features of PureBasic (for application programming) is that it creates 100% standalone executables, with no other DLLs or runtime files needed. Just ship a single ".exe" to your customers and that's it. Suddenly requiring a runtime DLL makes it far less attractive, and makes people start comparing PureBasic to other runtime-based languages. After all, if all BASICs use a runtime, then PureBasic just becomes equal to them with no advantages whatsoever.

While this may be true, the fact is that it would not be a major undertaking to make it an option for those who want it their choice, rather than forced upon them. It would open PB up to a larger market.

I don't think cross-compilation is worth it. Let's keep PB small and fast.
As has been said, you still need the native system to test on, why not just install PB there and compile?
I'm not clear on how this would open PB up to a larger market?
I'm not advocating it but it seems like easier event-handling would increase PB's attractiveness to some types of developers, but that would likely increase the minimum executable size as well.

USCode wrote: I don't think cross-compilation is worth it. Let's keep PB small and fast.

There's no reason why it wouldn't be small and fast!
A runtime dll is really only a convenience solution but isn't necessary
Also you don't really need to have the foreign system libraries either not if you can compile to an intermediate form and leave it up to the installer to compile to the target at installation time.
In that case all you need to know is the targets systems function calls and imports libraries and ship the ir code in the installer
which can either be compiled or Jited if the user only wanted to demo it.
As long as you know that the libraries being used are part of the OS you would be fine
Though of course, you would still need the target OS to test your code on.

GPI wrote:The problem with the virtual system is: MacOs - it is not allowed to use it in a virtual machine (only on macs) - i don't have on.

Mac OS X Server is allowed to run on a VM, i guess. It is official supported
by VirtualBox. And for VMware, there is a hack to get it run. But the bigger
problem is, that you need the right real architecture to get it run in the VM.

And if you have bought a license for a Mac OS, why it shouldn't be allowed
to be run in a VM? I doesn't think that it is illegal to do that in Germany. There
are many things, that Apple doesn't want but that doesn't mean it is not legal
to do it.

MFG PMV

Mac OS Server run in VirtualBox with Windows-Host only in a modified Version and this is not allowed.
VirtualBox supports Mac OS Server only on Mac OS Hosts

idle wrote:As long as you know that the libraries being used are part of the OS you would be fine
Though of course, you would still need the target OS to test your code on.

When i look on my Crillion-Code - only a small part of the code is really System-depending. So i only must find someone who translate this small pices to MacOs and after that i can compile the game by myself. When i change something in gameplay (for example the value of the points for a broken block) no big tests are necassary.

GPI wrote:

idle wrote:As long as you know that the libraries being used are part of the OS you would be fine
Though of course, you would still need the target OS to test your code on.

When i look on my Crillion-Code - only a small part of the code is really System-depending. So i only must find someone who translate this small pices to MacOs and after that i can compile the game by myself. When i change something in gameplay (for example the value of the points for a broken block) no big tests are necassary.

No, I was talking Hypothetically about a pb cross compiler that can target an intermediate bitcode.
If you have a cross compiler targeting a virtual architecture along with user libraries which are archived in intermediate form
including versions for each supported platform, then it would be possible to do.
When compiling your code to bitcode you are not linking to native system libraries, so you don't need to have them on the host.
It will only link bitcode modules to produce a single bitcode file of your application, which you would zip and add to the installer.
When it comes to compiling to native code it is all done on the customers machine, via the installer which includes
a JIT engine, assembler and linker. You would also need to include any 3rd party native libs in the installer.

USCode wrote: I'm not clear on how this would open PB up to a larger market?

The "market" for Java is MUCH larger than PB. Do you think it is entirely because it is easier to learn? Hardly--PB is much easier than Java. Or just because Sun put it together? Sure, they'll give it a certain credibility that "Fred compiler writer" (meaning the average Joe) will never have....but It's also partly because it's a lot easier to make cross-platform programs. Heck, that's their whole mantra!

I'm currently working on a compiler of my own, its output is ANSI C code which gets passed to GCC and theoretically it should be able to target Windows and Linux. But to get where I want to go with it will take years at the rate I'm going. I think the idea is sound enough though.

netmaestro wrote:I'm currently working on a compiler of my own, its output is ANSI C code which gets passed to GCC and theoretically it should be able to target Windows and Linux. But to get where I want to go with it will take years at the rate I'm going. I think the idea is sound enough though.

If you used LLVM it would save you all those years!
It also does source to source transforms, you can simply tell it to emit c or any other language where
it has the respective front and backend plugins for the source and target language.

netmaestro wrote:I'm currently working on a compiler of my own, its output is ANSI C code which gets passed to GCC

In case you are interested GLBasic does the same thing (it's a precompiler emitting c++ code for gcc).
The result is quite crappy in its case (bloated code and it's very difficult to have a fine control of what you are doing).
Pratically you inherit the bloat-iness of GCC for Win and loose the ability of make good C++ code manually!