标签归档:windows

svn、bugzilla等穿过防火墙访问:如何在 Windows 防火墙中打开端口

如果 Windows 防火墙阻止某一程序,而您希望允许该程序通过防火墙进行通信,通常可以通过在 Windows 防火墙允许的程序列表(也称为“例外列表”)中选中该程序来实现。若要了解如何进行此操作,请参阅允许程序通过 Windows 防火墙进行通信

但是,如果没有列出该程序,则可能需要打开一个端口。例如,当您与朋友联机进行多人游戏时,可能需要为该游戏打开一个端口,这样防火墙才能允许游戏信息到达您的计算机。端口始终保持打开状态,因此请确保关闭不需要打开的端口。

  1. 通过单击「开始」按钮 「开始」按钮的图片,然后单击“控制面板”,打开“Windows 防火墙”。 在搜索框中,键入防火墙,然后单击“Windows 防火墙”

  2. 在左窗格中,单击“高级设置” 需要管理员权限 如果系统提示您输入管理员密码或进行确认,请键入该密码或提供确认。

  3. “高级安全 Windows 防火墙”对话框的左窗格中,单击“入站规则”,然后在右窗格中,单击“新建规则”

  4. 按照新建入站规则向导中的说明进行操作。

如果您无法通过 Windows 防火墙让其他计算机与您的计算机通信,则可以尝试使用“传入连接”疑难解答自动查找并修复一些常见问题。

通过单击“开始”按钮 「开始」按钮的图片,然后单击“控制面板”,打开“传入的连接”疑难解答。在搜索框中,键入疑难解答,然后单击“疑难解答”。单击“查看全部”,然后单击“传入的连接”

Enable Bootcamp to install from usb for OSX 10.9**WORKS**

要不说老外还是牛逼啊:

 

So basically, I have trying to install windows on my mbp using a usb drive. However bootcamp wont allow me to do so since I have a optical drive on the laptop. I have been searching for a long time and eventually came across this solution and I would like to share this so u guys dont have to google all over the place again .

The solutions given before by changing info.plist is correct except that now Bootcamp crashes everytime you change it in OSX 10.9.

 

Full solution:

 

1. Add your Boot Rom Version(from system info) under DARequiredROMVersions.

2. Add Model Identifier(from system info) under PreUSBBootSupportedModels

3. Delete “Pre” from “PreUSBBootSupportedModels”, so you have “USBBootSupportedModels”

 

The first 3 steps are same as before and if its not clear you can easily google solutions with screenshots.

The next step is only for OSX 10.9, as it employs some kind of code signature to prevent you from changing info.plist and cause bootcamp to crash.

 

4. Open your terminal, use the following command

sudo codesign -fs – /Applications/Utilities/Boot\ Camp\ Assistant.app

 

Sudo means using administrator privilege and u need to enter your mac password. And the command resigns the bootcamp application so that it runs with the new info.plist file and not crash.

 

5. Continue on with your installation….

 

Cheers.

 

P.S. back up info.plist before u change anything.

【转】Windows上调用Cygwin编译的函数库

2012-04-05 19:22
转载自 kaien_space

本篇介绍的是静态库函数。静态库扩展名是.lib(windows上)或.a(linux上),他和动态库(dll)是有区别的。

调用静态库编译后会写入执行程序中。然后就可以独立运行了。

动态库旨在动态调用,调用的时候需要加载dll才能正常工作。

(所以动态库往往可以提供补丁,或功能升级的时候使用,但是运行的速度有待商协)

另外,两个库的编译器也不一样,例如mingw用g++.exe生成动态库.dll, 用ar 生成静态库.a

而VC则一律用link.exe生成生成动态和静态库,用options来区别生成哪种。

 

本文只讲静态库.dll和.a 的例子。动态库其实很类似。

我们的目的是,把若干的C++和C文件在Cygwin上编译成一个静态库函数文件。

然后在Windows上调用这个库函数。

举个简单的例子:

我们有两个库函数文件.cpp或.c

1. myf1.cpp

#include <stdio.h>

void f1_Fonction1(int a, double b, char *c)
{
printf(“调用文件myf1.cpp的f1_Fonction1成功\n”);
}
int f1_Fonction2(int c)
{
printf(“调用文件myf1.cpp的f1_Fonction2成功\n”);
return c+1;
}

2. myf2.c

