Error :UI engine accessed without holding the event lock.

http://rob.wemakewebsites.co.nz/index.php?p=39

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800505/800608/How_to_-_Manage_UI_interactions.html?nodeid=800514&vernum=0

VS编译动态库无法直接运行，所需的其他文件说明(Visual C++ Libraries as Shared Side-by-Side Assemblies)

Refer to
http://www.cppblog.com/noswimfish/archive/2010/11/24/123742.html

The ATL, MFC, Standard C++, and CRT libraries support the deployment model available on Windows XP, Windows Server 2003, and Windows Vista. The DLLs corresponding to all Visual C++ libraries have been grouped into several shared side-by-side assemblies and are installed into the native assembly cache, also called the WinSxS folder, under the operating system root directory. Similarly, while building a C++ application by using Visual C++, by default the compiler and the linker generate a manifest file that describes runtime dependencies of this application on Visual C++ libraries.

Visual C++ libraries cannot be used by a C/C++ application without a manifest binding the application to these libraries. If a C/C++ application that depends on a Visual C++ library does not use a manifest, then an attempt to load the Visual C++ library as a dependent DLL from the application-local folder will result in an error message indicating that this is an unsupported way of loading a Visual C++ library.
NoteNote

On versions of Windows that do not support deployment of shared side-by-side assemblies, such as Windows 98 and Windows 2000 Server, the Visual C++ libraries are installed in the System32 folder and WinSxS folder under the operating system root directory. This setup enables running Visual C++ applications on these operating system versions because they do not support manifest-based binding of applications to dependent DLLs. On these operating systems, when an application is loaded, the corresponding manifest file is ignored and the operating systems searches for dependent DLLs using paths set in the current running environment. However, on upgrading the operating system to a version that support manifest-based binding, such as Windows XP, Windows Server 2003, or Windows Vista, applications built with manifests start using the DLLs installed in the WinSxS folder.

This change to the deployment model of Visual C++ libraries prevents the problem of version conflicts between DLLs that occur when you add updates or configurations to a machine, and will allow support of side-by-side installation of two different Visual C++ toolsets. It will also allow you to produce reliable, self-describing applications and components that will not conflict with existing components. For more information on the advantages of new deployment model, please see Concepts of Isolated Applications and Side-by-side Assemblies. To learn about how this may impact deployment of existing native C++ applications, please refer to Redistributing Visual C++ Files.

Visual C++ libraries have been packaged in several shared side-by-side assemblies with corresponding manifest files.

Assembly Name


DLLs included in the assembly


Visual C++ Library

Microsoft.VC90.ATL


atl100.dll


Active Template Library

Microsoft.VC90.CRT


msvcr100.dll

msvcp100.dll

msvcm100.dll


C Runtime Library, release DLLs

Microsoft.VC90.DebugCRT


msvcr100d.dll

msvcp100d.dll

msvcm100d.dll


C Runtime Library, debug DLLs

Microsoft.VC90.MFC


mfc100.dll

mfcm100.dll

mfc100u.dll

mfcm100u.dll


Microsoft Foundation Classes, release DLLs

Microsoft.VC90.DebugMFC


mfc100d.dll

mfcm100d.dll

mfc100ud.dll

mfcm100ud.dll


Microsoft Foundation Classes, debug DLLs

Microsoft.VC90.MFCLOC


mfc100chs.dll

mfc100deu.dll

mfc100esn.dll

mfc100ita.dll

mfc100kor.dll

mfc100cht.dll

mfc100enu.dll

mfc100fra.dll

mfc100jpn.dll

mfc100rus.dll


Microsoft Foundation Classes, localized resources

Microsoft.VC90.OpenMP


vcomp100.dll


OpenMP Library, release DLLs

Microsoft.VC90.DebugOpenMP


vcomp100d.dll


OpenMP Library, debug DLLs

When you build applications with Visual C++ 2008, you may need to redistribute Visual C++ libraries and deploy the corresponding DLLs to customers' desktops. For more information please see Deployment (C++).
Feedback
# re: VS编译动态库无法直接运行，所需的其他文件说明(Visual C++ Libraries as Shared Side-by-Side Assemblies) 回复 更多评论
2010-11-24 09:32 by 杨书童
在VS2005下用C++写的程序，在一台未安装VS2005的系统上，
用命令行方式运行，提示：
“系统无法执行指定的程序”
直接双击运行，提示：
“由于应用程序的配置不正确，应用程序未能启动，重新安装应用程序可能会纠正这个问题”

