How should I test a stand alone application on different OS - c++

I have developed an application with c++ on Vista. It works OK. But Now I want to be sure that it works on XP, on Windows 7, and later may be on some types of linux. What good methods do developers use for this task?

There is no substitute for actually running it on the platform itself. If you cannot afford to have separate machines dedicated to each platform then you need to:
Partition the disk(s) on a single machine and install each O/S in its own partition, and multi-boot between them.
Use virtualization software like VMWare or VirtualBox (free!) to set-up each O/S under your host O/S
If your application make little or no use of graphics (or other) hardware then the latter option is a real possibility; if it does use this hardware extensively then you have little choice but to go for the former option.

I use vmware. You can also use VBox or something similar. If you use visual studio along with vmware workstation you can even remote debug your application running in the VMWare.
Obviously keeping to the standard in C++ helps for portability to linux.

go and get a virtual machine player and have functionnal virtual machines for each OS you will test.
Execute the same unitary test scenarii on all the virtual machines.
Don't hesitate to focuss on what may be implemented differently on each plateform:
Save/Load dialogs
Remote communication
Drag'n'Drop
that's what come to my mind, there maybe thousands of other issues.
Anything really really low level (with inline asm code for eample) may be impacted by OS change.

Related

bios information in c++

I just want to known how to get BIO information in C++. I tried following option but each one has its drawback.
From Registry: But I found some system where HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS is missing may be it is virtual machine.
Using WMI: But It is not necessary that WMI will run on all the systems, because in certain cases either the service is disabled or the WMI object is missing!!
I need one permanent solution that gives me BIO information in c++.
Trying to detect if you are in a virtual OS is done in various ways and depends on the virtualization software being used.
There are many different questions about this already on stackoverflow.
In no particular order, here are some articles, they cover a variety of the different virtualization pieces used:
Detect virtualized OS from an application?
detect if application running on virtual box
64-bit windows VMware detection
How to identify that you're running under a VM?
http://www.codeproject.com/Articles/9823/Detect-if-your-program-is-running-inside-a-Virtual
Whilst Salgar beat me to it, one of the more "safe" methods is to use the CPUID instruction, which generally works on modern VM's. I know that KVM, Microsoft and Xen uses a CPUID leaf around 0x40000000 that gives back "You are in a virtual machine". Not 100% sure if VMWare also supports the same one - on a "real" machine, these are reserved and not used.
Here's a page that discusses several options besides CPUID:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/detecting-x86-virtual-machines.html
and there are several links for further reading.

how can i write a driver without any library or frame work?

my question is "How to write a driver without WDK or DDK or ...?"
I googled it but i couldn't find any thing...
and i just want to do it for educational purpose
and i want to do it in windows 7
and i know c and assembly (but not pro in assembly)
Help is very much appreciated!
Writing a driver for ANY operating system requires knowledge about the OS kernel's driver structures and system calls and other behavior: this is what the DDK provides for you. Attempting to do this WITHOUT the DDK would be the same as attempting to re-implement all the kernel's driver structures and system calls from scratch.
Conceivably this could be done: practically it is not really possible, particularly for any mature operating system such as Windows 7.
If you meant driver that enables system to use some hardware - it is (virtually) not possible. The driver must interface somehow with the system, and that's what DDK is for.
But if you just want to access some device you have (eg. connected via COM, LPT or USB), you don't need any drivers except those for COM, LPT or USB (already in the system).
There's really no way to do this without using the driver kits - Microsoft is legally bound by the US Government Dept. of Justice decrees from providing OS access to anybody (even their own devs) via privileged/non-published APIs.
You need to know what the WDK or DDK do and recreate it. You'll be pushing special values into special registers, responding to special interrupts...etc.
LOT'S of work ahead for you.
Good luck!
I know nothing about Windows internals but Andrew Tridgell did a talk on reverse engineering Windows drivers using LD_Preload. He didn't use any driver kits or the like
I also know nothing about the Window's dynamic linker (I'm pretty sure Windows doesn't use .so's) but his technique of running Windows through a virtual machine (he used virtual box) under Linux should work.
You can see more details here http://lwn.net/Articles/425714/
Reverse engineering an existing driver should give you a good start towards writing your own.
If you mean driver as in a driver that works under a specific operating system such as Win7, then naturally you need a development kit such as WDK unless you want to re-invent the wheel.
It's like developing a game without using a framework, or developing Android Apps without using Android SDK. It's possible but a very very hard task which could be done easily using a development kit such as WDK.
EDIT: If you really want to go deep into the code that handles drivers, you can create a driver with DDK and then use reverse engineering to take a look at the code at low-level and see how it interacts with CPU for handling the hardware.