#include <stdio.h>

void f2_Fonction1(void)
{
printf(“调用文件myf2.c的f2_Fonction1成功\n”);
}
int f2_Fonction2(int c)
{
printf(“调用文件myf2.c的f2_Fonction2成功\n”);
return c+2;
}

上面两个文件一个是C++的,另一个是C的。

两个文件各提供了两个函数。

现在我们在Cygwin上编译他们为库函数mylib.a 或mylib.lib (扩展名不重要)

> gcc -c myf1.cpp myf2.c

由于我们这里的函数都是C标准格式,所以我们还使用g++, c++或cc等编译。选用任意一种都可以编译通过。

(通常情况下,选哪个编译器和你的C++代码的编写用语格式有关,每个编译器都有其特殊的支持格式)

上面的命令编译生成两个文件myf1.o和myf2.o

接着,我们使用ar生成静态库

> ar r mylib.lib myf1.o myf2.o

这样,我们就在cygwin上生成了一个静态库mylib.lib

现在,我们尝试在windows上调用这个库中的一个函数试试看

写一个简单的调用的C++程序main.cpp

#include <iostream>
using namespace std;

void f1_Fonction1(int a, double b, char *c);

int main()
{
char c;

f1_Fonction1(1,2.0,&c); //调用了myf1里面的函数f1_Fonction

cout << “Hello world!” << endl;
return 0;
}

现在,在window上用MinGW编译。

首先生成main.o文件

> gcc -c main.cpp

接着把main.o和函数库mylib.lib连接起来生成main.exe文件

> g++ -o main.exe main.o mylib.lib

注意link的顺序。函数库必须在主函数后面。另外,因为main.cpp是C++格式,所以link的时候要用g++编译器。gcc编译器会出现没有定义std::cout 这类的错误信息。

另外一个值得注意的是,虽然VC的.lib和Linux的.a格式是相同,都是一种归档文件格式。但是由于VC编译的程序中函数列表需要符号索引 (如果你用 reimp -s mylib.lib 察看VC的lib文件就会发现,函数名都被加了冗长的前后缀),所以vc的lib似乎无法直接在gcc上连接通过,同样的gcc的.a似乎也无法在vc上使用。虽然也有些文章讨论过lib和a的转换问题,配合使用reimp和dlltool命令转换。但是我的测试中发现转换后的库文件还是无法调用。如果有人成功的实现vc和gcc的静态库互换,请务必留言告诉我具体方法。

Shared libraries with Eclipse CDT and cygwin on Windows

Can you help me use shared libraries with Eclipse CDT, managed make and cygwin?“, I was asked yesterday. Read on for a list of common pitfalls and detailed instructions.

The instructions are based on the latest CDT release (Galileo) and cygwin (make 3.81, gcc 3.4.4). They are applicable to CDT’s managed make projects (that means CDT generates a makefile to build project).

The Pitfalls

It turns out that using a shared library on Windows is not as straight forward as you think. There are several pitfalls waiting for the unaware to fall into:

1. Recent versions of cygwin’s make insist on cygwin-style paths instead of windows paths (/cygdrive/c/foo instead of c:\foo). CDT is not picky about this and will generate an incorrect makefile, if you use workspace relative paths:

make all
example.d:1: *** multiple target patterns.  Stop.

The solution is to use absolute cygwin paths, such as: /cygdrive/c/workspace/mymath

2. The compiler and linker will not find the header files / library unless you set the appropriate parameters. The compiler needs an include path (-I). The linker needs the library name (-l) and library search path (-L). These settings are scattered in two places in the project properties. Their location is not obvious for a first-time user (details below).

3. When launching, Windows will not find the shared library (.dll) and greet you with the error pictured below. Unix users might try to set the LD_LIBRARY_PATH, which has no effect on Windows. The solution is to append the directory containing the .dll to the PATH (MSDN Article). Restart Eclipse for the changed PATH to take effect.

The remainder of the post walks you through the process of creating and using a simple shared library with cygwin and CDT.

Creating a Shared Library with CDT

Follow these instructions to create a shared library project with CDT.

1. File > New > Project > C Project > Next. Project name: mymath. Ensure “use default location” is checked. Note the location: c:\workspace\mymath — we’ll need it later. Project type: Shared Library; Empty Project. Hit Finish.