以前用VC6和VS2003的话, 如果缺少库文件，是会提示缺少“**.dll”，但是用VS2005却没有这样的提示。

自己实验了一下，感觉以下几种解决办法是可行的：
方法一：
在类似C:\Program Files\Microsoft Visual Studio 8\VC\redi
st\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT 下找到了下列文件：

msvcm80d.dll
msvcp80d.dll
msvcr80d.dll
Microsoft.VC80.DebugCRT.manifest

把这几个文件拷贝到目标机器上，与运行程序同一文件夹或放到system32下，就可以正确运行了。

其他release版、MFC程序什么的都是拷redist下相应文件夹下的文件就可以了,文件夹后都有标识!

方法二：
修改编译选项，将/MD或/MDd 改为 /MT或/MTd，这样就实现了对VC运行时库的静态链接，在运行时就不再需要VC的dll了。

方法三:

工程－》属性－》配置属性－》常规－》MFC的使用，选择“在静态库中使用mfc”
这样生成的exe文件应该就可以在其他机器上跑了。

方法四:

你的vc8安装盘上找到再分发包vcredist_xxx.exe和你的程序捆绑安装
刷新评论列表

http://msdn.microsoft.com/en-us/library/aa260978%28VS.60%29.aspx

Porting x86 programs to x86_64

Refer to:
http://www.physics.uq.edu.au/people/foster/amd64_porting.html


Porting x86 programs to x86_64

Since buying my amd64 system in 2004 I have been running a 64-bit linux kernel, and often want to run programs which have been developed for 32-bit x86 processors. Porting code to amd64 from x86 is usually a fairly straightforward task involving fixing a few type problems. The following describes some of the issues I've encountered when porting to x86_64 in the hope that it will save someone some time.
Sizes of integer and pointer types

One of the most common problems encountered in programs written for x86 is assumptions about the size of pointer and integer types. Typically this leads to truncation; a common C++ error looks like the following:

string str = get_some_string();
unsigned int delimPos = str.find(':');
if(delimPos != string::npos)
handle_delimiter(str);

However, since an unsigned int encompasses a smaller range than string::size_type, string::npos is truncated to fit, and the conditional is always executed.

Actually, using the unsigned int above is just bad practise and should be avoided in favour of the proper type provided by the standard library, string::size_type. These kinds of errors easily slip by on a 32-bit system however where we typically have unsigned int == string::size_type. Luckily they're easily found by a compiler - study your compiler warnings carefully - they are usually there for a reason!
Pointers

A bunch of nastier errors occur because the pointer size on a 64-bit system is naturally enough 64 bits wide. Any code which is doing horrible low-level things involving casting pointers to integers will probably break in a rather nasty fashion.
Sizes of types, for the record

The trivial piece of C++ code here shows the relevant sizes of various types. For a 64-bit amd64 system using g++, I have the following:

$ ./test_data_sizes
Integer types:
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8

Pointers:
sizeof(void*) = 8

Floating point types:
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 16

Sizes from stddef.h:
sizeof(size_t) = 8
sizeof(ptrdiff_t) = 8

On the other hand, when compiled with g++ on a 32-bit system (i686) we get the following:

$ ./test_data_sizes
Integer types:
sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 4
sizeof(long long) = 8

Pointers:
sizeof(void*) = 4

Floating point types:
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 12

Sizes from stddef.h:
sizeof(size_t) = 4
sizeof(ptrdiff_t) = 4

Of particular relevance, the sizes of the long, void* and types from stddef.h are different. Note that these results also may depend on the compiler, not just the architecture. I've been told that VC++ differs from g++ with regard to the sizeof(long).
Position Independent Code and Non-x86 Architectures; -fPIC

Another problem which often rears its ugly head is related to the difference between the way that the two platforms handle position independent code (PIC) and indicates that the build system rather than the source code needs to be modified. Since there's been a distinct lack of information on the web about this, here's my take on the subject. I'm not an expert, so take it with a grain of salt; constructive feedback is always welcome.

Briefly, position independent code is object code which may be put at an arbitrary position in memory and executed without modification. This is in contrast to (relocatable) position dependent code which needs an extra translation step. One upshot is that PIC is appropriate for use in shared objects.

In order to generate PIC with gcc, the option -fPIC should be used. Portability issues arise when a build system assumes that position dependent code can be linked into a shared library. Because of architectural peculiarities this assumption is fine on a x86 system, but invalid on many others, including amd64.
An Example

Suppose I decide to write a library containing a single function, writeHello(), the source files being as follows:

// hello.h
#ifndef HELLO_H
#define HELLO_H

void writeHello();

#endif // HELLO_H

// hello.cpp
#include
#include "hello.h"

void writeHello()
{
std::cout << "Hello World!\n";
}

If we attempt to compile these into a shared library without using -fPIC, we get the following mess:

$ g++ -c -o hello.o hello.cpp
$ g++ -shared -o libhello.so hello.o
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld:
hello.o: relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
hello.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
$

On the other hand, if we include an -fPIC in the compile options, everything is fine, and out pops a shiny new shared object:

$ g++ -c -fPIC -o hello.o hello.cpp
$ g++ -shared -o libhello.so hello.o

Granted it doesn't do much... but not to worry ;)
Shared and static libraries

The example above is a very simple case of where you can get into trouble with non-PIC object code. A more complicated case involves attempting to link static libraries into shared libraries. Suppose I created a bunch of static libraries, libfoo.a, libbar.a and libbaz.a and I wanted to link them into a shared object libfred.so. On x86 it is permissible to create the static libraries out of non-PIC objects. However, the following will fail on the amd64 architecture unless the static libraries are built with -fPIC:

$ g++ -shared -o libfred.so $fred_objects -lfoo -lbar -lbaz

Relevance to automated build tools
Autoconf et. al.

The nasty mess that is the GNU autotools has a uniform way for dealing with generating position independent code - the relevant command line flag, --with-pic will cause static libraries to be built as PIC, and avoids the library issue mentioned above. The autobook briefly mentions this though I haven't played with it myself so I'm not sure if the option is relevant if libtool is not being used.
SCons

SCons automatically determines whether to use -fPIC when creating libraries using the StaticLibrary or SharedLibrary builder methods. However, you've still got to be careful with linking static libraries made from non-PIC objects into shared libraries. This page resulted from my search for a clean solution to this problem for use with the Aqsis renderer project.

After learning much more about scons than I'd originally intended, I finally found the following reasonably clean solution. The idea is to override the default Library and StaticLibrary builder objects of the build environment and cause them to compile PIC code. This may be done by passing src_builder = SharedObject rather than StaticObject to the Builder factory function:

import platform

if platform.machine() == 'x86_64':
picLibBuilder = Builder(action = Action('$ARCOM'),
emitter = '$LIBEMITTER',
prefix = '$LIBPREFIX',
suffix = '$LIBSUFFIX',
src_suffix = '$OBJSUFFIX',
src_builder = 'SharedObject')
env['BUILDERS']['StaticLibrary'] = picLibBuilder
env['BUILDERS']['Library'] = picLibBuilder

For some projects it may be desirable to build static libraries from both PIC and non-PIC objects. In that case, instead of overriding the Builder objects as above, you'd probably want to define some new ones, and explicitly call them to produce pic libraries. You'd also want to modify the library name to allow both flavours of static library to coexist without name clashes. I gather the standard way to do this is to append _pic to the library name. Putting this together, you'd have something like:

if platform.machine() == 'x86_64':
picLibBuilder = Builder(action = Action('$ARCOM'),
emitter = '$LIBEMITTER',
prefix = '$LIBPREFIX',
suffix = '_pic$LIBSUFFIX',
src_suffix = '$OBJSUFFIX',
src_builder = 'SharedObject')
env['BUILDERS']['StaticPicLibrary'] = picLibBuilder
env['BUILDERS']['PicLibrary'] = picLibBuilder

Relevant Links

* A helpful discussion about fPIC on the freeBSD ports list
* Shared objects for the object disoriented: an introduction to shared objects at IBM developer works.

QT

http://hi.baidu.com/baldwin8/blog/item/10c3fd8e7c0002f6503d92df.html

https://lists.webkit.org/pipermail/webkit-help/2009-August/000193.html

http://www.qtcn.org/bbs/simple/?t18619.html

vmware 网络配置实例二 windows xp host + linux guest

vmware 网络配置实例二 windows host + linux guest
（yunqing（2005-03-24）按：很多朋友问到ping不通host的情况，请检查一下host里的防火墙设置，多数的windows xp sp2下的防火墙都设置成不响应）
前言：前几天写了一个vmware的配置的一个案例，主要关于linux host+windows guest的情况（http://bbs.chinaunix.net/forum/viewtopic.php?t=367907& highlight=yunqing），适用于经常跑linux而把windows当成副业的朋友。发布以后反应不大，后来发现坛子里的朋友使 windows host 来跑linux guest的居多 ，且有很多帖子谈到网络问题，自己想没有那么难吧，就试了一把，把过程写下来希望对网络有问题的朋友有所帮助。
版权属yunqing所有，首发chinaunix.net，转贴引用请包含此行声明

