When I just built, for the first time, a 64 bit app for Windows, using 2018r2, I ended up with this file layout:
[rant]Arghh, why does this stupid forum still not let me embed images?!? All new but worse, that appears to be Xojo’s incorrigible motto. I mean - aren’t there plenty of forums out there that can do this? Why did Xojo have to choose one that was half-finished, and isn’t ever getting better?[/rant]
Why does Xojo not put these new DLLs into the Libs folder, like every other dll? Is there a way to fix this? Does the most recent Xojo version do this better (I have no license for it, so I can’t test)?
I think Microsoft require that the MS runtime files are in the same folder as the executable.
I don’t know why the Xojo Framework is being placed in the root though as previous versions put it in the Libs folder.
You can leave away most DLLs, if the client shave them installed already in system folders.
Why does Xojo not put these new DLLs into the Libs folder, like every other dll? Is there a way to fix this? Does the most recent Xojo version do this better (I have no license for it, so I can test)?[/quote]
This has been stated before but …
Some dlls, like those for plugins, are loaded by the running application using an appropriate API. They can be placed where ever the runtime wants.
The others are loaded by the operating system and that flexibility doesnt exist. It demands they be in certain places and if they are not present the app simply will not be launched by the OS.
So, does that mean that if I include my own DLLs with a 64 bit app for Windows, I should place them also in that same folder and not into a subfolder, when I use declares into that DLL? Or can I safely place mine into the Libs folder with the other DLLs there?
BTW, I was pleasantly surprised that my little app that I developed over the past 2 days, still with Real Studio 2012r2, did build and run just fine for 64 bit on both Mac and Windows. So, not all things are bad, I’m saying
Hi Thomas, I still don’t understand why you still use RB. You will have to rework a lot once you’re forces to move on to a more recent version of Xojo.
Because of the editor. Its navigation works better for me.
And no, I don’t have to rework much at all.
The “worst” problem is not being able to use the newer SQLiteDatabase instead of the REALSQLDatabase, but I can work around that by either using some conditional compiling with #if, or use the MBS SQL plugin instead all over.
That reminds me of our situation until about a year ago
We’ve coded in 2011r3. And used the most current XojoVersion to build for Windows/HiDPI (Windows Store). It’s really not a big deal to code in an older version, but still support many of the newest features
To add one more example: you can even “handle” DarkMode and the (in 2011r3 not existing) AppearanceChanged-Event by using ConditionalCompilation and AddHandler.
Yup. Place your own custom .dll’s in the “official” Libs folder (). Just leave those .dll’s next to the .exe which are required by the OS.
() It’s just… that in some “older” REALStudio/XojoVersion you had to hard-code the "relative Libs Path… but I think that’s now working in recent XojoVersions. If not, you can still put your own .dll’s next to the .exe, too.
I expect that it wont be long before Apple simply make 32 bit apps not work at all and then anyone using old versions will have to resort to some other means like a VM with an old macOS install etc
Apple has already stated that Mojave will be the last macOS to run 32bit… perhaps there will be emulators like Rosetta was, but I’m kinda betting not.
Apple wont ship one - that I have no doubt about
A VM running something older is seems a reasonable option
I have already have 10.10, 10.11and 10.14 VM’s and could make ones for 10.12 and 10.13
Surely Mojave is the “emulator”. It has the 32-bit frameworks and libraries, and runs the 32-bit instructions natively. Next OS version won’t have the 32-bit frameworks and libraries.
Mojave is not an “emulator” it is a full complete operating system that currently supports both 32bit and 64bit applications. An emulator would be a 64bit application running in a 64bit operating system that “fakes” an environment to run 32bit applications.
Rosetta was such an “emulator” it allowed the first versions of OSX to run PPC code
I think you mean “later version”, not “first versions”. And it still required the old PPC frameworks and libraries to be in place, meaning that Apple still had to maintain them. Once Apple stopped supplying those old frameworks, in whichever version of OS X it was, it didn’t matter if you managed to install Rosetta and try to run an old PPC app: it would fail on the first system call as the old frameworks were not installed.
Mojave supports 32 and 64 bit versions because it has both sets of frameworks and libraries in place. Without the 32-bit versions, no longer there because Apple doesn’t want to support them, you can’t run 32-bit apps, “emulator” or not.
Not getting your point? The NEXT macOS will not run 32bit applications… So what Mojave does now isn’t part of the issue, as it won’t be contributing to the solutiion. And yes, IF an emulator is supplied with the next macOS, a 32bit framework will be required, but it won’t be required to be integrated into macOS, which is the point here. It will be similar in nature to a VM (which may be the best solution, but would require a bit more techinical skill to implement)
But because Apple “doesn’t want to support them” is why I said I would bet against any such emulator becoming available.
I would not hold my breath waiting for Apple to announce some kind of support for 32 bit apps after Mojave
macOS has been fully 64 bit since about 10.7 ( 2011 ish ) so this is no surprise they expect all apps to also be 64 bit
Plus they have been saying 32 bit apps wont be supported beyond Mojave
It wont be a surprise if they actually remove all 32 bit API’s etc
[quote=429972:@Dave S]Mojave is not an “emulator” it is a full complete operating system that currently supports both 32bit and 64bit applications. An emulator would be a 64bit application running in a 64bit operating system that “fakes” an environment to run 32bit applications.
Rosetta was such an “emulator” it allowed the first versions of OSX to run PPC code[/quote]
That is not entirelly true. The OS is NOT 32-bit and 64-bit at the same time. It is ONLY a 64 bit OS.
The 32-bit support is made by a subsystem that is actually a emulator that allows 32-bit applications to run seamlessly on the 64-bit OS, being actually a 64bit application running in a 64bit operating system that “fakes” a 32-bit environment.
The app layer is implemented both in 32 and 64 bit on Mac.
The frameworks are build in two architectures.
And they talk via mach ports to system, which itself is 64-bit only.
[quote=430066:@Ivan Tellez]That is not entirelly true. The OS is NOT 32-bit and 64-bit at the same time. It is ONLY a 64 bit OS.
The 32-bit support is made by a subsystem that is actually a emulator that allows 32-bit applications to run seamlessly on the 64-bit OS, being actually a 64bit application running in a 64bit operating system that “fakes” a 32-bit environment.[/quote]
Maybe on Windows with WOW but this is incorrect true for macOS as Christian notes