Does anyone know library to browse (and upload/download/stream) on smb shares (SMB/CIFS protocol) from iOS. This must be support for all the Windows OS. This is grade help for me.
Not quite an answer to your question, but I have some tips:
If you write your own client, don't trust the IETF RFC. Microsoft
hasn't been scrupulous in its adherence to the spec. And be sure to
test with Unicode file/folder names, all major versions of Windows,
and so on.
Don't write your own client. :-)
If you use an open-source library, make sure it's not GPL or LGPL,
unless you plan to open-source your entire project. LGPL almost
works—it does on Mac OS X—but it requires dynamic linking, which
isn't supported on iOS.
You may see apps in the app store that use GPL or LGPL libraries,
but don't assume that it is safe to use them yourself. Those apps
are often blatantly abusing the license.
opensource.apple.com has an smb client that's a great reference but
it's a file system kernel extension, so you can't use it directly.
Related
we have developed a kernel extension (KEXT) for a virtual file system (VFS) on macOS to integrate our software with external programs like Adobe InDesign or Microsoft Word. Our software and the KEXT are used by many of our customers.
As it looks like KEXTs are deprecated and may be removed completely in future versions of macOS, particularly on Apple Silicon based computers. See e.g. Apple's announcement in its security guide:
"This is why developers are being strongly encouraged to adopt system extensions before kext support is removed from macOS for future Mac computers with Apple silicon"
Therefore we are currently investigating in possible alternatives.
Apple suggests to migrate to System Extensions instead of KEXTs. However, the only VFS related API we found is to implement a File Provider that is based on an NSFileProviderReplicatedExtension.
Unfortunately that NSFileProviderReplicatedExtension has several flaws:
Files can either be in the cloud or downloaded. It is not possible to download/read only a portion of a file. This is a big performance problem for us, since we work with large images (> 1GB). The programs we integrate with typically only read a part of the image, e.g. the embedded preview. The API does not offer a way to access selected blocks of a file (random access file).
The File Provider learns about the file system content via enumerators. So everything that is inside a folder must be enumerated (listed) first. Otherwise it cannot be accessed. However, we cannot enumerate our VFS. Most of the content of our VFS is fully dynamic. It only exists when it is accessed by a client the first time. Such dynamic content also includes dynamic parameters like the client's locale or the size of a box where the image will be placed. Since we do not know those parameters in advance, we cannot enumerate the VFS's content in advance.
This means, an NSFileProviderReplicatedExtension in its current state isn't a replacement for a "real" VFS and therefore cannot be used by us as a replacement for our current VFS KEXT.
My questions:
Will Apple allow kernel extensions also in future versions of (Apple Silicon/M1 based) operating systems? Or is there at least a clear deadline?
If not, what is Apple's officially suggested replacement for KEXT based VFS solutions?
Will the API of an NSFileProviderReplicatedExtension be improved to behave like a "real" file system so that above mentioned flaws will no longer be an issue?
Many thanks for any answers or comments!
Best regards,
Michael
Will Apple allow kernel extensions also in future versions of (Apple Silicon/M1 based) operating systems? Or is there at least a clear deadline?
Apple doesn't really give timelines, and they also occasionally break promises of support.
However, this sort of hard API deprecation and removal usually is done as part of a major release, so you will typically get deprecation notice for it at WWDC one year, users might start seeing deprecation notices when the .0 of the OS release ships at the earliest, and sometimes the .3 or .4 revision. Then you'll typically be told at the next WWDC that the API is blocked in the upcoming release, so by that point you should have implemented a replacement.
If not, what is Apple's officially suggested replacement for KEXT based VFS solutions?
As far as I'm aware, NSFileProviderReplicatedExtension is currently the only one.
Will the API of an NSFileProviderReplicatedExtension be improved to behave like a "real" file system so that above mentioned flaws will no longer be an issue?
Other than via beta SDKs, Apple generally doesn't pre-announce future APIs.
My advice:
File issues for each of the file provider shortcomings you are hitting using Feedback Assistant. (Radar)
File an "enhancement request" feedback issue with Apple for a "real" file system API replacement for the VFS KPI.
If your vfs kext is critical to your business/product, I suggest additionally asking Apple's DTS via a TSI what they recommend for your situation. Reference the feedback IDs of the issues filed, otherwise they will recommend that you file issues.
I am quite confused as to the proper way of distributing Bonjour as a part of a Windows application that would publish a service for a client iOS app.
No matter how much I google around, I cannot find a clear how-to guide. It would be great if someone could provide guidelines.
The main reasons of my confusion are:
Is it mandatory to distribute the entire bonjour Win SDK as a part of my Win application?
Since Apple provides source code to build mDNSResponder.exe, is it sufficient to only distribute such file along with dns-sd.dll?
What is the intended purpose of providing sources for mDNSResponder.exe otherwise?
What is the recommended way to handle the possibility of having Bonjour already installed on the system?
Also, where can I find the latest Bonjour SDK (3.x I guess?), I can only find 2.0.4. Is it only accessible if I am enrolled in the OSX developer program? (I am enrolled in iOS developer program for now.)
Many thanks.
This is information I gathered from various sources, including communications with official Apple support. I report it in the way I believe to be accurate, I hope it can be useful (no liability assumed!).
For Bonjour-enabled Windows application you have basically two main options:
Bundle the Bonjour Installer with your application (which is not the Bonjour SDK, the SDK if for your own developer use only).
If you choose to do so, the Bonjour installer must be called from your own installer during the installation process. The possibility of Bonjour being already installed in the system is totally handled by the Bonjour installer.
And here come some bad news: you must include de Bonjour Logo on your physical distribution medium (like a DVD cover sleeve) according to the Apple guidelines specified in the Windows Bundling Agreement, and you need Apple approval before distributing your product.
Do not bundle. I.e., do not distribute Bonjour with your application but simply use it if already present in the system. If you do not distribute Bonjour in any form the whole Windows Bundling Agreement simply does not apply. You application should search for the dnssd.dll and load it dynamically if found.
Consider that most of Windows users would have Bonjour already installed due to the fact that some popular apps use it (for example iTunes and Skype).
While the source code of Bonjour is released under an open-source library (Apache License, Version 2.0) this does not require Apple to do anything. In particular, they do not need to document how you'd use this license.
The license allows you to use and adapt Apple's source code, including its copyright, but not including its trademark "Bonjour(TM)". Since this is the standard Apache license, you don't have the requirement either to show the trademark.
So, to answer your questions:
No, you can build your own version of Bonjour from source and use that under the Apache license. You can't call it Bonjour, but why do you need a name in the first place? "mDNS" would be a reasonable choice, possibly prefixed with your trademark.
It seems sufficient to distribute the DLL and EXE. Arranging how they find each other might benefit from some tailoring, so your own build of Bonjour doesn't clash with Apple's.
(I won't speculate on Apple's motives)
The design problem here is that Bonjour acts as a system service, and services are inherently singletons. If you install it unmodified, Apple wouldn't be able to install its own build. That's not a legal problem, probably, but it is a bad customer experience. Installing your own build as a distinct service would avoid the clash, allowing both versions to co-exist.
(Resource request, off-topic)
I'm looking for a desktop publishing platform for Mac, Windows, and Linux that is closely tied to PhoneGap in terms of the concept. I know that there's Titanium for Desktop (TideSDK?) but as far as I've used it before, it requires the end-users to download a big 70mb-ish runtime file once. What I liked about PhoneGap is that it doesn't require any of that (it works out of the box). I'm looking for something similar, only, instead of being meant for the mobile development, it 's targeted at desktop application development.
Perhaps I failed to mention it but if you are not aware of what I'm specifically talking about, I'm talking about an environment of sort that will let me code via an HTML base and output a native for said platforms. Both TideSDK and PhoneGap does this.
I would highly recommend giving TideSDK another chance, I have developed large, data driven applications on it in the past, and deployed to OSX and Windows and have personally been very satisfied with it. Also, it is now an open source project managed and maintained by a very good team with some oversight and help from Appcelerator (the original creators).
Theyre are two benefits to TideSDk as I see it:
License - TideSDK is open source licensed under a liberal Apache 2.0 license. As opposed to QT which is under the restrictive GNU Lesser Public, and commercial license.
Power - TideSDK allows you to leverage native API's (like phonegap) but access them in your favorite programming language (well, choose between Ruby, PHP, and Python). Your only options with QT are C++.
As for what you said about the 70MB runtime, this is not true, I built the runtime in with my last project, and the binary I gave to my clients (OSX) was only 15.3MB.
Hope this helps you come to a decision.
There is a way to run a PhoneGap HTML5 App on the Desktop with the help of Adobe AIR like described here: http://www.tricedesigns.com/2012/02/17/repurposing-phonegap-apps-as-desktop-apps/
But I am also looking for a less bloaty approach. Maybe based on Xulrunner/Prism/WebRT thing (or Chrome).
Tidesdk is the easiest, xml file is almost identical to the phonegap, provides powerful api and the best part you can package your app with runtime. I think you should stick to tidesdk.
I was looking for the same and found this implementation for windows ony: https://github.com/davejohnson/phonegap-windows
I did not tried it though.
If a particular piece of software is made to be run on one platform and the programmer/company/whatever wants to port it to the other, what exactly is done? I mean, do they just rewrite linux or windows-specific references to the equivalent in the other? Or is an entire rewrite necessary?
Just trying to understand what makes it so cost-prohibitive that so many major vendors don't port their software to Linux (specifically thinking about Adobe)
Thanks
this is the point of a cross-platform toolkit like qt or gtk, they provide a platform-agnostic API, which delegates to whichever platform the program is compiled for.
some companies don't use such a toolkit, and write their own (for whatever reason - could well be optimisation-related), meaning they can't just recompile their code for another os.
There are also libraries available that ease, at least on a specific area, the port of Windows API calls to Linux. See the Windows to Linux porting library.
In my experience, there are three main reasons why it's cost-prohibitive to take a large existing program on one platform and port it to another:
it has (not necessarily purposely) extensively used some library or API (often GUI, but there are also plenty of other things) that turns out not to exist on the other platform
it has unknowingly become riddled with dependency on nonstandard features or oddities of the compiler or other tools
it was written by somebody who didn't know that you had to use some oddball feature to get things to work on the other platform (like a Linux library that isn't sprinkled with the right __declspec directives you need for a good Windows DLL).
It's much easier to write a cross-platform app if you consider that a design goal from the start, and I have three specific recommendations:
Use Boost—oodles of handy things you might ordinarily get from platform-specific APIs and libraries, but by using Boost you get it cross-platform.
Do all your GUI programming using a cross-platform library. My favorite these days is Qt, but there are other worthy ones as well.
Build and test every day on both platforms, never provide an opportunity for the code to develop a dependency on only one platform and discover it only too late.
There are many reasons why it may be very difficult to port an application to a different platform, most often it is because some interfaces the application uses to communicate with the system are not available, and one either has to implement them on their own, port a library your application depends on, or rewrite the application, so that it uses alternative functions. Most languages today are very portable across hardware architectures and operating systems, but the problem is with libraries, system calls and potentially other interfaces the OS (or platform) provides. To be more specific:
Compilers may differ in their configuration and the standard functions they provide. On Windows the most popular compiler for C/C++ is Visual Studio, while on unix it is gcc and llvm (in combination with the standard library glibc or BSD libc). They expect different flags, different forms of declaration, produce different file format of executables and shared libraries. Even though C and C++ have standard libraries, they are implemented differently across platforms. There are some systems whose aim is to make compilation portable, such as Autotools, CMake and SCons.
On top of standard libraries there are additional functions OS provides. On Windows they are covered by win32 API, on unix systems these are part of the POSIX standard, with various GNU, BSD and Linux specific extensions, and there are also plain system calls (the lowest-level interface between applications and the operating system). POSIX functions are available on Windows via systems such as cygwin and mingw, win32 API function are available on unix via Wine. The problem is that these implementations are not complete, and often there are minor (but important) differences.
Communication with the desktop system (in order to make a GUI interface) is done differently. On Linux this might be the X Window System (together with freedesktop libraries) or Wayland, while Windows has its own systems. There are GUI libraries which try to provide an abstract interface for these, such as Qt, GTK, wxWidgets, EFL.
Other services the OS provides, such as network communication may be implemented differently. On Windows many applications use .NET libraries, for which there is only limited support on unix systems. Some unix applications rely on Linux-specific features such as systemd, /proc, KMS, cgroups, namespaces. This limits portability even among unix systems (Linux, BSD systems, Mac OS X, ...). Even .NET libraries are not very compatible across different versions, and they might not be available on an older version of Windows or on embedded systems. Android and iOS have different interfaces entirely.
Web applications are usually the most portable, but HTML5 is a live standard, and many interfaces may not be available yet in some browsers/web engines. This requires the use of polyfills, but it is usually much less painful than the situation with "native" applications.
Because of all of these limitations, porting can be a pretty hard work and sometimes it is easier to create a new application from scratch, either specifically for the other platform, using cross-platform abstraction libraries/platforms (such as Qt or Java), or as a web application (potentially bundled in something like Electron). It is a good idea to use these from the beginning, but many programmers choose not to because the applications tend to look and behave differently from "native" applications on the platform, and they might also be slower and more restricted in the way they interact with the OS.
Porting a piece of software that has not been made platform-independant upfront can be an enormous task. Often, the code is deeply ingrained with non-portable APIs, whether 3rd party or just OS libraries. If the 3rd party vendor does not provide the API for the platform you are porting on, you are pretty much forced into a full rewrite of that functionality, or finding another 3rd party that is portable. This only can be awfully costly.
Finally, porting software also means supporting it on another platform, which means hiring some specialists, and training support to answer more complex queries.
In the end, such a process can be very costly, for very little additional sales. Sadly, the decision is easy: concentrate on new functionality on your current platform that you know your customers are going to pay for.
If the software was written for a single OS, a major rework is likely. The first step is to move absolutely all platform-specific code into a single area of the code base; this area should have little or no app-specific stuff. Then rewrite this isolated portion of the code for the new target OS.
Of course, this glosses over some extremely major implications. For instance, if your first version targeted the Win32 API, then any GUI code will be heavily tied to Windows, and to maintain any hope of preserving your sanity, you will need to move all that code to a cross-platform GUI framework like Qt or GTK.
Under Mono, you can write a C# Winforms program that works on both platforms. But to make that possible, the Mono team had to write their own Winforms library that essentially duplicates all of the functions of Winforms. So there is still no free lunch.
Most software is portable to some extent. In the case of a C app - there will be a lot of #ifdefs in the area, apart from path changes, etc.
Rarely windows/linux version of the same software don't share a common codebase - this would actually mean that they only share a common name. It's always harder to maintain more codebases, but I think that the actual problem with porting applications has little to do with the technical side and a lot with business side. Linux has much fewer users that Windows/OSX, most of them expect everything to be free as in beer or simply hate commercial software on some religious grounds.
When you come to think about it - most open source software is multiplatform, no matter what language was used to implement it. This speaks for itself...
P.S. Disclaimer - I'm an avid supporter of Free and Open source software, I don't want to insult anybody - I just share my perspective on the topic.
Some of the requirements (restrictions) for such a ui framework/toolkit are:
No single vendor lock down
Ability for real time data visualization
Good initial widgets
Good dash boarding capabilities
cross platform
Good development/debug environment
No flash
It's a pity you can't/won't use Flash. Else I could really recommend Adobe AIR. It has a good editor (Flex Builder built on Eclipse), a good component framework with many out of the box components, charting components set, ability to communicate with many different protocols (and you could write your own protocol implementation), cross platform, runs in the AIR runtime and not in the browser, file IO, ...
I wouldn't pass over Flex/Air (Flash) without a closer consideration but here are a few others I have come across:
wxWidgets
GTK+
Qt
There is also a slashdot post with links to some tookits I haven't heard of. I'll add their recommendations here:
GLUI, an OpenGL-based GUI
Whisper, a Mac/Windows application framework
WxWindows, a framework which supports Windows 3.1/95/98/NT, and Unix with GTK/Motif/Lesstif, and MacOS
YAAF, Yet Another Application Framework, offering suport for Macintosh OS, Windows 95 and Windows NT, and X Windows
CPLAT, a framework for developing MacOS and Windows (Linux soon) applications
Ardi's Carbonless Copies technology, which is a portable rewrite of much of the MacOS API
For general information:
GUI Toolkit/Framework Page
PIGUI FAQ Page
C++ User's Journal PIGUI Page
I might suggest Mozilla XUL, but it has some drawbacks:
No really good development / debug environment (although there are tools and debuggers; they are variable)
You are locked into a vendor, but it is Mozilla.
It is very easy to use though and allows you to reuse your web Javascript skills for a rich-client app.
There's also Java of course. It satifies all your requirements AFAICS.
Plenty of custom charting controls, which are things you will struggle to find for GTK/WxWindows/$other_small_userbase_framework.
If you dont like Swing(its come a long way - Metal is dead, long live SystemDefault L&F!), there are options like SWT or even QT bindings for java(QTJambi).
For C or C++ go QT, its APIs are really nice.
For RCAs check out Eclipse RCP. For RIAs, you might be interested in OpenLaszlo. It's a rich internet platform that can compile both to Flash and DHTML.
http://www.gnustep.org/
"GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components."
Portable to: Windows, BSD-based systems, Linux-based systems, HP/UX, , Solaris, Sparc, GNUstep Solaris 10 U2 vmware appliance, OpenSolaris, others.
I recently made a pretty complete list here: http://commadot.com/ria-frameworks/
ExtJS is probably my favorite and we use that at work. I think it satisfies your list. Otherwise, there are a bunch of other possibilities on that page.