zlib for WinRT? - c++

I require zlib library for the development of Windows Store app.
Has anyone converted Win32 zlib project to WinRT yet?
Can anyone please describe the steps to convert the existing win32 static lib project to winRT?


Visual C++ is already a supported language for WinRT development, if you wan't to use zlib, just compile it together with your solution. There is nothing that is preventing you from reusing standard ISO C and C++ libraries from within the WinRT, if you are using the C++ language, you might have to expose certain aspects of your library as WinRT Components but only if you need to interface with facilities like XAML or other WinRT languages but that should be a walk in the park. Not something which is tremendously difficult to do.
The whole point of supporting C++ in the WinRT is to allow an existing ecosystem of largely native applications to be ported to the Windows Store. zlib is not an exception. Non-standard ISO C and C++ such as sockets are not supported but there you have alternatives that you can plug-in to, just check that the library you're using has some kind of portability support.


WinRT is very limited with regards to C library functions which are present. What this means is that virtually all cross-platform C libraries are (AFAIK, I'm not a WinRT dev) unusable for that target.
For the case of zlib, there is an alternative: see this question
EDIT: to clarify what I'm saying above, I dug up a list of all CRT functions that are absent for WinRT, which you can find here. As long as zlib or any other C library does not depend on these function calls, you should be able to use the WinRT tools to build that C library. I even found a project file for zlib on winrt by the Ogre team here, not sure how useful it is to you.


You could take a look into this WinRT (Un)Zip component. Its used in production code already.
See the unit tests inside on how to use the component. It compiles on all WinRT architectures including ARM. It has no custom asm for ARM though.

Related

Is there any C++ counterpart for Borland C++ Builder 5's dir.h header?

I need to adapt a file written in Borland C++ Builder 5 to be usable in MS Visual Studio 2022. One of the files heavily utilizes the dir.h library, which, as far as I can tell, is a C library exclusive to Builder. The source files are available, however they have a lot of dependencies and, as I've mentioned, are written in C. I have searched the Internet for a substitute, unfortunately to no avail. Does a similar library exist for C++? Or do I have to re-write the file (which is pretty big) using e.g. std::filesystem?

The functions in dir.h are mapping quite direct to Win32 API calls of fileapi.h. You could use this header for a quick port.
For a modernization, it might be the best idea to re-write the code using std::filesystem. There is hardly any sensible C++ library with such a C-like API.
Well, there are the modernized Embarcadero API-calls in System.SysUtils.hpp, but they are still no modern C++, and they are only available in their ecosystem.

Targeting C++/WinRT with CMake

I'm working on compiling a CMake-based third party C++ shared library for use within a UWP application.
Per documentation on MSDN, I've been building with the flags -DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0. While this is very useful for flagging any disallowed or unavailable APIs, my understanding is it sets the /ZW flag, which enables C++/CX.
This is mostly fine except for some minor points (for example: the library deals with networking, and makes use of the variable name interface which is apparently a reserved keyword by C++/CX).
More fundamentally, since I'm building a standard C++ library, I'd rather use standard C++ (C++/WinRT). Is there a way to tell CMake to target the WindowsStore SDK but without carrying along C++/CX?

This is a fallacious question. Underlying problem has nothing to do with C++/CX or UWP -- Including windows.h pulls in combaseapi.h which has #define interface __STRUCT__. And so, MSVC treats interface as the struct keyword.
[The original, incorrect answer cited interface being a reserved keyword on MSVC per https://learn.microsoft.com/en-us/cpp/cpp/interface?view=vs-2019. This is also not correct, as pointed out in the comments]

Sample code for Anymote in C++ version?

Can anyone tell me where to find the resource just like this one
(But I hope this is for C++ !!)
There is a dynamic library under google tv chrome extersion here
This hyperlink tells us how to go Anymote by call C++ libraries through NPAPI under javascript.
Maybe I can follow this page to go under C++ version.
Unfortunately, the arch of these libraries is i386 (or x86_64).
My project build under the other platform (ex: arm), so I can't call these libraries directly. Orz

There is a cpp Anymote library implementation and some unittests which exercise the library APIs at:
http://code.google.com/p/anymote-protocol/source/browse/#hg%2Fcpp
Apart from that there is no open source Anymote client library in C++.

C++ API for multiplatform development

I want to learn C++ to work on various platform (primarily, Linux and Windows). I have come across few solutions like the Boost C++ library, Qt toolkit, etc that can be used to write programs which will compile on both the platforms.
I want to know from the community, what type of library would you refer to use and if any of you had experience with this type of multi-platform programming before.

Use Qt and the BOOST C++ Libraries. They are both free and very high quality. Also, at least for me personally, I found Qt to be much more straightforward, easy to learn, and simpler than wxWidgets.

It depends on what you're going to do. If you need to write a strictly command-line utility to process text, Qt or wxWidgets might be inappropriate. What exactly is your application field?
Scientific computing is my field of expertise. in which these are great multi-platform APIs:
Parallel Programming
MPI
OpenMP
Numerical Algorithms
BLAS (via Boost's C++ wrappers for BLAS)
LAPACK
LINPACK
PETSc
High-performance file I/O
HDF
NetCDF
Visualization
Visualization Toolkit
If you're doing viz work, a GUI can be great. Try one of the following multi-platform APIs:
Qt
wxWidgets
GTK
The plugin framework for the parallel viz apps:
Paraview
VisIt

You didn't specify any partuclar type of library, but if you just want a general recommendation I have to say wxWidgets is an excellent cross platform GUI library.
It has some great features like rendering the GUI in the native look and feel of the operating system it's running on, and is not particularly hard to learn. It offers a single API for GUI writing across Win/Mac/Linux, plus others like WinCE.
I highly recommend it for cross platform GUI work.
Check it out at http://www.wxwidgets.org/

I highly recommend Qt if you are doing any sort of GUI work; it's even quite useful if you aren't, since it has well-thought out networking/database/container/etc APIs also. It's a very well designed API and very easy to use.

The core C++ standard and the STL are pretty much cross platform already. Its usually only the GUI and hardware access stuff that requires libraries.
I have used GTK+ as a GUI toolkit and it's pretty good too, although you need to install glib and some other stuff on windows.
RtAudio is nice for cross-platform audio I/O.
The low level networking/sockets stuff is largely the same between windows and linux, you could write a very lightweight layer yourself to handle any differences. I don't have any experience with higher-level networking libraries.
I also like the SFML (simple fast media library) for cross-platform 2d graphics type stuff. It's very nice indeed.
I would suggest, however, that if you are just learning c++ then you're probably better off not looking at Boost (or indeed any of these toolkits) until you've got your head around the basics - by writing a couple of basic console applications, for example.
If you want to learn c++ only so you can do multi-platform dev, be aware that there are many other languages and associated toolkits that may be more suitable, depending on the app you're writing.
Without knowing the type of app you're planning on developing, its hard to say whether C++ (or C or Python or whatever) is the best idea. Personally, I generally turn to Python + PyGTK for crossplatform GUI apps and C# for windows-only apps. You can always plug C/C++ in to replace any components that are running too slowly.

Like other posters have mentioned, I would recommend Qt and Boost for cross-platform development. I had tried gtkmm which is a thin C++ wrapper around GTK+, but was not satisfied with it partly because it's not a native C++ library and documentation is poor compared to Qt. Besides that, Qt comes with very nice development environment including a easy-to-write make alternative qmake and a gui designer.

I for are going to do some cross platform development in C++ an you don't want to maintain different build systems (Makefiles, Visual Studio Projects, etc) there are several tools out there that can help you.
The one I personally use is CMake. It supports Linux and Unix Flavours, Windows and Mac/OS. Actually several open source projects, like KDE, use it. But there are others options like for instance Scons.

Standard C++ programs will compile and be portable, i.e. work across a large range of platforms. To be sure that you are keeping code clean, your best bet is to get a few different compiler and check your code with all of them, while enforcing full standard conformance (with options like -std= for g++, for example) and writing warning-free code (with options such as -W -Wall -Werror for g++, which emits errors instead of warnings). The exact choice of compilers is up to you, but if you're mostly learning, I advice using:
g++ (free, open source)
the Intel compiler (free for noncommercial use on Linux)
maybe MSVC++
Also, if you really have to use compiler- or target-specific code in your projects, be sure to abstract it so it's all gathered in one place, and hidden from the rest of your code.
Now, if you want to use more than the STL, then you need to choose your libraries by considering the range of compilers and platforms they're tested against (and, if the documentaiton doesn't state it, it's a bad omen). The detailled choice depends on what exactly you want to do, but Boost (as a robust, wide-ranging library for many common issues) and Qt (a recent version; for GUI programming) are good choices. For numerical, scientific programming, BLAS/LAPACK (and/or their parallel versions, BLACS and Scalapack) are very widely used, directly or through wrapper C++ classes as can be found in Boost (for BLAS); a good FFT library is also often needed (FFTW is good if its GPL licence is not a burden for you).

Using Component Object Model (COM) on non-Microsoft platforms

I'm regularly running into similar situations :
I have a bunch of COM .DLLs (no IDL files) which I need to use and invoke to be able to access some foreign (non-open, non-documented) data format.
Microsoft's Visual Studio platform has very nice capabilities to import such COM DLLs and use them in my project (Visual C++'s #import directive, or picking and adding them using Visual Basic .NET's dialogs) - and that's the vendors recommended way to use them.
I would be interested into finding a way to use those DLLs on non-microsoft development platforms. Namely, using these COM classes in C++ project compiled with MinGW or Cygwin, or even Wine's GCC port to linux (compiles C++ targeting Win32 into binary running natively on Linux).
I have got some limited success using this driver, but this isn't successful in 100% of situations (I can't use COM objects returned by some methods).
Has someone had success in similar situations ?

Answering myself but I managed to find the perfect library for OLE/COM calling in non-Microsoft compilers : disphelper.
(it's available from sourceforge.net under a permissive BSD license).
It works both in C and C++ (and thus any other language with C bindings as well). It uses a printf/scanf-like format string syntax.
(You pass whatever you want as long as you specify it in the format string, unlike XYDispDriver which requires the arguments to exactly match whatever is specified in the type library).
I modified it a little bit to get it also compile under Linux with WineGCC (to produce native Linux elf out of Win32 code), and to handle "by ref" calls automatically (stock disthelper requires the programmer to setup his/her own VARIANT).
My patched version and patches are available as a fork on github:
https://github.com/DrYak/disphelper
And here are my patches :
patch for single source
patch for split source

The problem with the Ole/Com Object Viewer packaged with Visual Studio and Windows SDKs is that it produces a broken .IDL out of the .DLL, which can't further be compiled by MIDL into a .H/.CPP pair.
Wine's own reimplementation of OleViewer is currently unstable and crashes when trying to use those libraries.

I think you should be able to use the free tool Ole/Com Object Viewer to make the header files.