2. Create a header file (mymath.h) and the corresponding implementation (mymath.c). The example below provides a trivial function that multiplies two integers:

3. Afterwards save and hit Ctrl+B (or Project > Build All) to build the library. If cygwin is on your path, you should see a “Release” folder in your project containing the file “mymath.dll”.

4. For windows to find the shared library, you need to add the directory containing the .dll to your path. On Vista this can be done via: Control Panel > User Accounts > User Accounts > Change my environment variables.

5. Exit and restart Eclipse after changing the PATH. Otherwise the changes will not be picked up.

Using a Shared Library with CDT

Follow these instructions to use a shared library in a “managed make” CDT project.

1. File > New > Project > C Project > Next. Project name: example. Project type: Executable; Empty Project. Hit Finish.

2. In that project create a file named example.c with the following content:

3. Save and hit Ctrl+B to build the project. The second line will have an error: “mymath.h: No such file or directory”. We now have to adjust the compiler and linker settings so that the mymath.h / mymath.dll files are found during the build.

4. Select the “example” folder in the Project Explorer. Select “Project > Properties” from the menu. A dialog comes up. In the tree on the left open: “C/C++ General > Paths and Symbols”. In the “Languages” list, pick “GNU C”. Then hit “Add”. Enter the cygwin-style path to the “mymath” project: /cygdrive/c/workspace/mymath

Caution: When entering the path, don’t use the “Workspace” or “File system” buttons because the resulting path will not be compatible with cygwin’s make.

5. In the same dialog select: C/C++ Build > Settings in the tree on the left. In the “Tool Settings” tab find: “Cygwin C Linker > Libraries”. Hit the “+” icon in the “Libraries” section and add the name of the library: mymath

Caution: if your shared library starts with lib, omit the ‘lib’ prefix (i.e. libfoo becomes foo)

Hit the “+” icon in the “Library search path” section and add the path to the folder containing the shared library:/cygdrive/c/workspace/mymath/Debug

Hit OK.

6. You will be asked to rebuild the project. Answer “Yes”, but for some reason this will not rebuild your project. Hit Ctrl+B to rebuild. The error will go away.

Note: ignore the “unresolved inclusion” warning. It seems that CDT has trouble resolving cygwin-style paths. The generated make-file however will work as expected.

7. Select “example” in the Project Explorer. Right-click > Run As > Local C/C++ Application. At this point you see the result of the multiplication on the console. That means that the shared library was found and used successfully:

Kind regards,
Elias.

 

本文转自:http://eclipsesource.com/blogs/2010/03/03/shared-libraries-with-eclipse-cdt-and-cygwin-on-windows/

windows下实现微秒级的延时

1.微秒级的延时肯定不能基于消息(SetTimer函数),因为一出现消息堵塞等就会影响精
度,而且setTimer单位才是毫秒.实际响应时间可能要到55毫秒左右.

2.微秒级的延时也不能不能基于中断,VxD最快的时钟服务程序Set_Global_Time_Out函数
才能保证1毫秒的精度.其他挂接int 8H中断处理函数等,只能保证55ms的精度.(有时还不
能)

3.因此可以想到汇编下的那种基于循环执行语句的那种延时.但汇编那种代码不通用,跟
cpu的频率有关.

所以可以用windows下的几个函数来写出通用代
码.GetTickCout,timeGetTime,QueryPerformanceCounter.
1)GetTickCout响应只能保证55ms的精度
2)timeGetTime只能保证1ms的精度
3)而QueryPerformanceCounter函数不依赖计算中断的次数,而是靠读取别的硬件时钟来
实现的,可以有0.8微秒的精度.这个系统不支持windows 95以下的系统,不过这些系统应
该没人用了吧.呵呵.

下面是示例代码:
//LARGE_INTEGER类型类似一个64位的整型,是一个union,里面是LongLong类型和两个
long组成的结构体的union.
//QueryPerformanceFrequency函数得到你的计算机里高精度计时器每秒计时多少次,
//参数LARGE_INTEGER,返回false表示你的当前计算机硬件不支持高精度计时器.
//QueryPerformanceCounter函数得到当前计时器记了多少次.类似与GetTickCout.
#include
#include
using namespace std;

