We Keep Coding

Does every windows comes with user32.dll?

I have c# application that contains the code.
[DllImport("user32.dll")]
static extern IntPtr GetForegroundWindow();
to get current window title . Now I have to deploy the application , I want to know that does every type of windows (64 and 32bit and XP,7,vista,8,10)comes with user32.dll or I have to make users download that first?

You can be sure that user32.dll will always be present, as it is part of the Windows API.
I could imagine a world where Microsoft comes up with win 11/12/etc.. And they are so frustrated with having to keep up with their old API that they throw user32.dll out the window(s).
Like with any API break - deal with it when it present's itself. if you plan for every eventuality - you will have to wait it out and never publish a single bit of software.

It is a core dll like kernel32.dll. It contains all necesary API that a windows user can call. So yes, it is present in any windows version

Yes it comes by default with every window,
USER32.DLL implements the Windows USER component that creates and
manipulates the standard elements of the Windows user interface, such
as the desktop, windows, and menus. It thus enables programs to
implement a graphical user interface (GUI) that matches the Windows
look and feel. Programs call functions from Windows USER to perform
operations such as creating and managing windows, receiving window
messages (which are mostly user input such as mouse and keyboard
events, but also notifications from the operating system), displaying
text in a window, and displaying message boxes.
Many of the functions in USER32.DLL call upon GDI functions exported
by GDI32.DLL to do the actual rendering of the various elements of the
user interface. Some types of programs will also call GDI functions
directly to perform lower-level drawing operations within a window
previously created via USER32 functions.
Source Wiki User32.dll

Window CE 4.2 - Enumerating through the controls of a different running process

I have been charged with the task to send data from COM 1 to COM 2 in Windows CE 4.2. A running application takes data from COM 1 and displays it to the user in a form (textbox I assume). I then have to take that data and send it out COM 2. COM 1 is being used by the program displaying the data and I know of no way to hijack COM 1.
I figure trying to do a screen scrap would be the next step. Unfortunately this is compact framework and an old version at that and from a lot of research it seems managed code is out of the question . Many of the API functions I would use are not available; FindWindowEx for example.
Here is where I am at now. I have created two projects. One runs with a TextBox and some wording. A separate application runs and tries to read the text in that TextBox. I have been able to find the running process based off the name of the form using FindWindow API. Using code I have found on this site I have even been able to enumerate through the controls of the form. However my TextBox is never found and many of the controls that are found where never placed on the form by myself (listbox, button). I assume those are the form's initial controls.
Does anyone have any experience with this? Currently this is in C# but VB or Visual C++ will be fine. Even if you have any ideas on a third party application. BTW I am not given the option to upgrade to a higher version of compact framework.
Thank you.
An update I just found out about. It does not look like I only screen scrape only new data but instead have to screen scrape the entire screen and send it out COM2. Someone will scan a barcode and I will send out all screen data through COM2. The data may include a picture etc.

