[Source]
TFTP服务器的配置(RedHat)
作者: TFTP 点击: 2167
Redhat Linux下tftp服务器配置其实很容易。现以RedHat 7.3为例说明。
1. 如何启动tftp服务？1
执行ntsysv命令，选中tftp服务，再执行service xinetd restart命令。tftp服务就启动了，容易吧。
2. 如何下载文件？
先分析一下tftp的配置文件。
打开/etc/xinetd.d/tftp文件，如下所示：
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
per_source = 11
cps = 100 2
}
这就是tftp的配置文件，其中，server_args = -s /tftpboot是tftp服务器运行时的参数。-s /tftpboot表示服务器默认的目录是 /tftpboot,当你执行put a.txt时，文件会被放到服务器的/tftpboot/a.txt，省去你敲put a /tftpboot/的麻烦。你也可以加其它服务器运行参数到这，具体可以执行man tftpd命令查阅。
要下载文件，执行如下命令：（下载文件的默认路径为/tftpboot）
>tftp
>get
3. 如何上传文件？
上传文件时，需要先把服务器上的/tftpboot目录和这个目录下的文件变成可读可写权限，如下命令所示：
>cd /
>chmod 777 tftpboot
>cd tftpboot
>chmod 777 *
（这里用777权限有些高，可以用666，不过无所谓）
上传文件用put命令，但是默认情况下，只能上传远程tftp服务器已有的文件，例如，在tftp服务器上有/tftpboot /a.txt这个文件，你可以执行
>put a.txt
将本地的a.txt文件上传上去并覆盖服务器上的原文件。所以这个时候要先在服务器上建一个同名文件，如下命令所示：
>cd /tftpboot
>touch a.txt
>chmod 666 *
如果想上传原来目录中没有的文件，需要修改tftp服务器的配置文件并重起服务，如下操作所示：
打开/etc/xinetd.d/tftp 文件，在 server_args 增加-c参数，如下所示：
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot -c
per_source = 11
cps = 100 2
}
存盘退出。
重起tftp服务，如下所示：
>service xinetd restart
可以了。现在就可以上传新文件了。
Friday, March 19, 2010
Thursday, August 27, 2009
Fedora 11 ADSL
1. Download RP-PPPoE.
http://www.roaringpenguin.com/products/pppoe
2. Compile the package.
3. Setup
> pppoe-setup
Seednet DNS servers:
139.175.55.244
139.175.252.16
4. Start ADSL
> pppoe-start
5. Stop ADSL
> pppoe-stop
http://www.roaringpenguin.com/products/pppoe
2. Compile the package.
3. Setup
> pppoe-setup
Seednet DNS servers:
139.175.55.244
139.175.252.16
4. Start ADSL
> pppoe-start
5. Stop ADSL
> pppoe-stop
Tuesday, August 25, 2009
My X Window Applications
X Server on Win32 => Xming
SlickEdit => KScope
/usr/bin/kscope
UltraEdit => Kate
/usr/bin/kate
WinMerge => Meld
/opt/meld-1.3.1/meld
SVN Client => kdesvn
/usr/local/bin/kdesvn
SlickEdit => KScope
/usr/bin/kscope
UltraEdit => Kate
/usr/bin/kate
WinMerge => Meld
/opt/meld-1.3.1/meld
SVN Client => kdesvn
/usr/local/bin/kdesvn
Sunday, August 23, 2009
Vim Cscope
1. Generate filelist
> find -name '*.c' > cscope.files
> find -name '*.h' >> cscope.files
> find -name '*.cc' >> cscope.files
> find -name '*.cpp' >> cscope.files
2. Build Cscope database
> cscope -b -q -k
3. Use Vim to open source file. It's possible to use Cscope inside Vim.
: cs (help)
: cs find c aim_config_set_int (find all functions that call aim_config_set_int)
> find -name '*.c' > cscope.files
> find -name '*.h' >> cscope.files
> find -name '*.cc' >> cscope.files
> find -name '*.cpp' >> cscope.files
2. Build Cscope database
> cscope -b -q -k
3. Use Vim to open source file. It's possible to use Cscope inside Vim.
: cs (help)
: cs find c aim_config_set_int (find all functions that call aim_config_set_int)
Vim Function List
[Source]
ShowFunc.vim : Creates a list of all tags / functions from a window, all windows or buffers.
Default Key Mappings:
Run scan and open cwindow.
To reassign add the following to your .vimrc:
map NewKeyShowFunc
map! NewKeyShowFunc
For example to change the mapping to
map ShowFunc
map! ShowFunc
ShowFunc Window commands:
c Close cwindow.
h Display help dialog.
r Refresh.
s Change file sort, results will appear in either alphabetical or file order. (Default: file order)
t Change scan type, results will be from either the current file, all open windows or all open buffers. (Default: all open buffers)
install details
Put this file in the vim plugins directory (~/.vim/plugin/) to load it automatically, or load it with :so ShowFunc.vim.
ShowFunc.vim : Creates a list of all tags / functions from a window, all windows or buffers.
Default Key Mappings:
To reassign add the following to your .vimrc:
map NewKey
map! NewKey
For example to change the
map
map!
ShowFunc Window commands:
c Close cwindow.
h Display help dialog.
r Refresh.
s Change file sort, results will appear in either alphabetical or file order. (Default: file order)
t Change scan type, results will be from either the current file, all open windows or all open buffers. (Default: all open buffers)
install details
Put this file in the vim plugins directory (~/.vim/plugin/) to load it automatically, or load it with :so ShowFunc.vim.
Vim CTags
[Source]
[建立 tag 檔]
在所解開的 source code 目錄下，下以下指令：
> ctags -R *
[一般的 tag 使用]
如果就照上一節的方式產生 tag files，那麼只要在 source code 目錄下由 vim 去開啟檔案的話，會自動載入 tags 這個檔案，無需另行載入，否則要由 :set tags=your.tags 來指定 tags 檔。然後就是照一般使用 Vim 線上說明一樣，游標移到識別字或函數名上，按 Ctrl+]，要回到原處就按 Ctrl+T。
請注意，Vim 啟動時，工作目錄（vim 啟動時的所在目錄）名為 tags 的檔案會自動載入，$VIMRUNTIME/doc 及 $HOME/.vim/doc 目錄下的 tags 檔也會自動載入。而且，凡是載入的 tags 檔裡頭所有標誌文字都可以使用補全鍵來補全，別忘了這個好用的功能。
[建立 tag 檔]
在所解開的 source code 目錄下，下以下指令：
> ctags -R *
[一般的 tag 使用]
如果就照上一節的方式產生 tag files，那麼只要在 source code 目錄下由 vim 去開啟檔案的話，會自動載入 tags 這個檔案，無需另行載入，否則要由 :set tags=your.tags 來指定 tags 檔。然後就是照一般使用 Vim 線上說明一樣，游標移到識別字或函數名上，按 Ctrl+]，要回到原處就按 Ctrl+T。
請注意，Vim 啟動時，工作目錄（vim 啟動時的所在目錄）名為 tags 的檔案會自動載入，$VIMRUNTIME/doc 及 $HOME/.vim/doc 目錄下的 tags 檔也會自動載入。而且，凡是載入的 tags 檔裡頭所有標誌文字都可以使用補全鍵來補全，別忘了這個好用的功能。
Friday, March 13, 2009
Friday, February 20, 2009
Sunday, February 15, 2009
Build DLL with Cygwin
[source]
[Building and Using DLLs]
> Could you please tell me where I might read more on
> __declspec(dllexport) and __declspec(dllimport)
>
> I do not understand how to use these....
That's a complicated question. Essentially, the MS engineers were on crack
when they designed Windows DLLs. When compiling code to become a DLL, you
must explicitly tell the compiler which symbols(1) will be exported(2) from
the DLL in the declarations(3) of the symbols. When compiling code that
will use a DLL, you must explicitly tell the compiler which symbols will be
imported from DLLs as opposed to statically linked into your program. At
first this doesn't sound so bad, but essentially it means you need three
different versions of all of your declarations for:
1. compiling code to become the DLL
2. compiling code to use the DLL
3. compiling code that will be statically linked
Consider the case of function "foo()" defined in "foo.c" that will be used
in the "main()" of a program "bar.exe" that is defined in "bar.c" . If foo()
is statically linked into bar.exe, your files might look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
/* definition of foo() */
int foo() { return 1; }
-------------
Compile foo.c:
gcc -c foo.c -o foo.o
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
int main() { return foo(); }
--------------
Compile bar.c and link foo.o into bar.exe statically:
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
However, if foo() should go into a DLL, your files need to look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllexport) int foo(); /* exporting foo() from this DLL */
/* definition of foo() */
int foo() { return 1; }
-------------
Make a DLL from foo.c:
gcc -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
This will create the DLL (foo.dll) and the import library for the DLL
(libfoo.import.a).
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllimport) int foo(); /* importing foo() from DLL */
int main() { return foo(); }
--------------
Compile and link bar.exe to use foo.dll (via its import library):
gcc -c bar.c -o bar.o
gcc bar.o libfoo.import.a -o bar.exe
bar.exe now uses foo.dll.
So we have three different possible declarations of the function foo():
1. int foo(); /* static linking */
2. __declspec(dllexport) int foo(); /* making DLL with foo() in it */
3. __declspec(dllimport) int foo(); /* importing foo() from DLL */
Which one we use depends on how we are using foo(). The real problem is
that most people don't want to deal with three sets of declarations but want
to just have one header file which is used in all cases. To solve this you
could do something like this:
--- foo.h ---
#if defined(MAKEDLL)
# define INTERFACE __declspec(dllexport)
#elif defined(USEDLL)
# define INTERFACE __declspec(dllimport)
#else
# define INTERFACE
#endif
INTERFACE int foo();
-------------
--- foo.c ---
#include "foo.h"
int foo() { return 1; }
-------------
--- bar.c ---
#include "foo.h"
int main() { return foo(); }
--------------
Now you are only maintaining the declaration of foo() in one place: foo.h.
To compile bar.exe to statically link in foo():
gcc -c foo.c -o foo.o
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
To compile foo() into a DLL:
gcc -DMAKEDLL -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
To compile bar.exe to use the DLL:
gcc -DUSEDLL -c bar.c -o bar.exe
gcc bar.o libfoo.import.a -o bar.exe
That's all there is to it.
(1)functions, methods and variables in structs / classes, external
variables
(2)available to programs that use the DLL
(3)function prototypes, class definitions, etc.-- the stuff found in
your header files
Hope this helps,
Carl Thompson
PS: for structs / classes instead of doing this:
class foo {
public:
INTERFACE int bar;
INTERFACE int baz;
}
You can do this:
class INTERFACE foo {
public:
int bar;
int baz;
}
They are both equivalent, but the second way is cleaner.
PPS: I've heard you can do the same thing using separate ".DEF" files,
but I don't know about that.
PPPS: None of this is necessary with reasonable operating systems, such
as Unix or Linux. The compiler and linker automatically export
and import all externally visible symbols when building or using
DLLs (shared libraries). You don't even need a separate import
library.
> ...
[Building and Using DLLs]
> Could you please tell me where I might read more on
> __declspec(dllexport) and __declspec(dllimport)
>
> I do not understand how to use these....
That's a complicated question. Essentially, the MS engineers were on crack
when they designed Windows DLLs. When compiling code to become a DLL, you
must explicitly tell the compiler which symbols(1) will be exported(2) from
the DLL in the declarations(3) of the symbols. When compiling code that
will use a DLL, you must explicitly tell the compiler which symbols will be
imported from DLLs as opposed to statically linked into your program. At
first this doesn't sound so bad, but essentially it means you need three
different versions of all of your declarations for:
1. compiling code to become the DLL
2. compiling code to use the DLL
3. compiling code that will be statically linked
Consider the case of function "foo()" defined in "foo.c" that will be used
in the "main()" of a program "bar.exe" that is defined in "bar.c" . If foo()
is statically linked into bar.exe, your files might look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
/* definition of foo() */
int foo() { return 1; }
-------------
Compile foo.c:
gcc -c foo.c -o foo.o
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
int foo();
int main() { return foo(); }
--------------
Compile bar.c and link foo.o into bar.exe statically:
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
However, if foo() should go into a DLL, your files need to look like this:
--- foo.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllexport) int foo(); /* exporting foo() from this DLL */
/* definition of foo() */
int foo() { return 1; }
-------------
Make a DLL from foo.c:
gcc -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
This will create the DLL (foo.dll) and the import library for the DLL
(libfoo.import.a).
--- bar.c ---
/* declaration (AKA prototype) of foo(), usually found in .h file */
__declspec(dllimport) int foo(); /* importing foo() from DLL */
int main() { return foo(); }
--------------
Compile and link bar.exe to use foo.dll (via its import library):
gcc -c bar.c -o bar.o
gcc bar.o libfoo.import.a -o bar.exe
bar.exe now uses foo.dll.
So we have three different possible declarations of the function foo():
1. int foo(); /* static linking */
2. __declspec(dllexport) int foo(); /* making DLL with foo() in it */
3. __declspec(dllimport) int foo(); /* importing foo() from DLL */
Which one we use depends on how we are using foo(). The real problem is
that most people don't want to deal with three sets of declarations but want
to just have one header file which is used in all cases. To solve this you
could do something like this:
--- foo.h ---
#if defined(MAKEDLL)
# define INTERFACE __declspec(dllexport)
#elif defined(USEDLL)
# define INTERFACE __declspec(dllimport)
#else
# define INTERFACE
#endif
INTERFACE int foo();
-------------
--- foo.c ---
#include "foo.h"
int foo() { return 1; }
-------------
--- bar.c ---
#include "foo.h"
int main() { return foo(); }
--------------
Now you are only maintaining the declaration of foo() in one place: foo.h.
To compile bar.exe to statically link in foo():
gcc -c foo.c -o foo.o
gcc -c bar.c -o bar.o
gcc foo.o bar.o -o bar.exe
To compile foo() into a DLL:
gcc -DMAKEDLL -c foo.c -o foo.o
gcc -Wl,--out-implib,libfoo.import.a -shared -o foo.dll foo.o
To compile bar.exe to use the DLL:
gcc -DUSEDLL -c bar.c -o bar.exe
gcc bar.o libfoo.import.a -o bar.exe
That's all there is to it.
(1)functions, methods and variables in structs / classes, external
variables
(2)available to programs that use the DLL
(3)function prototypes, class definitions, etc.-- the stuff found in
your header files
Hope this helps,
Carl Thompson
PS: for structs / classes instead of doing this:
class foo {
public:
INTERFACE int bar;
INTERFACE int baz;
}
You can do this:
class INTERFACE foo {
public:
int bar;
int baz;
}
They are both equivalent, but the second way is cleaner.
PPS: I've heard you can do the same thing using separate ".DEF" files,
but I don't know about that.
PPPS: None of this is necessary with reasonable operating systems, such
as Unix or Linux. The compiler and linker automatically export
and import all externally visible symbols when building or using
DLLs (shared libraries). You don't even need a separate import
library.
> ...
Creating a shared and static library with GCC
[source]
Here's a summary on how to create a shared and a static library with gcc. The goal is to show the basic steps. I do not want to go into the hairy details. It should be possible to use this page as a reference.
These examples were tested and run on cygwin/Windows.
The code for the library
This is the code that goes into the library. It exhibits one single function that takes two doubles and calculates their mean value and returns it.
calc_mean.c
//#include
double mean(double a, double b) {
return (a+b) / 2;
}
The header file
Of course, we need a header file.
calc_mean.h
double mean(double, double);
Creating the static library
A static library is basically a set of object files that were copied into a single file. This single file is the static library. The static file is created with the archiver (ar).
First, calc_mean.c is turned into an object file:
gcc -c calc_mean.c -o calc_mean.o
Then, the archiver (ar) is invoked to produce a static library (named libmean.a) out of the object file calc_mean.o.
ar rcs libmean.a calc_mean.o
Note: the library must start with the three letters lib and have the suffix .a.
Creating the shared library
As with static libraries, an object file is created. The -fPIC option tells gcc to create position independant code which is necessary for shared libraries. Note also, that the object file created for the static library will be overwritten. That's not bad, however, because we have a static library that already contains the needed object file.
gcc -c -fPIC calc_mean.c -o calc_mean.o
For some reason, gcc says:
cc1: warning: -fPIC ignored for target (all code is position independent)
It looks like -fPIC is not necessary on x86, but all manuals say, it's needed, so I use it too.
Now, the shared library is created
gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1 calc_mean.o
Note: the library must start with the three letter lib.
The programm using the library
This is the program that uses the calc_mean library. Once, we will link it against the static library and once against the shared library.
main.c
#include
#include "calc_mean.h"
int main(int argc, char* argv[]) {
double v1, v2, m;
v1 = 5.2;
v2 = 7.9;
m = mean(v1, v2);
printf("The mean of %3.2f and %3.2f is %3.2f\n", v1, v2, m);
return 0;
}
Linking against static library
gcc -static main.c -L. -lmean -o statically_linked
Note: the first three letters (the lib) must not be specified, as well as the suffix (.a)
Linking against shared library
gcc main.c -o dynamically_linked -L. -lmean
Note: the first three letters (the lib) must not be specified, as well as the suffix (.so)
Executing the dynamically linked programm
LD_LIBRARY_PATH=.
./dynamically_linked
Here's a summary on how to create a shared and a static library with gcc. The goal is to show the basic steps. I do not want to go into the hairy details. It should be possible to use this page as a reference.
These examples were tested and run on cygwin/Windows.
The code for the library
This is the code that goes into the library. It exhibits one single function that takes two doubles and calculates their mean value and returns it.
calc_mean.c
//#include
double mean(double a, double b) {
return (a+b) / 2;
}
The header file
Of course, we need a header file.
calc_mean.h
double mean(double, double);
Creating the static library
A static library is basically a set of object files that were copied into a single file. This single file is the static library. The static file is created with the archiver (ar).
First, calc_mean.c is turned into an object file:
gcc -c calc_mean.c -o calc_mean.o
Then, the archiver (ar) is invoked to produce a static library (named libmean.a) out of the object file calc_mean.o.
ar rcs libmean.a calc_mean.o
Note: the library must start with the three letters lib and have the suffix .a.
Creating the shared library
As with static libraries, an object file is created. The -fPIC option tells gcc to create position independant code which is necessary for shared libraries. Note also, that the object file created for the static library will be overwritten. That's not bad, however, because we have a static library that already contains the needed object file.
gcc -c -fPIC calc_mean.c -o calc_mean.o
For some reason, gcc says:
cc1: warning: -fPIC ignored for target (all code is position independent)
It looks like -fPIC is not necessary on x86, but all manuals say, it's needed, so I use it too.
Now, the shared library is created
gcc -shared -Wl,-soname,libmean.so.1 -o libmean.so.1.0.1 calc_mean.o
Note: the library must start with the three letter lib.
The programm using the library
This is the program that uses the calc_mean library. Once, we will link it against the static library and once against the shared library.
main.c
#include
#include "calc_mean.h"
int main(int argc, char* argv[]) {
double v1, v2, m;
v1 = 5.2;
v2 = 7.9;
m = mean(v1, v2);
printf("The mean of %3.2f and %3.2f is %3.2f\n", v1, v2, m);
return 0;
}
Linking against static library
gcc -static main.c -L. -lmean -o statically_linked
Note: the first three letters (the lib) must not be specified, as well as the suffix (.a)
Linking against shared library
gcc main.c -o dynamically_linked -L. -lmean
Note: the first three letters (the lib) must not be specified, as well as the suffix (.so)
Executing the dynamically linked programm
LD_LIBRARY_PATH=.
./dynamically_linked
Monday, January 26, 2009
Find Files in Linux
find -name 'mypage.htm'
In the above command the system would search for any file named mypage.htm in the current directory and any subdirectory.
find / -name 'mypage.htm'
In the above example the system would search for any file named mypage.htm on the root and all subdirectories from the root.
find -name 'file*'
In the above example the system would search for any file beginning with file in the current directory and any subdirectory.
find -name '*' -size +1000k
In the above example the system would search for any file that is larger then 1000k.
( expression )
True if expression is true.
! expression
Negation of a primary; the unary NOT operator.
expression [-a] expression
Conjunction of primaries; the AND operator is implied by the juxtaposition of two primaries or made explicit by the optional -a operator. The second expression shall not be evaluated if the first expression is false.
expression -o expression
Alternation of primaries; the OR operator. The second expression shall not be evaluated if the first expression is true.
find \( -name 'hello*' -a -name '*.sh' \)
find \( -name '*.sh' -o -name '*.txt' \)
對找到檔案做處理: -exec
有時我們會把找到的特定檔做特別的處理 ,像是刪除和移動就可以用 exec來處理
請看範例。請注意指令的後面要加 \; 來做結束
而此範例是把找到的檔案cp 到user的家目錄下的txt目錄裡面,在這裡的重點是 {}就是找到檔案的代號, 而exec 後面就是要操作的命令
find /tmp/ -type f -name "*.txt" -exec cp {} ~/txt \;
In the above command the system would search for any file named mypage.htm in the current directory and any subdirectory.
find / -name 'mypage.htm'
In the above example the system would search for any file named mypage.htm on the root and all subdirectories from the root.
find -name 'file*'
In the above example the system would search for any file beginning with file in the current directory and any subdirectory.
find -name '*' -size +1000k
In the above example the system would search for any file that is larger then 1000k.
( expression )
True if expression is true.
! expression
Negation of a primary; the unary NOT operator.
expression [-a] expression
Conjunction of primaries; the AND operator is implied by the juxtaposition of two primaries or made explicit by the optional -a operator. The second expression shall not be evaluated if the first expression is false.
expression -o expression
Alternation of primaries; the OR operator. The second expression shall not be evaluated if the first expression is true.
find \( -name 'hello*' -a -name '*.sh' \)
find \( -name '*.sh' -o -name '*.txt' \)
對找到檔案做處理: -exec
有時我們會把找到的特定檔做特別的處理 ,像是刪除和移動就可以用 exec來處理
請看範例。請注意指令的後面要加 \; 來做結束
而此範例是把找到的檔案cp 到user的家目錄下的txt目錄裡面,在這裡的重點是 {}就是找到檔案的代號, 而exec 後面就是要操作的命令
find /tmp/ -type f -name "*.txt" -exec cp {} ~/txt \;
My First Makefile
[Makefile]
# Makefile Test
include FileList
CC = gcc
CFG = release
OBJS = $(addsuffix .o, $(basename $(SOURCE)))
EXE = hello
# release
CFLAGS_RELEASE = -O2
DFLAGS_RELEASE = LINUX OS_POSIX
# debug
CFLAGS_DEBUG =
DFLAGS_DEBUG = _DEBUG LINUX OS_POSIX
# switch CFG
ifeq ($(CFG), release)
CFLAGS = $(CFLAGS_RELEASE)
DFLAGS = $(addprefix -D, $(DFLAGS_RELEASE))
else
CFLAGS = $(CFLAGS_DEBUG)
DFLAGS = $(addprefix -D, $(DFLAGS_DEBUG))
endif
# make rules
all: $(EXE)
$(EXE): $(OBJS)
$(CC) $(CFLAGS) -o $@ $^
%.o: %.c
$(CC) $(CFLAGS) $(DFLAGS) -c $<
clean:
rm -f $(EXE) $(OBJS)
[filelist.sh]
#!/bin/sh
FileList=`find -name '*.c'`
echo "SOURCE =" '\'
for i in $FileList; do
echo $i '\'
done
echo
# Makefile Test
include FileList
CC = gcc
CFG = release
OBJS = $(addsuffix .o, $(basename $(SOURCE)))
EXE = hello
# release
CFLAGS_RELEASE = -O2
DFLAGS_RELEASE = LINUX OS_POSIX
# debug
CFLAGS_DEBUG =
DFLAGS_DEBUG = _DEBUG LINUX OS_POSIX
# switch CFG
ifeq ($(CFG), release)
CFLAGS = $(CFLAGS_RELEASE)
DFLAGS = $(addprefix -D, $(DFLAGS_RELEASE))
else
CFLAGS = $(CFLAGS_DEBUG)
DFLAGS = $(addprefix -D, $(DFLAGS_DEBUG))
endif
# make rules
all: $(EXE)
$(EXE): $(OBJS)
$(CC) $(CFLAGS) -o $@ $^
%.o: %.c
$(CC) $(CFLAGS) $(DFLAGS) -c $<
clean:
rm -f $(EXE) $(OBJS)
[filelist.sh]
#!/bin/sh
FileList=`find -name '*.c'`
echo "SOURCE =" '\'
for i in $FileList; do
echo $i '\'
done
echo
Tuesday, December 30, 2008
Unicode and RichEditCtrl
[source]
Unicode and RichEditCtrl
Unicode Strings in MFC
The easiest way to deal with Unicode strings is to use CStringW class. As it is, CStringW can edit Unicode strings. Another option is to use char* equivalent wide-byte type in MFC called LPWSTR.
Writing and reading Unicode strings to and from controls in MFC is not exactly as straight forward. GetDlgItemText and SetDlgItemText only take single byte character strings. This page explains how to send messages to set and retrieve Unicode strings to the controls without the use of those functions.
Take a look at the following functions. Those functions read and write Unicode strings from and to MFC controls (RichEditCtrl). Sending messages requires several steps. First is to specify the type of the message. The type of the message, the codepage, and other optional settings are set to a structure called GETTEXTEX and SETTEXTEX. Then calculate and prepare space to store the results.
LPWSTR GetUnicodeString(UINT id)
{
CRichEditCtrl* edit=(CRichEditCtrl*)GetDlgItem(id);
int nLength = edit->GetTextLengthEx(GTL_DEFAULT,1200);
LPWSTR lpszWChar = new WCHAR[nLength+1];
GETTEXTEX getTextEx;
getTextEx.cb=(nLength+1)*sizeof(WCHAR);
getTextEx.codepage=1200;
getTextEx.flags=GT_DEFAULT;
getTextEx.lpDefaultChar=NULL;
getTextEx.lpUsedDefChar=NULL;
edit->SendMessage(EM_GETTEXTEX, (WPARAM)&getTextEx, (LPARAM)lpszWChar);
return lpszWChar;
}
void SetUnicodeString(UINT id, LPWSTR str)
{
SETTEXTEX setTextEx;
setTextEx.codepage=1200;
setTextEx.flags=ST_DEFAULT;
CRichEditCtrl *caption=(CRichEditCtrl*)GetDlgItem(id);
if(caption!=NULL)
caption->SendMessage(EM_SETTEXTEX, (WPARAM)&setTextEx, (LPARAM)str);
}
The usage of GetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control.
CStringW str=GetUnicodeString(IDC_RICHEDITCTRL);
Likewise, the usage of SetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control, and the Unicode string to be set to the control.
SetUnicodeString(IDC_RICHEDITCTRL,str);
Unicode and RichEditCtrl
Unicode Strings in MFC
The easiest way to deal with Unicode strings is to use CStringW class. As it is, CStringW can edit Unicode strings. Another option is to use char* equivalent wide-byte type in MFC called LPWSTR.
Writing and reading Unicode strings to and from controls in MFC is not exactly as straight forward. GetDlgItemText and SetDlgItemText only take single byte character strings. This page explains how to send messages to set and retrieve Unicode strings to the controls without the use of those functions.
Take a look at the following functions. Those functions read and write Unicode strings from and to MFC controls (RichEditCtrl). Sending messages requires several steps. First is to specify the type of the message. The type of the message, the codepage, and other optional settings are set to a structure called GETTEXTEX and SETTEXTEX. Then calculate and prepare space to store the results.
LPWSTR GetUnicodeString(UINT id)
{
CRichEditCtrl* edit=(CRichEditCtrl*)GetDlgItem(id);
int nLength = edit->GetTextLengthEx(GTL_DEFAULT,1200);
LPWSTR lpszWChar = new WCHAR[nLength+1];
GETTEXTEX getTextEx;
getTextEx.cb=(nLength+1)*sizeof(WCHAR);
getTextEx.codepage=1200;
getTextEx.flags=GT_DEFAULT;
getTextEx.lpDefaultChar=NULL;
getTextEx.lpUsedDefChar=NULL;
edit->SendMessage(EM_GETTEXTEX, (WPARAM)&getTextEx, (LPARAM)lpszWChar);
return lpszWChar;
}
void SetUnicodeString(UINT id, LPWSTR str)
{
SETTEXTEX setTextEx;
setTextEx.codepage=1200;
setTextEx.flags=ST_DEFAULT;
CRichEditCtrl *caption=(CRichEditCtrl*)GetDlgItem(id);
if(caption!=NULL)
caption->SendMessage(EM_SETTEXTEX, (WPARAM)&setTextEx, (LPARAM)str);
}
The usage of GetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control.
CStringW str=GetUnicodeString(IDC_RICHEDITCTRL);
Likewise, the usage of SetUnicodeString above is shown below. Specify the ID of the RichEditCtrl control, and the Unicode string to be set to the control.
SetUnicodeString(IDC_RICHEDITCTRL,str);
Friday, December 19, 2008
Visual Studio 2005 SP1
From Microsoft Download Center
Visual Studio® 2005 Team Suite SP1
Visual C++ 2005 SP1 Redistributable Package (x86)
Visual Studio 2005 Service Pack 1 GDIPLUS.DLL Security Update
Integrate VS 2005 & SP1:
[HowTo]整合Visual Studio 2005與Service Pack 1
Visual Studio® 2005 Team Suite SP1
Visual C++ 2005 SP1 Redistributable Package (x86)
Visual Studio 2005 Service Pack 1 GDIPLUS.DLL Security Update
Integrate VS 2005 & SP1:
[HowTo]整合Visual Studio 2005與Service Pack 1
Monday, December 15, 2008
C Restrict Pointers
[Source]
One of the new features in the recently approved C standard C99, is the restrict pointer qualifier. This qualifier can be applied to a data pointer to indicate that, during the scope of that pointer declaration, all data accessed through it will be accessed only through that pointer but not through any other pointer. The 'restrict' keyword thus enables the compiler to perform certain optimizations based on the premise that a given object cannot be changed through another pointer. Now you're probably asking yourself, "doesn't const already guarantee that?" No, it doesn't. The qualifier const ensures that a variable cannot be changed through a particular pointer. However, it's still possible to change the variable through a different pointer. For example:
void f (const int* pci, int *pi;); // is *pci immutable?
{
(*pi)+=1; // not necessarily: n is incremented by 1
*pi = (*pci) + 2; // n is incremented by 2
}
int n;
f( &n, &n);
In this example, both pci and pi point to the same variable, n. You can't change n's value through pci but you can change it using pi. Therefore, the compiler isn't allowed to optimize memory access for *pci by preloading n's value. In this example, the compiler indeed shouldn't preload n because its value changes three times during the execution of f(). However, there are situations in which a variable is accessed only through a single pointer. For example:
FILE *fopen(const char * filename, const char * mode);
The name of the file and its open mode are accessed through unique pointers in fopen(). Therefore, it's possible to preload the values to which the pointers are bound. Indeed, the C99 standard revised the prototype of the function fopen() to the following:
/* new declaration of fopen() in */
FILE *fopen(const char * restrict filename,
const char * restrict mode);
Similar changes were applied to the entire standard C library: printf(), strcpy() and many other functions now take restrict pointers:
int printf(const char * restrict format, ...);
char *strcpy(char * restrict s1, const char * restrict s2);
C++ doesn't support restrict yet. However, since many C++ compilers are also C compilers, it's likely that this feature will be added to most C++ compilers too.
Danny Kalev
One of the new features in the recently approved C standard C99, is the restrict pointer qualifier. This qualifier can be applied to a data pointer to indicate that, during the scope of that pointer declaration, all data accessed through it will be accessed only through that pointer but not through any other pointer. The 'restrict' keyword thus enables the compiler to perform certain optimizations based on the premise that a given object cannot be changed through another pointer. Now you're probably asking yourself, "doesn't const already guarantee that?" No, it doesn't. The qualifier const ensures that a variable cannot be changed through a particular pointer. However, it's still possible to change the variable through a different pointer. For example:
void f (const int* pci, int *pi;); // is *pci immutable?
{
(*pi)+=1; // not necessarily: n is incremented by 1
*pi = (*pci) + 2; // n is incremented by 2
}
int n;
f( &n, &n);
In this example, both pci and pi point to the same variable, n. You can't change n's value through pci but you can change it using pi. Therefore, the compiler isn't allowed to optimize memory access for *pci by preloading n's value. In this example, the compiler indeed shouldn't preload n because its value changes three times during the execution of f(). However, there are situations in which a variable is accessed only through a single pointer. For example:
FILE *fopen(const char * filename, const char * mode);
The name of the file and its open mode are accessed through unique pointers in fopen(). Therefore, it's possible to preload the values to which the pointers are bound. Indeed, the C99 standard revised the prototype of the function fopen() to the following:
/* new declaration of fopen() in
FILE *fopen(const char * restrict filename,
const char * restrict mode);
Similar changes were applied to the entire standard C library: printf(), strcpy() and many other functions now take restrict pointers:
int printf(const char * restrict format, ...);
char *strcpy(char * restrict s1, const char * restrict s2);
C++ doesn't support restrict yet. However, since many C++ compilers are also C compilers, it's likely that this feature will be added to most C++ compilers too.
Danny Kalev
Friday, December 05, 2008
WinXP FAT32 與 NTFS 之間的轉換
[FAT32 -> NTFS]
保留資料
1) > convert D:/FS:NTFS /V
2) Partition Magic
不保留資料
> format D:/FS:NTFS
[NTFS -> FAT32]
保留資料
Partition Magic
不保留資料
> format D:/FS:FAT32
保留資料
1) > convert D:/FS:NTFS /V
2) Partition Magic
不保留資料
> format D:/FS:NTFS
[NTFS -> FAT32]
保留資料
Partition Magic
不保留資料
> format D:/FS:FAT32
Wednesday, December 03, 2008
POSIX Threads Programming
https://computing.llnl.gov/tutorials/pthreads/
Books:
- Programming with POSIX Threads
- Multithreading Programming Techniques
- Getting Started With POSIX Threads
Books:
- Programming with POSIX Threads
- Multithreading Programming Techniques
- Getting Started With POSIX Threads
Saturday, July 05, 2008
Set Environment Variables for VC
If we install more than 1 version of VC compilers, it's better to set environment variable to the version that we'd like to use for compiling programs under command mode (e.g. use nmake with makefile):
VC6:
$(VS_Path)\VC98\Bin\vcvars32.bat
VC7 (2003) / VC8 (2005) / VC9 (2008):
$(VS_Path)\Common7\Tools\vsvars32.bat
VC6:
$(VS_Path)\VC98\Bin\vcvars32.bat
VC7 (2003) / VC8 (2005) / VC9 (2008):
$(VS_Path)\Common7\Tools\vsvars32.bat
Sunday, March 02, 2008
精通 vi - Chap 3 快速移動位置
1. 移動
往下捲動一個螢幕 ^F
往上捲動一個螢幕 ^B
往下捲動半個螢幕 ^D
往上捲動半個螢幕 ^U
往下捲動一行 ^E
往上捲動一行 ^Y
將本行移到螢幕頂端 z [Enter]
將本行移到螢幕中間 z.
將本行移到螢幕最後 z-
移到螢幕頂端 H
移到螢幕中間 M
移到螢幕最後 L
移到下一行首 + 或 [Enter]
移到上一行首 -
移到句子開頭 (
移到下一句子開頭 )
移到段落開頭 {
移到下一段落開頭 }
到第 n 行 nG
到最後一行 G
2. 搜尋
向下找 /pattern
向上找 ?pattern
同一方向重複找 n
相反方向重複找 N
重複上一搜尋命令，方向相同 ;
重複上一搜尋命令，方向相反 ,
3. 其它
估計目前所在位置的百分比 ^G
往下捲動一個螢幕 ^F
往上捲動一個螢幕 ^B
往下捲動半個螢幕 ^D
往上捲動半個螢幕 ^U
往下捲動一行 ^E
往上捲動一行 ^Y
將本行移到螢幕頂端 z [Enter]
將本行移到螢幕中間 z.
將本行移到螢幕最後 z-
移到螢幕頂端 H
移到螢幕中間 M
移到螢幕最後 L
移到下一行首 + 或 [Enter]
移到上一行首 -
移到句子開頭 (
移到下一句子開頭 )
移到段落開頭 {
移到下一段落開頭 }
到第 n 行 nG
到最後一行 G
2. 搜尋
向下找 /pattern
向上找 ?pattern
同一方向重複找 n
相反方向重複找 N
重複上一搜尋命令，方向相同 ;
重複上一搜尋命令，方向相反 ,
3. 其它
估計目前所在位置的百分比 ^G
精通 vi - Chap 2 簡單的文字編輯
1. 編輯命令
文字物件 更改 刪除 複製
一個單字 cw dw yw
兩個單字，不含標點 2cW 2dW 2yW
往回三個單字 3cb 3db 3yb
一整行 cc dd yy
到一行末 c$ d$ y$
到一行首 c0 d0 y0
單一字元 r x y1
五個字元 5s 5x 5y1
貼上 p 或 P
2. 游標移動
左下上右 h, j, k, l
到下一行首 +
到上一行首 -
到單字結尾 e
往後一個單字 w
往前一個單字 b
到本行末 $
到本行首 0
3. 建立與處理文字
在游標所在位置插入文字 i
在行首插入文字 I
在游標所在位置附加文字 a
在行尾附加文字 A
在游標下一行開啟新行 o
在游標上一行開啟新行 O
刪除一行並代換文字 S
用新文字覆蓋現存的文字 R
合併此行與下一行 J
切換大小寫 ~
重複上一動作 .
還原上一動作 u
還原一整行的編輯 U
文字物件 更改 刪除 複製
一個單字 cw dw yw
兩個單字，不含標點 2cW 2dW 2yW
往回三個單字 3cb 3db 3yb
一整行 cc dd yy
到一行末 c$ d$ y$
到一行首 c0 d0 y0
單一字元 r x y1
五個字元 5s 5x 5y1
貼上 p 或 P
2. 游標移動
左下上右 h, j, k, l
到下一行首 +
到上一行首 -
到單字結尾 e
往後一個單字 w
往前一個單字 b
到本行末 $
到本行首 0
3. 建立與處理文字
在游標所在位置插入文字 i
在行首插入文字 I
在游標所在位置附加文字 a
在行尾附加文字 A
在游標下一行開啟新行 o
在游標上一行開啟新行 O
刪除一行並代換文字 S
用新文字覆蓋現存的文字 R
合併此行與下一行 J
切換大小寫 ~
重複上一動作 .
還原上一動作 u
還原一整行的編輯 U
Subscribe to:
Posts (Atom)