void main(){

int delayTime = 20; //微秒级的延时.

LARGE_INTEGER m_liPerfFreq={0};

if (!QueryPerformanceFrequency(&m_liPerfFreq))
{
cout <= delayTime)
break;

}
cout.precision(40);
cout << “开始” < cout << “结束” < cout< cout << “延时” <*1000000)/(double)m_liPerfFreq.QuadPart)<

}

因为windows是多任务系统,只要保证windows执行这段代码时不被其他进程打断,就可以
保证延时微秒级成功.出现打断的几率很小.一般可以不考虑.如果代码执行时间低于一
个时间片,那就100%不会被打断了.

在SDK中,可以用DWORD timeGetTime(VOID)函数获取系统时间,其返回值是毫秒单位的。可以用其实现延时功能的函数。
void Delay(DWORD delayTime)
{
DWORD delayTimeBegin;
DWORD delayTimeEnd;
delayTimeBegin=timeGetTime();
do
{
delayTimeEnd=timeGetTime();
}while(delayTimeEnd-delayTimeBegin }
注:在使用timeGetTime之前应先包含头文件#i nclude 或#i nclude 并在project->settings->link->Object/library modules中添加winmm.lib
也可以在文件头部添加 #pragma comment( lib,”winmm.lib” )
命令行:#pragma comment( lib,”xxx.lib” )时预编译处理指令,让vc将winmm.lib添加到工程中去进行编译。

在Windows平台下,常用的计时器有两种,一种是timeGetTime多媒体计时器,它可以提供毫秒级的计时。但这个精度对很多应用场合而言还是太粗糙了。另一种是QueryPerformanceCount计数器,随系统的不同可以提供微秒级的计数。对于实时图形处理、多媒体数据流处理、或者实时系统构造的程序员,善用QueryPerformanceCount/QueryPerformanceFrequency是一项基本功。

本文要介绍的,是另一种直接利用Pentium CPU内部时间戳进行计时的高精度计时手段。以下讨论主要得益于《Windows图形编程》一书,第15页-17页,有兴趣的读者可以直接参考该书。关于RDTSC指令的详细讨论,可以参考Intel产品手册。本文仅仅作抛砖之用。
在Intel Pentium以上级别的CPU中,有一个称为“时间戳(Time Stamp)”的部件,它以64位无符号整型数的格式,记录了自CPU上电以来所经过的时钟周期数。由于目前的CPU主频都非常高,因此这个部件可以达到纳秒级的计时精度。这个精确性是上述两种方法所无法比拟的。

在Pentium以上的CPU中,提供了一条机器指令RDTSC(Read Time Stamp Counter)来读取这个时间戳的数字,并将其保存在EDX:EAX寄存器对中。由于EDX:EAX寄存器对恰好是Win32平台下C++语言保存函数返回值的寄存器,所以我们可以把这条指令看成是一个普通的函数调用。像这样:

inline unsigned __int64 GetCycleCount()
{
__asm RDTSC
}

但是不行,因为RDTSC不被C++的内嵌汇编器直接支持,所以我们要用_emit伪指令直接嵌入该指令的机器码形式0X0F、0X31,如下:

inline unsigned __int64 GetCycleCount()
{
__asm _emit 0x0F
__asm _emit 0x31
}

以后在需要计数器的场合,可以像使用普通的Win32 API一样,调用两次GetCycleCount函数,比较两个返回值的差,像这样:

unsigned long t;
t = (unsigned long)GetCycleCount();
//Do Something time-intensive …
t -= (unsigned long)GetCycleCount();

《Windows图形编程》第15页编写了一个类,把这个计数器封装起来。有兴趣的读者可以去参考那个类的代码。作者为了更精确的定时,做了一点小小的改进,把执行RDTSC指令的时间,通过连续两次调用GetCycleCount函数计算出来并保存了起来,以后每次计时结束后,都从实际得到的计数中减掉这一小段时间,以得到更准确的计时数字。但我个人觉得这一点点改进意义不大。在我的机器上实测,这条指令大概花掉了几十到100多个周期,在Celeron 800MHz的机器上,这不过是十分之一微秒的时间。对大多数应用来说,这点时间完全可以忽略不计;而对那些确实要精确到纳秒数量级的应用来说,这个补偿也过于粗糙了。

这个方法的优点是:

1.高精度。可以直接达到纳秒级的计时精度(在1GHz的CPU上每个时钟周期就是一纳秒),这是其他计时方法所难以企及的。

2.成本低。timeGetTime 函数需要链接多媒体库winmm.lib,QueryPerformance* 函数根据MSDN的说明,需要硬件的支持(虽然我还没有见过不支持的机器)和KERNEL库的支持,所以二者都只能在Windows平台下使用(关于DOS平台下的高精度计时问题,可以参考《图形程序开发人员指南》,里面有关于控制定时器8253的详细说明)。但RDTSC指令是一条CPU指令,凡是i386平台下Pentium以上的机器均支持,甚至没有平台的限制(我相信i386版本UNIX和Linux下这个方法同样适用,但没有条件试验),而且函数调用的开销是最小的。

3.具有和CPU主频直接对应的速率关系。一个计数相当于1/(CPU主频Hz数)秒,这样只要知道了CPU的主频,可以直接计算出时间。这和QueryPerformanceCount不同,后者需要通过QueryPerformanceFrequency获取当前计数器每秒的计数次数才能换算成时间。

这个方法的缺点是:

1.现有的C/C++编译器多数不直接支持使用RDTSC指令,需要用直接嵌入机器码的方式编程,比较麻烦。

2.数据抖动比较厉害。其实对任何计量手段而言,精度和稳定性永远是一对矛盾。如果用低精度的timeGetTime来计时,基本上每次计时的结果都是相同的;而RDTSC指令每次结果都不一样,经常有几百甚至上千的差距。这是这种方法高精度本身固有的矛盾。

关于这个方法计时的最大长度,我们可以简单的用下列公式计算:

自CPU上电以来的秒数 = RDTSC读出的周期数 / CPU主频速率(Hz)

64位无符号整数所能表达的最大数字是1.8×10^19,在我的Celeron 800上可以计时大约700年(书中说可以在200MHz的Pentium上计时117年,这个数字不知道是怎么得出来的,与我的计算有出入)。无论如何,我们大可不必关心溢出的问题。

下面是几个小例子,简要比较了三种计时方法的用法与精度

//Timer1.cpp 使用了RDTSC指令的Timer类//KTimer类的定义可以参见《Windows图形编程》P15
//编译行:CL Timer1.cpp /link USER32.lib
#include
#include “KTimer.h”
main()
{
unsigned t;
KTimer timer;
timer.Start();
Sleep(1000);
t = timer.Stop();
printf(“Lasting Time: %d/n”,t);
}

//Timer2.cpp 使用了timeGetTime函数
//需包含,但由于Windows头文件错综复杂的关系
//简单包含比较偷懒:)
//编译行:CL timer2.cpp /link winmm.lib
#include
#include

main()
{
DWORD t1, t2;
t1 = timeGetTime();
Sleep(1000);
t2 = timeGetTime();
printf(“Begin Time: %u/n”, t1);
printf(“End Time: %u/n”, t2);
printf(“Lasting Time: %u/n”,(t2-t1));
}

//Timer3.cpp 使用了QueryPerformanceCounter函数
//编译行:CL timer3.cpp /link KERNEl32.lib
#include
#include

main()
{
LARGE_INTEGER t1, t2, tc;
QueryPerformanceFrequency(&tc);
printf(“Frequency: %u/n”, tc.QuadPart);
QueryPerformanceCounter(&t1);
Sleep(1000);
QueryPerformanceCounter(&t2);
printf(“Begin Time: %u/n”, t1.QuadPart);
printf(“End Time: %u/n”, t2.QuadPart);
printf(“Lasting Time: %u/n”,( t2.QuadPart- t1.QuadPart));
}

////////////////////////////////////////////////
//以上三个示例程序都是测试1秒钟休眠所耗费的时间
file://测/试环境:Celeron 800MHz / 256M SDRAM
// Windows 2000 Professional SP2
// Microsoft Visual C++ 6.0 SP5
////////////////////////////////////////////////

以下是Timer1的运行结果,使用的是高精度的RDTSC指令
Lasting Time: 804586872

以下是Timer2的运行结果,使用的是最粗糙的timeGetTime API
Begin Time: 20254254
End Time: 20255255
Lasting Time: 1001

以下是Timer3的运行结果,使用的是QueryPerformanceCount API
Frequency: 3579545
Begin Time: 3804729124
End Time: 3808298836
Lasting Time: 3569712

 

本文转自:http://blog.csdn.net/lhsxsh/article/details/4151393