My client wants an application, that uses 10.7 specific features (eg. it's compiled with 10.7 SDK to support resume, no specific code changes are needed for this), but it's needed, that the same application runs on 10.5 and 10.6. This application shall get into App Store.
Any ideas?
Also you could set Deployment target to 10.5 and all will be fine. But in this case specific Lion features will be not working in the lowest versions of osx. Also you should not call selectors thats not exist in lowest versions. In this case you should wrap osx 10.7 selectors into responsToSelector: statement.
Related
Since Mac OS 11 Big Sur release Apple allows installation of kext drivers in the Recovery mode only.
It also prohibits installation of kext drivers from Apple store. Which I guess is the end of macFuse, at least for virtual/cloud file systems.
What would be the migration path and how to build virtual file systems for Mac OS 11+, in particular for document management and cloud storage, similar to OneDrive, DropBox, etc.
I can also guess that a similar issue may appear on Windows too. I can imagine that Microsoft will follow Apple's path and will prohibit file system drivers and filters on Windows for these purposes in future releases.
Any hint for future migration if such a situation happens would be appreciated.
Since macOS 11, Apple has updated documentation of the File Provider API which can be used to sync files between client and server and may serve as a replacement for file system drivers. Until this day Apple has not officially announced that functionality on macOS.
The API is similar to the File Provider API that Apple has provided for iOS 11 some time ago but still it has some differences in mostly how main FileProvider class extension works and which abilities it has. There is no examples at this moment that I’ve seen but it looks like this functionality works at least on basic level. Based on what people say on the forums.
On Windows, Microsoft has introduced the Cloud Storage Provider (Cloud Sync Engine) API for Windows 10 in the year 2018 (Windows Creators update). It is used in One Drive for Windows. Here are some examples on GitHub in C++ and in C#.
The repository 'https://packagecloud.io/realm/realm/linuxmint serena Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
We don't support Linux Mint at this time.
Edit regarding the comment:
We support Linux. It's the only platform we support in production.
We support Ubuntu 16.04, CentOS 6 & 7 (as indicated on the website). You can trivially create a docker container or VM using one of these base images on Linux Mint. We have a number of issues requesting Debian support, Fedora support, native Docker image, but none formally requesting Linux Mint support.
We obviously want to make the experience as painless as possible for everyone, but we also have to be very strategic when deciding to add a new platform as officially supported. Our CI has to build and test every single change on this new platform. We have to be able to support our users, etc. For example, we already have some bugs that only appear on CentOS 6, but not on 7 nor Ubuntu, so we want to make sure we stabilise things before moving ahead.
Feel free to submit a feature request to support Linux Mint. That way you will have a place where you can ask us directly about progress.
Firstly my original question link regarding PB 10.5 on windows 7 64-bit has been mostly answered in the following link - PowerBuilder 10.5 Application on Windows XP 32-bit to Windows 7 64-bit
Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine?
Currently have a 32-bit application on Windows XP. Client wants it working in Windows 7 64-bit. I know this is a big jump and PB 10.5 has been unsupported for a long time now.
Has any one successfully fooled around with The Runtime Packager PowerBuilder runtime DLLs and got any of the following DLL's wokring in a Windows 7 64-bit system?
libjcc.dll
libjutils.dll
pbacc105.dll
pbdwe105.dll
pbdwr105.dll
pbdwr105.pbd
pbjag105.dll
pbjvm105.dll
pbshr105.dll
pbtra105.dll
pbvm105.dll
I realize these are 32-bit DLL's but I need to start somewhere and not sure how to tackle this one. Hoping for anyones help or advise.
I suspect the most useful answer to you is a completely useless answer.
First point is that PB 10.5 pre-dates Windows 7. Very obviously, any success of 10.5 on Windows 7 is going to rely on Microsoft's ability to provide forward compatibility of applications. (MS's success with providing forward compatibility is stellar compared to other platforms I've used, but has never been perfect.)
Windows 7 was released around the PB 11.0 time frame, IIRC. It took Sybase to somewhere in the 12.0 cycle to announce that they would support Windows 7. Support for a new platform is a good feather for your marketing cap, so a reasonable interpretation of this delay is that they found some issues and had to work them out. (To the best of my knowledge, Sybase never listed those issues in one place, although some probably show up in the bug lists published with each patch.)
I'm going to go out on a limb and bet that if you created a 10.5 application with one line in the application Open event:
MessageBox ("Hello World!", "It's me!")
and deployed this to Windows 7, it would work. Conversely, from what we've inferred from Sybase's behaviour, there exists some combinations and permutations of features that will fail when deployed to Windows 7. Where your application lies in this n-dimensional spectrum of features and complexity is hard to tell.
So, I suspect that your most useful answer to your question is that it doesn't matter if I've had success with a 10.5 application on Windows 7; my experience may not have a bearing on your application's success on Windows 7. There are known risks, even if we don't know exactly what those risks are.
I do use PB11.5 IDE on Win7/64 (that is also 32b) without problem.
Concerning the runtime packager, I do not use it anymore because I develop and maintain several products that are released asynchronously and may occur to need different runtimes, sometimes from different major PB version (10.5 / 11.5) and sometimes from different releases (EBF) of the same major.
As PB seems very picky regarding the version of the runtime (in the sense that you'd better distribute the exactly same build for the runtime as the version the application is build with), I place the runtimes dll in the same directory as the application files. There is no problem for a PB 10.5 / 11.5 PB application to use its runtime files in the same directory.
Export the registry information of those dlls from a working xp 32 bit system.
if the dlls didn't reside in the powerbuilder's executable path, but something
like C:\windows\system32 or one of system32's subdirectories instead then copy
the dlls to the windows 7 64 bit system's related c:\windows\syswow64 folder
area. If it was necessary to place them in a new location then modify the
registry exports to point to the new location. If you they were from the powerbuilder's
executable path, then you don't need to modify the registry exports.
Merge them into the registry. Rebooting might be required. I've had
success with this when old dll and ocx files turned out to be necessary
to keep stuff like office database apps working after upgrading
office versions. you'll want to keep a copy of the dlls and registry merge files
in offline storage incase you have to rebuild your system from scratch
at some future date. Good luck.
PB 10.5 runs fine on Windows 7 (32 or 64 bit) from my all of my experience. PB 10.5 is still relatively common at large corporate IT shops, along with 11.5, 12.5 & PB 2017 (and above).
The package manager, included with PowerBuilder will gather all the runtime libraries needed. Windows 7 64-bit can run 32 bit or 64 fine via SYSWoW64, the 'WoW64' stands for Windows 32-bit on Windows 64-bit. SysWoW64 process running in your Windows is part of your Windows operating system.
By now all Mac App Store developers know that all apps must have the new OSX Lion Sandboxing enabled going forward. For existing apps, we must enable it in XCode 4.2 and set in place the data migration plist.
So my existing Mac App Store app has a build target of OSX 10.6.8 Snow Leopard. Not only that, but it does access the webcam and also synchronizes stuff to iCal via CalendarStore API and AppleScript. I'm expecting most of my app to break when I enable the Sandbox, but when I get that working in the Sandbox I'm wondering if a Sandboxed app can run in Snow Leopard.
Does anybody have experience in migrating to the Mac App Sandbox? I would like to know if enabling this would break Snow Leopard compatibility, and what I am up against given the entitlements my app will require.
Snow Leopard is an awesome OS and I'd like to support it as long as reasonably possible, for those users who have a Mac not quite new enough to run Lion.
After enabling entitlements and sandbox while still keeping the build target as 10.6, I was able to get my app up to speed so it operates within the sandbox in Lion. E.g. file access, calendar access, webcam access.
Once I had that taken care of, I built a .pkg file and installed it on my old Mac Mini running Snow Leopard. It seems to run in Snow Leopard just as it did before. Unlike Lion, it won't migrate your config and plist-defined folders as it seems the sandbox stuff that is compiled in is completely ignored when run under Snow Leopard (which makes sense since the Lion kernel is probably doing all the work).
So there you have it, the short answer for backwards compatibility is "Yes". Although who is to say Apple won't restrict 10.6 targeted builds from being uploaded to the Mac App Store once March 1st hits? Probably not, but it will happen eventually. I'm not trying to start a rumor or anything, it's just a thought.
Anyways, I hope Apple continues to let us support Snow Leopard users, as I imagine they are still the majority of the Mac users out there. Take this article with a grain of salt, but still...
http://www.theverge.com/2011/11/11/2554009/mac-os-x-lion-adoption-slowing
I have a problem with legacy 32-bit C application, built in Mac OS 10.4, with Xcode 2.2.0. It runs correctly on later (64-bit) systems (10.5 and later), but if I try to build it in later Xcode versions (2.2.1 - 3.2.6) on 10.5 and later, it's behavior changes, even though I set SDK 10.4 and GCC 4.0 everywhere (in "project settings" and "active target settings").
Details on changed behavior: when getting function addresses through CFBundleGetFunctionPointerForName() and then calling them, some return pointers. Then:
If application is compiled in Xcode 2.2.0 in Mac OS 10.4, and running in 10.5+, pointers could not exceed LONG_MAX, so signed long is sufficient for storing call result.
If application is compiled in Xcode 2.2.1+ in 10.5+ and running in 10.5+, pointers could be in range LONG_MAX..ULONG_MAX.
And interpreting result as signed long is essential, because functions, returning signed long (not pointers), are called exactly the same way. Changing it would be making a kludge, so please don't suggest splitting calls to functions that return pointers and functions that return result immediately - it would be done only if I cannot get a correct build.
This difference of builds' behavior I could explain only as calling in runtime some other bundles than an older build would call - and that is possible if 1) CFBundle library, which calls functions, is not the same as in real 10.4, or 2) system correctly determines SDK of an older build, and uses the correct "backward compatibility", but something in newer program settings is wrong, and so other bundle is called in runtime.
So I wonder, are there any "hidden" options in Xcode or its backends, that make a difference between real 10.4 build and build against 10.4 SDK in later OS?
Or how I can search for such differences?