In our project, we have a lot of ActiveX controls written in VB6. On big (x86) computers it works very well. These controls are hosted on website. And mobile users also wants to use it.
So is there any possible solution to recompile/cross-compile an .ocx and make .cab file to works under ARM architecture?
Or maybe I can emulate x86 architecture on mobile phones/PDAs?
Mateusz
There is no way to take a control written in VB6 and run it on a device with an ARM processor (via cross-compiling, emulation or otherwise).
Your best route is to rewrite your application in something that targets both x86 and the ARM mobile platform of your choice (one of java/j2me, .net framework/compact framework, flash, C/C++, etc) or just make your application run at the server and expose it via the web
Related
How can I use glib in Windows Phone 8 / 8.1 or Windows 10 Mobile C / C++ application? Is it possible?
Should I somehow try to use autotools or should I create Visual Studio project and add all the files needed?
Windows Store apps rely on Windows Runtime and run in sandboxed environment. GLib provides the core application building blocks for libraries and applications written in C. It provides the core object system used in GNOME, the main loop implementation, and a large set of utility functions for strings and common data structures. For Winows Store apps, there are some limitations or restrictionsin security, inter-app communication, low-level system functionality, usable APIs, etc.. If you wanna port your app based on Glib to Windows Store app, you'd better leverage the power of Windows Runtime and other high-quality third party libraries specific to Windows Store.
I have a decade old MFC VC++ desktop application. Beauty of the application is it works from Windows 2000 to Windows 7, in more than 15 languages. Its multithreaded with IPC and SSL on top of winsocket.
Lately i am reading that win Windows 8 Metro style we will not be able to run the existing application. Does that mean Windows is heading towards killing VC++ or MFC?
Is there a possibility of me keeping same code base for all windows versions? Do I have alternative APIs for winsock and MFC? Is it compulsory to write the app in HTML5?
Lately i am reading that win Windows 8 Metro style we will not be able
to run the existing application
I find it easier to think about things in terms of the Windows Runtime (WinRT). The ARM based Windows 8 systems will only support WinRT programs. The x86 based Windows 8 systems are capable of running both WinRT programs and existing Win32 programs.
There is an implication (or possibly an assumption?) that all Metro style applications are WinRT applications. Certainly WinRT is intended for use in building Metro style applications. I could imagine building traditional Win32 applications that looked like Metro apps - big square active tiles, an application surface that stretched to the left and right of the visible desktop etc. I'm not sure those would really be considered "Metro style" apps even if they were built in the same style as a Metro app.
Existing applications will not run on ARM based Windows 8 systems and will not run in the non-Desktop part of the x86 based Windows 8 systems. They will run in the desktop part of the x86 based Windows system. That's where Visual Studio runs, that's where PhotoShop will probably run, that's where all the programs that currently run on Windows 7 will run.
Does that mean Windows is heading towards killing VC++ or MFC?
Absolutely not. MFC applications will run just fine in the desktop environment of Windows 8 on x86 based systems. MFC applications will not run on ARM based Windows 8 systems - but then there are lots of places MFC applications won't run.
As for VC++, you can build Metro style applications using C++ if you want to, you just have to follow the Metro "style".
Is there a possibility of me keeping same code base for all windows
versions?
It depends on what you mean by "all windows versions". The code that runs on Windows 7 x86 based systems today will run on Windows 8 x86 based systems tomorrow. If that's your target market then you're done, you don't need to change your code. The only thing you won't have is an active tile. But you could build an active tile using the Metro style APIs and tie that back into your app's logic if that makes sense.
If you want to support ARM based Windows 8 systems as well as x86 based systems, or if you want all of your program to have the Metro look and feel when running on x86 based systems then you'll have to change your program to use HTML/CSS or XAML and the WinRT APIs instead of MFC and the Win32 APIs.
Or if you want both worlds, perhaps you might even seperate your program's logic from the UI and then build an MFC skin and a Metro skin around that common logic
Do I have alternative APIs for winsock and MFC?
For networking there are a number of classes you can use from JavaScript, Visual Basic, C# and C++. For building UI you either use HTML/CSS or you use XAML.
Or you continue to use MFC if that fits your needs. You're probably never going to ever build a Metro style app that's got a Multiple Document Interface with a Tabbed UI!
Metro Style is all about user experience and different UI layout. If you want to utilize metro style UI in your app then you many need to write a WinRT wrapper around you app to utilize it. That doesnt mean that your application will not run at all in Windows 8, all the leagacy application still run in Windows 8
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
I'm tasked with "porting" a few apps from a Windows environment to various mobile platforms and Mac as well.
I plan on writing MVC patterned apps in which I write as many controllers as I can in some sort of universal library, probably in C or C++. Then writing the views in various choice languages (Objective C, Java, .NET, whatever) for the target OSes.
I've never attempted anything like this before, so my questions are: Is it possible to write and compile one library that can be used on iPhone, Android, Blackberry, Windows and Mac? Is it even wise to try this?
I understand that certain native methods simply won't be available on each platform.
You can create a library whose source code is portable, assuming that you properly abstract away any platform-dependent calls. You can't, however, create such a library, compile it, then use it anywhere; you'll have to compile it for each platform.
Your should take a look at the Mono Project. http://www.mono-project.com
...more specifically at :
MonoTouch: To develop iPhone applications in .NET
MonoDroid (BETA): To develop Android applications in .NET
Mono plugin for MeeGo: To develop MeeGo applications in .NET
And you know that you can develop on Windows Mobile in .NET already.
I've haven't found anything related to BlackBerry yet.
There are services like Rhomobile and Appcelerator which will allow you to do this sort of cross compiling.
I've never used either however.
For developing programs for windows, we need windows SDK. I understand that this SDK is what helps to create windows and handle window events and all that. I suppose it also enables us to manipulate with files and registries.
(Does the same SDK is the reason for thread creation and handling?)
All that is fine!
I would like to know what are the files and libraries that come as a part of this SDK. Also does it come when I install the OS or when I install editors like Visual studio? Sometimes I see links to windows SDK separately as such. Is it same as the one that I get when installing Visual Studio or has something more than that.
Base Services:
Provide access to the fundamental resources available to a Windows system.
Included are things like
file systems,
devices,
processes & threads
and error handling.
These functions reside in kernel32.dll on 32-bit Windows.
Advanced Services:
Provide access to functionality that is an addition on the kernel.
Included are things like the
Windows registry
shutdown/restart the system (or abort)
start/stop/create a Windows service
manage user accounts
These functions reside in advapi32.dll on 32-bit Windows.
Graphics Device Interface:
Provides functionality for outputting graphical content to
monitors,
printers
and other output devices.
It resides in gdi32.dll on 32-bit Windows in user-mode. Kernel-mode GDI support is provided by win32k.sys which communicates directly with the graphics driver.
User Interface:
Provides the functionality to create and manage screen windows and most basic controls, such as
buttons and scrollbars,
receive mouse and keyboard input,
and other functionality associated with the GUI part of Windows.
This functional unit resides in user32.dll on 32-bit Windows. Since Windows XP versions, the basic controls reside in comctl32.dll, together with the common controls (Common Control Library).
Common Dialog Box Library:
Provides applications the standard dialog boxes for
opening and saving files,
choosing color and font, etc.
The library resides in comdlg32.dll on 32-bit Windows. It is grouped under the User Interface category of the API.
Common Control Library:
Gives applications access to some advanced controls provided by the operating system. These include things like
status bars,
progress bars,
toolbars
and tabs.
The library resides in comctl32.dll on 32-bit Windows. It is grouped under the User Interface category of the API.
Windows Shell:
Component of the Windows API allows applications to access the
functionality provided by the operating system shell,
as well as change and enhance it.
The component resides in shell32.dll on 32-bit Windows. The Shell Lightweight Utility Functions are in shlwapi.dll. It is grouped under the User Interface category of the API.
Network Services:
Give access to the various networking capabilities of the operating system.
Its sub-components include
NetBIOS,
Winsock,
NetDDE,
RPC and many others.
Internet Explorer web browser APIs:
An embeddable web browser control, contained in shdocvw.dll and mshtml.dll.
The URL monitor service, held in urlmon.dll, which provides COM objects to applications for resolving URLs.
A library for assisting with multi-language and international text support (mlang.dll).
XML support (the MSXML components, held in msxml*.dll).
I have listed only files for 32-bit windows (as that is what many window developers work on)
For more info, please check http://en.wikipedia.org/wiki/Windows_API
EDIT:
Above dlls and all are part of the operating system, not the SDK. The Windows SDK provides import libraries (.lib files) that allow code to dynamically link against these system-provided DLLs.
(This was rightly pointed by Marcelo Cantos. Many thanks to him)
SDK stands for Software Development Kit. It is a big fat collection of headers, libraries, tools and other bits and pieces that developers use to construct software. Microsoft provides many SDK's for their large range of products, and they are not generally deployed to the end-user's desktop. They are usually only installed on developer machines, either as part of a development environment like Visual Studio, or separately (but usually intended for use within VS anyway).
When you talk about the thing that handles windows, threads, etc., you are describing the Windows APIs. The purpose of an SDK is to allow developers to write software that accesses the APIs.
The Windows SDK gives you, as a developer, access to all the services of the Windows platform, including all the things you list.
The SDK is installed as part of the installation of Visual Studio, and usually you'll use the one that came with the compiler, and never have to worry about it. The standalone SDK downloads are there to support two scenarios:
If you use a compiler other that Visual Studio, it may not come with the SDK files, so you can download them separately.
Each new version of Windows includes more features in the API, so to call these new functions you need an updated SDK.