I'm about to write an app that should work under OS X and Windows XP/Vista/7. The app will require a database engine. Can someone suggest one that can do the following:
Be compatible with Windows
Be compatible with OS X (and preferably with iOS)
Preferably be available by default in those operating systems, or require minimum installation.
I understand that all three items may be hard to come by. So just curious, whatever is available?
My favorite is Sql Lite: http://sqlite.org/
It requires no installation, and is a small binary.
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#.
I have Developed an Windows Application in visual Studio 2010 by integrating Sql Server Express using prerequisites that works fine in all windows Operating System.But my application should also work other than Windows Operating Systems like MAC,LINUX . We didn't tested other than Windows Operating system.so we have an doubt weather MAC and LINUX Supports Windows Application with Sql Express.
Anything that depends on windows GUI will nor work under Mac or Linux without a lot of advance preparation. If cross platform use is your goal, you're probably starting with the wrong set of tools.
You do not. YOu goto a mirror and ask the person on the other side why he did not bother to check system requirements before choosing technologies.
.NET will in 2015 run on Mac and Linux (outside Mono, MS puts the whole stack offically on those platforms). But SQL Server - no. Sorry. Whoever choose that should learn to read system requirements. I you drop SQL Server (and allow alternatives) and can wait for .NET 5.0 - then yes, that is doable.
At the moment your only rel way to do that is via virtualization. WINE may work - not sure, but definitely not something I would support. Full windows virtualization will work but is similar to installing another OS.
If that was a professional development, someone obviously did not consider "knowing what I do" to be part of the job requirements. Always funny.
1) Linux, Rewrite in C++, using KDE or GNOME for front-end, use something like MySQL for back-end
2) OSx, Rewrite in objective C, using MySQL for back end
3) Windows, Keep front-end but change back-end to MySQL
note MySQL used on all SQL servers to keep some of the development the same.
you could rewrite front end using something like Java so it will work on all platforms but i'm not a java developer so i'm not sure what is involved.
My best recommendation is that you find a different line of work as you don't seem to understand the first thing about development...
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.
We need to build a C library on various environment like (suse x86, suse itanium, solaris, HPUX, IBM AIX) with different compiler options(like compiler flags, 32bit or 64 bit, static or dyanamic, endianess etc). Currently we are building it on around 200 build machines. We are having an efficient makefile but still we need to login to various machines and doing FTP to take the code and then doing make and then again transferring libraries. Then we need to keep all 200 platform libs in one release machine.
Our intension is to reduce the effort of logging in to different machine manually for triggering build, what is the best way to do it?
One way to automate this by writing an expect script on one linux machine which will do login to all 200 machine, triggering build and taking back the libs and keep it on place.
Is there any other way is there which will takes less effort when compared to writing expect scripts for 200 builds? For example we need to build around 50 Vxworks platform, for that we are having tornado packages(cross compiler) in only one windows machine which will do all 50 platforms. For this we have written one click automation scripts(small script which doesnt require to login to 50 machine).
Similarly if cross compilers available for all *nix machine (suse, solaris, hpux, ibm aix, etc) compilers we can install all that in one machine(either linux or windows). Then we can write a script to automate all 200 builds in one machine without writing scripts for remote login or ftp.
Or is there any other easy way to handle builds in multiple *nix platforms?
Would Jenkins be a possibility for you?
It's becoming increasingly popular beyond Java projects (C/C++/C#). From what I understand, Jenkins would be a fit.
Take a look at the GNU AutoTools. Everybody knows how to use their output (the typical ./configure; make; make install dance), no strange requirements on the target, has extensive machinery to handle operating system vagaries. It's learning curve is quite steep, though.
Can anyone weigh in on the speed, responsiveness, reliability and flexibility of the following two options:
Using RDP to remotely access a Windows machine from a Windows machine
Using NX to remotely access a Linux machine from a Linux machine (or a Windows machine if not much different)
The application I would run on either guest is the same. If the approaches perform about as well as each other, I'd prefer the second for security reasons pertaining to Linux. However if NX is going to be significantly slower, I may reluctantly go with RDP and Windows for the time being.
Please mention the variety or varieties of NX you have experience with (FreeNX, NeatX, x2go, etc.) Thanks!
The short answer is that it really depends on what the application does, NX can be quite efficient with applications that draw using X11 primitives, much less so for graphical/video.
As for the different NX varieties: FreeNX is unmaintained, so is NeatX, and you forgot winswitch.
When it comes to performance, which implementation you choose makes no difference since they all rely on the same NX libraries for remoting the display (assuming they do not misconfigure the link parameters), the only thing they change is the way they manage the sessions (the UI) and the client-server protocol used for the GUI app (which has no impact on performance).
It is now at least as efficient as RDP and NX so you may also want to give xpra a go.