Get number of physical processors inside virtual machine

I'd like to know if there's a way to learn the number of physical CPU-s of a host computer when my code is running inside a VM.
I'm looking for C++/assembly solutions that run in Windows and under VmWare (workstation/esxi) and HyperV. Sorry for the very vague question but after several searches, I'm not sure if this is possible to do inside the virtual machine.
The very concept of VM is that your code (even your OS) do not know that they are sharing resources.
So in first intance, no. The only possible workaround would be if the VM provided it explicity (I am thinking of VMWare Tools, yet I do not know if they offer an API for you).

Is it possible to port a Linux daemon to Windows using Cygwin or MinGW?

I have a Linux C++ application which run as a daemon. When user executes this application, it will be running in the background, listening on a port, and waiting for connection from the clients.
Is it possible to port this kind of application to Windows platform using Cygwin or MinGW?
Thanks.
Cygwin aims at POSIX/Linux source level compatibility, so your application is supposed to build and work there with no or only minor modifications.
MinGW does not try to provide such a compatibility layer. It's just the GNU toolchain for Windows, so you would need to replace any uses of POSIX/Linux-specific APIs with Windows equivalents.
It is possible to port almost anything (unless it makes sense only to one OS). The question is, "how hard is it to port application X"? And to help answer that question, we need to see source code.
General purpose tips
It basically boils down to how much compiler/system-dependent code you've spread out over your code base. I see you're using at least two things that are sensitive: daemons and sockets.
Daemons are tricky to port as the equivalent on Windows (a windows service) requires different platform-specific code. This is fixed cost (e.g. does not vary on the size of the rest of the application).
Sockets are more or less tricky to port depending on whether you're using advanced networking features (asynchronous I/O, etc.), which tend to vary more from system to system. It also depends on whether you abstracted socket manipulation code into some re-usable component. Windows supports a very similar sockets interface (the classic BSD socket interface with minor modifications to random parts of the API). Changing one Socket class is easier than changing your code if you didn't write a wrapper class.

Writing a Hypervisor?

I am researching ideas for a PhD project.
One of my thoughts is writing a hypervisor (or bare metal) (?) so I could run multiple OS's without use of a true host operating system. Example I get a menu of some type of options to start operating systems, view what the 'console' of what is going on in an OS that is already running. Reboot OS's, install a new one, etc.
So no host OS, just a small app that controls everything.
Conceptually how does one think about doing this?
I have a MacBook. I should be able to modify what the EFI boots. Maybe start with a very minimal Linux LIve implementation and scale it really, really far back?
Is it possible to use Darwin and scale it very far back?
Your idea as stated is not an original contribution to the science.
My advice is to review Xen and the general hypervisor literature, dating back to the '60s &
'70s when IBM invented it.
I'm certain there is room for improvement and original ideas there.
In terms of actually writing a hypervisor, you should review Wikipedia first, as it gives a good brief on virtualization.
Here is a historical summary, including some seminal citations: http://www.kernelthread.com/publications/virtualization/. Note the first citation is from 1959!
Scaling back an existing desktop/server OS seems like a poor choice. OTOH, rather than redo everything, it may be useful to start with an embedded RTOS such as ecos or L4 to draw some features from. Additionally, some code could possibly be re-used from QEMU.
If I were doing it, I would focus on hardware virtualization using VT-x and AMD-V ignore dynamic recompilation (unless was to be the focus of your work).
Also, it seems to me that it would be a good idea to already be able to write operating systems enough to make some small test operating systems that can boot on bare hardware to use for testing the hypervisor under development.
BTW, if scaling back an existing OS was a good strategy, I think it would work best on Linux or one of the major BSDs. Using Darwin is likely asking for pain.
Scaling back an existing OS to develop a hypervisor seems an unlikely approach.
Definitely have a look at some of the existing open source hypervisor project out there.
If you are interesting in reading about how they work and how you might approach writing
one then you could try:
Virtual Machines by Smith & Mair.
The Definitive Guide to the Xen Hypervisor by Chisnall.
If you are going to write it from scratch, and you are targeting the x86 family of processors then you are going to have to get your hands dirty with virtualization instructions (eg. Intel VT-x). And this will be with pure assembly language, or at best inline assembly. You are talking real low level stuff here.
If you are interested in computer communication and hypervisiors what about cross OS communication [it would be cheaper than trying to connect via normal TCP/IP sockets.
ESX is essentially a scaled-back Linux install - with a host of other goodies added: so your basic premise is decent.
However, for a PhD project, it sounds too broad: you should focus on something smaller.