For a native C application I have one sceleton that enumerates all child windows and controls inside a dialog: http://code.google.com/p/rdp-auto-login/source/browse/trunk/rdp-auto-login/tscDialog.cpp. See ScanTSCWindow and the results found in the comment "TSC dialog elements".
I started with remote spy and looked thru the RDM window to find the CtrlID values. There is also a nice tool called zDump (http://www.hjgode.de/wp/2009/06/11/zdump-take-a-look-inside-windows-ce/) that runs on device and enables you to look at window elements.
The theory is that every element in Windows (either Mobile or desktop) is a window. Windows are accesible by there window handle. The handle is assign by the OS during CreateWindow/Ex. Inside dialogs, elements can be identified by there control ID (a resource value), the window class (ie "EDIT", "LISTBOX") and window text and internally by the window handle at creation.
The problem with Compact Framework apps is that they hide many of these basics and dialog (Form) elements can not be easily identified from another process.
As you say you are not able to capture COM1, what is, if you stop the application and then open COM1? As knonw, normally on one application can access a serial port at the same time. You can then read the serial data directly and do not need to access a foreign window.
There are also drivers that enable port mirroring or multiple access. Even for Windows CE based OS (ie http://www.virtual-serial-port.org/products/serial-splitter-mobile/).
If the application is a compact framework one you can take a look inside the code using .Net Reflector or similar .Net decompilers. I use that often to mimik or learn from other apps.
You say "I have been charged with the task to send data from COM 1 to COM 2 in Windows CE 4.2. A running application takes data from COM 1 and displays it to the user in a form (textbox I assume). I then have to take that data and send it out COM 2. COM 1 is being used by the program displaying the data and I know of no way to hijack COM 1." and if you do not start the other app you can write your own and do not need to parse the foreign app.
Possibly you can post the other app or more details of what it does what you can not do.
EDIT/UPDATE:
as we now know it is Intermec TE2000 (terminal emulation) the answer is to use the XMLRPC interface provided by TE2000. The interface is able to call back a function hosted by an xmlrpc server and send all screen content (text, fields and attributes) on screen changes. I have working c++ stl windowsce code for that.
If the device is connected via network, the xmlrpc server can even run on a PC.
As TE2000 does use native drwastring API you will not success in reading texts from the window. If you screen capture the window, you will have to do OCR on the image. XMLRPC does avoid all this.
UPDATE2:
I finished a class lib to get async screen updates using TE2000 xmlrpc: see https://github.com/hjgode/ITE_xml_rpc/tree/master/XmlRpcCS/XmlRpcCF
and http://community.intermec.com/t5/Thin-Client-Based-Development/Printing-CV60-Screen-Windows-CE-4-2/m-p/28663/highlight/false#M473

Implementing separate application instances in taskbar like Skype

I noticed for a few updates of Skype now that if you start 2 or 3 instances of Skype, in the windows taskbar they appear as separate windows and you can drag them individually as opposed to other applications when they are "glued" together and you can drag them all at once.
My question is how can I implement the individual appearance in my application and is it possible from C# or through winapi?

The shell groups windows in the taskbar using each window's Application User Model ID (AppUserModelID).
By default, every window generated by a given EXE (even in different processes) shares a system-generated AppUserModelID.
You can give each process its own AppUserModelID by calling SetCurrentProcessExplicitAppUserModelID. From your description this is probably what Skype is doing, though I haven't checked.
You can give each window its own AppUserModelID by setting a different PKEY_AppUserModel_ID property on the windows.
Note that these IDs are required to have a particular format:
CompanyName.ProductName.SubProduct.VersionInformation
Raymond Chen wrote an article about this, and it's also worth reading the documentation I linked to.
I'm not aware of WinForms having explicit support for this, but you could certainly use interop to call the Win32 API directly.

Windows Form as child window of an unmanaged app

I am looking for a way to embed Windows Forms applications written in C# in a C++ windows application. The native application main window is subdivided into several panes. The C# app is supposed to appear within one of those panes, i.e. the root window of the C# component (the outermost form) must be a child window of the main application.
Can this be done? If so, how?
Some additional context: To my knowledge, there are two ways to go about this. First, host the CLR in the native app by using the .net hosting APIs (ICLRRuntimeHost, etc.). Second, host the CLR by putting the windows form in an ActiveX control.
Regarding the first approach, I have managed to get the CLR started up and to load a C# assembly (thanks largely to Mattias Högström). Where I am hitting a road block is that I see no way how to tell the component I am running in the CLR that it needs to be a child of a window passed in from the C++ side.
I have also experimented with the second method (using ActiveX and thanks to Daniel Yanovsky). It almost, but only almost, works for my purposes. I can let arbitrary Windows Forms components run in a child pane of the native app. BUT they always run on the main thread of the main app. This means they use the windows message loop of the main app. MSDN says this will not work reliably since the standard Windows message loops don't meet the requirements of Windows Forms (I wanted to post the link to MSDN here but have already used up my new-user-two-link-allotment).
The exceptions to the message loop issue are, according to MSDN, Internet Explorer and MFC apps. The native app I am using as a host is definitely not Internet Explorer. Also, it uses the windows API as wrapped by wxWidgets so MFC is not (or at least not a welcome) option.
The solutions Microsoft proposes involve letting the C# components run in their own message loops on their own threads. This, at least as far as I can tell, necessarily leads back to the first approach mentioned above. So I am back to the question of getting a Windows Form to work under a passed-in parent window.
Again, I am interested in any input that clarifies the child window issue, independent of the approaches I have mentioned here. But in light of the context I could reduce the general question to two specific questions (and I would need an answer to only one of them):
Given a Windows Form hosted in an ActiveX control, how can I allow the form to run in its own message loop on its own thread?
or
Given a Windows Form running in a CLR hosted by a native app, how can I make the form be a child window of a window in the native app?

yes, it can be done. We did the same thing years ago. This is our approach: .NET control also has native window handle, we get these handles through C++/CLI and pass them to Win32, and add these handles as the children of native windows. So the .NET controls run on the main thread of the main app, the problematic part is the message loop, as you have mentioned in your question. We need route the message between the nation and .NET windows if needed. As I remembered, we fixed a lot of bugs related to this, and still there were some mysterious problem we didn't figure out.
There's anothe way: using WPF interop. http://msdn.microsoft.com/en-us/library/ms742522.aspx . According to MS, this should fix the message problems, but we didn't try this approach. You can just use Win32 to host WPF, then use WPF to host Winform.
So for your last 2 questions:
You can't. Only one message loop.
Use handle. This article talks about the handle of Windows Forms: http://blogs.msdn.com/b/jfoscoding/archive/2004/11/24/269416.aspx

C# PInvoke and QWidget

I have an application that I am trying to automate on Windows. I need to find the location of a window that is running inside the application, and then automate a couple of mouse events on the application.
In a previous incarnation of the software that I am automating, I was able to search for child windows of the process which were named using the GetWindowText WinAPI function from C# (in combination with GetWindowTextLength).
The software manufacturers have now updated the software and updated the way that the child windows are drawn. Now each window lacks a caption, and has a class name of QWidget. I can no longer use my old strategy to find the child window location. I presume the use of QWidget means the windowing system uses the Qt framework.
Is there any way of pulling any data from the QWidget using PInvoke that I might be able to identify my windows with?

There's a couple problems here. One is that you can't get "unshared" data from another process. You can get at window data by pinvoking methods like GetWindowLong; but unless you know specific data about what QWidget does in that data (the other problem), there's not much you can do with the data.
Another problem is if you want to use most QT objects in a managed application (you can do this with C++/CLI and IJW) you need to initialize A QT Application object in your application... I'm not sure how this would impact what you want to do.