正文：

本人使用的是vmware workstation 4.52，host机器运行的是windows Xp professional ，如果你还在使vmware workstation 4.0建议下载一个升级包，不过我想即使不做问题也不大。

1。安装 vmware workstation，很简单，一路ok过去，相信大部分朋友已经装好。

2。创建新的guest系统。选择类型。因为我以发生问题最多的redhat 9做试验，所以就选redhat linux，选custom，网络接口选hostonly（如果你已经安装好 了，用了nat或bridge也没有关系，在虚拟机的属性里改成hostonly就行了。）

3。创建后启动虚拟机，插入安装rh9的第一张盘。选择定制安装，我只保留了gonme, X， 和graphical internet,节省安装空间和时间。

4。安装过程很顺利，没有问题，完成后重新启动虚拟机，发现在更新fstab的时候挂了起来，估计是连接cdrom活软盘时候超时。kill掉虚拟机，更改设置，把光驱和软盘的autoconnect when power on清除掉。重启虚拟机，没有问题，进入最后设置，声卡，图形界面均没有问题。

5。按照要求在虚拟机里安装vmware-tool,对鼠标和图形进行更好地支持。
如果你在图形界面下，首先要切换到文本模式。
右键点击桌面，打开一个終端
在終端里：
su
#/sbin/telinit 3
图形界面消失，敲回车几下，在文本方式下登录。
在windows的vmware的窗口菜单中选vm->;install vmware tools
在虚拟机中：
su
mount /dev/cdrom /mnt/cdrom
cd /tmp
tar zxf /mnt/vmware-linux-tools.tar.gz
cd vmware-tools-distrib
./vmware-install.pl
回答并设置屏幕分辨率，除了分辨率需要选择外，直接回车就行了。
返回到默认的图形界面（运行级别5）
/sbin/telinit 5

6.登录虚拟机，打开一个終端：
/sbin/ifconfig
发现eth0没有起来。
不要惊慌。
－－－－－－－－－－－－－以下是网络设置－－－－－－－－－－－－－－－
7。到windows XP 中，查看所有的网络连接，你应该发现除了原有的网卡之外，又多了Vmnet1和Vmnet8。如果你看了一下说明书应该知道，vmnet1是hostonly的接口，而Vmnet8是使用NAT的网络接口。在这里我们既不想用VMWARE自带的DHCP也不想用他的NAT所以我们知关心VMnet1
在进一步操作之前先说一下idea:
我们将使用hostonly这个网络接口连接虚拟机和主机，然后利用windows Xp/2000里面自带的internet连接共享（实际上是一个简单的路由NAT)来让虚拟机 通过原来的网卡进行外网的访问。
那么为什么不使用桥接的方式呢，我在前一篇文章（linux host + windows guest)里面已经有些讨论，请参考。不过最现实的原因是桥接需要一个不同于 原主机上的另外一个独立的IP地址，这对于有些情况（IP和MAC绑定，网管不同意），比较难办到。
OK， let's go
（1）查看你的连接外网的网卡的属性，选择“高级”标签，设置成允许共享，并设定允许的网络接口为VMNET1,如下图。

(2)再插看一下你的VMnet1 的属性，看一下TCP/IP协议的设置，你发现已经被自动设置为192.168.0.1/255.255.255.0，如下图。

