I have downloaded spotify API and am trying to build the example code using libspotify on Windows. The build environment seems to apply only for Mac/Linux world (atleast the Makefile seems to suggest that and there are no Visual Studio project files). Any one has any luck in building the sample code on Windows ?
Even the basic stub example uses pthreads which is not available on windows. Since all their examples assume a POSIX compliant OS (which windows is not) I'm afraid you will not be able to build them on windows (natively). If you want try then take a look at Cygwin.
However, you can still use the include header file and the provided dll/lib to link against and develop applications. The library calls made in the examples are still valid - just not the examples themselves.
Related
We were previously using a NPAPI plugin to execute some commands on windows system from our website. Now that NPAPI is gone, we are trying to port things to PPAPI or NaCl but there seems to be a lot of issues.
Google seems to provide vs_addin for Visual Studio 2010 and Visual Studio 2012, but it always give error when trying to compile the code as Pepper Plugin during linking phase. The error is something related to _MSC_VER mismatch as the object files in PPAPI libraries seems to be having that version as 1800 where the value is supposed to be 1600 or 1700 for VS2010 and VS2012 respectively.
To get around this issue, we tried downloading a old copy of pepper, but its not available from SDK. somehow we found the pepper_25 version on the internet, but then it seems that postmessage function is not available for plugins.
Tried using scriptableobjects but looks like the support for them was actually removed long back sometime in chrome 13?
If we are trying to build it as NaCl plugin, then we don't get access to windows functions like ShellExecuteA as the corresponding libraries are not included. Trying to include libraries only results into more errors.
This might be possible by having an extension with native messaging, but again a website cannot directly interact with an extension unless the extension places a content script on the webpage. As the users of the website, can install the website on their own systems, we have to scan and add content script on all the web pages which doesn't seem to be a nice option as it can result into system slowdown.
TLDR:
Now the question is, how can we build a chrome plugin that can execute commands on windows?
Thanks & Regards
The short answer is, there is (by design) no way to distribute a plugin that has access to the native platform APIs. The VS addin has a way to compile one, but it will only run on your local machine. You can develop a NaCl or PNaCl plugin, but it is limited to NaCl's APIs plus Javascript. If you need native APIs, then you might want to look at native messaging.
I have written a code in visual c++ , which is a sort of GUI used in virtual com PORT connection. However , i need to run that code in linux so that i can make it an open source. Since , visual c++ doesn't work in linux, I need to find out some alternatives.
So, please me what all alternatives I have
Thanks for your valuable time..!!
i need to run that code in linux so that i can make it an open source.
No, you can license code as open source without it running on linux.
If you simply want your code to run under linux you need to learn how to port from VC++ to Linux/GNU. It's not simply a matter of re compiling it.
See the following URL for advice and google search for more if required: http://www.johndcook.com/blog/2008/05/29/porting-visual-c-code-to-linuxgcc/
In my experience you can get a looooong way with
http://www.winehq.org/docs/winelib-guide/winelib-toolkit
winemaker (doing things as making all your includes case-sensitive correct on Linux)
winegcc (linking to the winelib runtime libs so you can have _WinMain and stuff like that just work)
Of course there are libraries that simply don't exist. Also, installing an SDK can be daunting; winetricks.sh is very helpful in that department. Also, you can consider 'XCOPY' deploying the SDK into your linux build tree and working with that;
This has successfully let me cross compile MSVC projects linked with 3rd party windows libraries in the past. Note minor incompatibilities due to having slightly different linkage semantics with gcc/GNU ld by default; expect this to affect areas like RTTI and exceptions thrown across DLL boundaries).
YMMV
Edit I want to confirm the fact that you can have perfectly valid opensource code for windows only, and you can build it using Visual Studio too. If you want to be nice to your (prospective) contributors, make sure you only depend on Visual Studio Express C++ (not MFC, e.g.) but hey, that's really up to you!
which is a sort of GUI used in virtual com PORT connection
This will be probably hardly portable (because of the BIG differences how virtual ports and GUI are handled in linux and windows - unless you used some cross-platform library already in Windows).
You can release your code as OpenSource for Windows only.
I want to make an easy to deploy Windows application and was was wondering which programming systems can create totally self contained Windows .exe files?
As a plus, if the same can be done with MacOSX and Linux from the same source this would be a bonus. I took a look at Realbasic but they have since abandoned the single .exe concept.
update: i am looking for something that can run from Windows XP up to Windows 7, no matter what version of .NET is installed. Is this even possible?
Delphi compiles to one executable, and generates native windows executables. So no dependencies to any kind of framework. If you use Free Pascal (fpc) and the Lazarus IDE, you could even develop for Linux and Apple from the same source.
If your using external dll's this would become a bit more tricky, but you could pack them up in your resource file and still maintain the one exe property.
Update 2020: since #Vassilis & #Marco van der Voort commented on this, I would like to update my old andswer and add that go is a very good way to make self-contained executables. Even crossplatform compilation is realy simple.
You can certainly do this with C/C++. Technically the runtime libraries are required, but they should already be installed on any windows, mac or linux system.
With .NET you can compile to an EXE, but of course the .NET framework is required. For newer versions of windows it should be installed by default, but on older versions (XP or older?) it may or may not be there. And of course you couldn't expect mono to be there by default on linux or mac either.
For Windows the following languages are viable:
C (MS, gcc)
C++ (MS, g++, Digital Mars)
D (Digital Mars)
Delphi (Embarcadero??? how do you spell that? just trips off the tongue doesn't it?)
Fortran (Intel, Salford Software)
Visual Basic 6 (MS)
Lua (you'll need a special tool to do it, but it is doable)
C#, VB.Net, F#, J#, etc (assuming that you don't mind using .Net technology)
You can use Tcl/tk. The technology you should research is a "starpack", which combines a runtime executable (a starkit) with a platform-specific runtime (a "tclkit") to create a single-file executable. It's remarkable in the fact that it's not just compiled code, but an entire self-contained virtual filesystem that can include images, sound, data, etc.
This same technology works for many platforms from the same code base. The only thing that is different is the platform-specific runtime. You can even "cross compile" in that you can copy the runtime for multiple platforms onto your dev box and then build starpacks for each platform without having to actually be on each platform.
Tcl can do this, especially through producing starpacks. They can be produced for all platforms from the same code. Note that this also includes all the necessary runtime libraries (except for things like the C library, but you don't want to make that static under normal circumstances).
JavaFX 2.2 supports that. It allows creation of self-contained applications targeting Windows, Mac OS, and Linux.
Please follow this link for more information: http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm.
I would recommend taking a look at AutoIt. It is an easy-to-use scripting language that will compile into an exe, so there are no runtimes needed. This would be for windows only though.
http://www.autoitscript.com/autoit3/index.shtml
From the website:
AutoIt v3 is a freeware BASIC-like
scripting language designed for
automating the Windows GUI and general
scripting. ... AutoIt is also very small,
self-contained and will run on all
versions of Windows out-of-the-box
with no annoying "runtimes" required!
c/c++
purebasic
delphi
vb6
i hope this help :)
Here's a good source for a number of basic-like programming languages that build small stand-alone EXEs. Some are cross-platform for Windows and Linux:
www.basic.mindteq.com
You can use Liberty Basic which is easy and cheap, you can easily make stand alone programs for windows but not possible to transfer to MacOS or Linux.
You can do this for Windows with .NET languages using ILMerge
ILMerge is a utility for merging multiple .NET assemblies into a single .NET assembly. It works on executables and DLLs alike and comes with several options for controlling the processing and format of the output. See the accompanying documentation for details.
However:
Currently, ILMerge works only on Windows-based platforms. It does not yet support Rotor or Mono.
QBasic can :-)
I wrote a few command line tools using it!
Have a quick project I need to put together for windows that can have no external references or dependencies; the stalwarts like C are obvious but if you are a .NET developer and need to build something like this very quick what language/tool would you use?
EDIT: Ultimately I want to be able to take JUST the exe produced by the compiler and put it alone on a windows machine and have the app run.
If you're a .net developer, you could consider something like using Remotesoft's Salamander or another similar tool that compiles everything into a single executable (including the framework).
This option lets you develop in .net, but not install the .net framework on your client's systems. If you're deploying on non-MS systems, you can use the Mono's deployment tools to accomplish the same thing for free.
In general, I'd say stick to the tools and languages you know. It's easier to build an installer to install the .net framework then it is to learn a new suite of tools, libraries, etc.
You can do it for practically any language (I'm excluding the obvious C/C++)
You can bundle the .NET runtime into your .exe and write the app in C#
You can write the app in Python and bundle everything into a single .exe using a tool like py2exe. I do this regularly. One can create great-looking and powerful applications with Python and PyQt, bundle everything into a single no-dependencies executable and deploy to users w/o a need to install anything else. The executable is a few MB large (~9 with PyQt), and loads and runs quickly.
Etc.
It's more important which language / environment do you currently know well. Focus on that, because the tools do exist for anything you'd want to use.
Delphi has always been the best product for producing stand-alone .EXEs for Windows. No Microsoft product has ever come near it in that regard.
I think a good allround answer to this is Free Pascal via the Lazarus IDE.
Free Pascal applications are native and dependency-free, and a lot of platforms are supported. Too many to list here! Free Pascal itself is a free and open source compiler.
For better convenience, I strongly recommend using the Lazarus IDE. Now you even get a RAD IDE for cross-platform GUI applications (as well as console), with a sizable set of builtin features, like database support. Really a pretty lovely all-in-one, often underestimated or even unknown, platform that produces self contained, native executables. There aren't all too many of those tools if you think about it. You can even cross-compile from it, for example to compile a GUI application for Linux on Windows, no virtual machines necessary.
One day, I wish .NET Native could get this far, but it is currently far from capable and I'm not sure if Microsoft even intends to go there. Google's Go language is also nice in that it compiles to native cross-platform code, but lacks a GUI library. Python can have its code packaged into executables but it's kind of a kludge and not native code. And so on...
C/C++ would be your language but don't use any fancy libraries like MFC, MSVCRT, etc. or if you do link them statically to your executable.
"No external references" is a bit vague. Are you talking about a deployment solution for an application?
For example, you can use Tcl which supports the ability to create a single file executable that contains both the application code and a virtual filesystem that can contain any other files needed by the application. If your goal is to create a single file that can be deployed without having to install extra files, read up about "starkits" and "starpacks".
If you target a Windows Vista .NET 3.0 is preinstalled,
If you target a Windows 7 .NET 3.5 is preinstalled, if you use no other libraries than the ones included in those distributions then you app will run. Installing .NET isn't really that much work anyway, just ship with the redistributable.
Assembler. Your only dependency is the CPU
Here's a left field answer...
Tcl
combined with starkits, you can create a simple double-clickable .exe with no need for an installer.
the downside, of course, is that it'll be written in tcl.
As an added bonus, you'll be able to port your app trivially to mac or linux (or a range of other odd operating systems)
Do you consider the .NET Framework "external"? If you stick to .NET Framework and use C#, your code should run anywhere the .NET Framework of appropriate version is installed, and you'll only need to deploy your .exe and .exe.config.
It is not possible to run a .NET program without the .NET Framework. If you can't require the .NET Framework to already be installed, then you cannot use a .NET program. That's what I meant.
I've no clue what the downvotes are about, but let me try once more to clarify. The original post said:
the stalwarts like C are obvious but
if you are a .NET developer and need
to build something like this very
quick what language/tool would you
use?
The answer is that if you are a .NET developer, there is no tool or language you can use for this purpose, as every .NET program requires the .NET Framework be installed. If you need a program that is entirely independant, then don't use .NET. As others have replied, you can bundle .NET into your exe. You can also have .NET installed with your application, if you're willing to ship a .MSI file and not just your exe.
But, by definition, a .NET program cannot be independent of the .NET Framework.
Can I write and compile code for this on XP? We have utilities for our apps that use activesync and now will be adding Vista/WMDC - and I was hoping I don't have to have another development OS (Vista) to develop and compile on.
I have not seen much documentation for the API for WMDC - can someone point me to some useful references for it?
hummm... ActiveSync, so Windows Mobile am I right?
all you need is the SDK and Visual Studio (well, this last you don't need cause you can compile everything using the command line, but, very nice to have for such applications)
there are plenty of SDKs for what you need, for example PocketPC, Windows Mobile, etc...
the sdk contains everything you need to build, compile and deploy an application, works fine on windows XP (what I currently use) and with ActiveSync, you can even debug the application in the device ;)
added:
unfortunatelly there is no SDK for the WMDC. The only thing you have are the 4 libraries in the %WinDir%\Windows Mobile. It contains 4 libraries named as "Microsoft.WindowsMobile.*.dll". Additionally you don't get any documentation on the libraries themselves which makes it hard to use.
As you use the RAPI (I think by using the OpenNETCF library) most of the applications shall still run under WMDC as the included RAPI seems to be backward compatible. The included RAPI itself is in a new version.
taken from MSDN forum
I hope this helps for the moment.