（3）windows下的设置完成，转入到跑linux的虚拟机。将你的eth0的ip地址设置为静态的（如果安装时没有选静态的话）
（4）windows下的设置完成，转入到跑linux的虚拟机。将你的eth0的ip地址设置为静态的（如果安装时没有选静态的话）。
按红帽子图标－＞系统设置－＞网络（或其它你了解的方法）
ip： 192.168.0.2(或其它在此网段上的地址）
netmask: 255.255.255.0
default gateway: 192.168.0.1
dns:输入你自己的DNS
保存设置。如果你还没有设置好主机名称：
cd /etc/sysconfig
vi network
编辑HOSTNAME
cd /etc
vi hosts
加入：
192.168.0.2 yourhostname
重新启动服务
su
/sbin/service network restart
(4)测试一下
网关： ping 192.168.0.1
dns: ping dnsserver

另请参阅：

vmware 配置实例一 linux host + windows guest + firewall
http://bbs.chinaunix.net/forum/viewtopic.php?t=367907&highlight=yunqing

vmware 网络设置三：理解虚拟网络的类型
http://bbs.chinaunix.net/forum/viewtopic.php?t=376768&highlight=yunqing

Howto: Ubuntu Linux convert DHCP network configuration to static IP configuration

My friend wanted to know how to change or convert DHCP network configuration to static configuration. After initial installation, he wanted to change network settings. Further, his system is w/o GUI system aka X Windows. Here is quick way to accomplish the same:

Your main network configuration file is /etc/network/interfaces

Desired new sample settings:
=> Host IP address 192.168.1.100
=> Netmask: 255.255.255.0
=> Network ID: 192.168.1.0
=> Broadcast IP: 192.168.1.255
=> Gateway/Router IP: 192.168.1.254
=> DNS Server: 192.168.1.254

Open network configuration file
$ sudo vi /etc/network/interfacesOR$ sudo nano /etc/network/interfaces

Find and remove dhcp entry:
iface eth0 inet dhcp

Append new network settings:

iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254

Save and close the file. Restart the network:
$ sudo /etc/init.d/networking restart
Task: Define new DNS servers

Open /etc/resolv.conf file
$ sudo vi /etc/resolv.conf

You need to remove old DNS server assigned by DHCP server:
search myisp.com
nameserver 192.168.1.254
nameserver 202.54.1.20
nameserver 202.54.1.30

Save and close the file.
Task: Test DNS server

$ host cyberciti.biz
Network command line cheat sheet

You can also use commands to change settings. Please note that these settings are temporary and not the permanent. Use above method to make network changes permanent or GUI tool as described below.
Task: Display network interface information

$ ifconfig
Task: Take down network interface eth0 / take a network interface down

$ sudo ifconfig eth0 downOR $ sudo ifdown eth0
Task: Bring a network interface eth0 up

$ sudo ifconfig eth0 upOR$ sudo ifup eth0
Task: Change IP address and netmask from command line

Activate network interface eth0 with a new IP (192.168.1.50) / netmask:
$ sudo ifconfig eth0 192.168.1.50 netmask 255.255.255.0 up
Task: Display the routing table

$ /sbin/route OR$ /sbin/route -n
Output:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
localnet * 255.255.255.0 U 0 0 0 ra0
172.16.114.0 * 255.255.255.0 U 0 0 0 eth0
172.16.236.0 * 255.255.255.0 U 0 0 0 eth1
default 192.168.1.254 0.0.0.0 UG 0 0 0 ra0

Task: Add a new gateway

$ sudo route add default gw 172.16.236.0
Task: Display current active Internet connections (servers and established connection)

$ netstat -nat
Task: Display open ports

$ sudo netstat -tulpOR$ sudo netstat -tulpn
Task: Display network interfaces stats (RX/TX etc)

$ netstat -i
Task: Display output for active/established connections only

$ netstat -e
$ netstat -te
$ netstat -tue

Where,

* -t : TCP connections
* -u : UDP connections
* -e : Established

Task: Test network connectivity

Send ICMP ECHO_REQUEST to network hosts, routers, servers etc with ping command. This verifies connectivity exists between local host and remote network system:
$ ping router
$ ping 192.168.1.254
$ ping cyberciti.biz

See simple Linux system monitoring with ping command and scripts for more information.
Task: Use GUI (Graphical Configuration) network Tool

If you are new, use GUI configuration tool, type the following command at terminal:
$ network-admin &

Above command is Ubuntu's GUI for configuring network connections tool.
Final tip - Learn how find out more information about commands

A man page is your best friend when you wanted to learn more about particular command or syntax. For example, read detailed information about ifconfig and netstat command:
$ man ifconfig
$ man netstat

Just get a short help with all command options by appending --help option to each command:
$ netstat --help

Find out what command is used for particular task by searching the short descriptions and manual page names for the keyword:
$ man -k 'delete directory'
$ apropos -s 1 remove

Display short descriptions of a command:
$ whatis rm
$ whatis netstat

Linux offers an excellent collection of utilities, which can be use to finding the files and executables, remember you cannot memorize all the commands and files ;)

TX31 Compfiling

resource:
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
http://www.cs.iit.edu/~agam/cs512/lect-notes/opencv-intro/opencv-intro.html
http://www.troubleshooters.com/linux/prepostpath.htm
http://www.appistry.com/community/forums/content/cannot-restore-segment-prot-after-reloc-permission-denied
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html

OpenCV2.1
http://opencv.willowgarage.com/wiki/InstallGuide

CMake
http://www.cmake.org/cmake/resources/software.html