처음 Emulator를 실행하면 Internet이 안될수가 있다.

이때에는 Internet 설정을 맞추어 주어야만 한다.

start -> settings ->connections Tab -> connections 를 누른다.

My Work Network 에서

Set up my proxy server 를 누른다.

This network connects to the Internet에 체크한 다음

모두 OK하고 나오면 Internet이 사용가능하다.
SDK 다운로드는 본 블로그안에 아래에서 다운받을 수 있습니다.


SDK를 Install 하고 나면 eMbedded Visual C++(이하 EVC++) 를 Install 합니다.

Emulator는 SDK를 Install하면 안에 있습니다.

이제 EVC++에서 Emulator를 사용하기 위한 설정을 알아봅시다.




(1) EVC++ 실행 및 Configure Platform Manager 실행



메뉴 Tools -> Configure Platform Manager를 실행시킵니다.



(2) Pocket PC 2003 Emulation 선택후 Properties 버튼 클릭




(3) 설정 변경



Transport : Microsoft ActiveSync를 TCP/IP Transport for Windows CE 로 바꿉니다.

Start Server : Microsoft ActiveSync를 Emulator Startup Server 로 바꿉니다.




(4) Test하기


Test를 누르면 Emulation을 찾습니다.



Emulator를 찾으면 설정이 됩니다.



동시에 Emulator가 동작하게 됩니다.





(5) EVC++에서의 설정 확인



EVC를 보면 위와 같이 2003 Emulator로 설정되어있음을 볼수 있다.
Path : http://msdn.microsoft.com/mobility/windowsmobile/downloads/default.aspx

위 Site에서 자신에게 맞는 환경을 선택하여

eMbedded Visual C++ 를 version에 맞게 다운 받는다.

Service Pack 도 다운 받는 것이 좋다.

이때 자신에게 맞는 SDK를 다운 받아 설치하는 것도 잊어서는 안된다.

선택의 종류는 다음과 같다.



한 task는 mm_struct를 가지고 있다. (struct mm_struct* mm;)

mm은 Memory Management의 약자이다.

즉, task에 대한 Memory를 관리 해준다.

그림에서 보듯이 mm_struct는 vmarea 라는 구조체를 연결되어 가지고 있다.

이때 각각의 vmarea는 Text , Data , Heap , Stack 영역에 대한 Virtual한 Address 정보를 가지고 있다.



위에 그림은 한 task가 가지는 mm_struct가 관리하는 Virtual Memory를 표현하고 있다. (제가 그려서 좀 허접하죠 @^-^@)

이때 text, data, heap , stack을 관리하는 vmarea는

말그대로 Virtual Memory Area를 관리한다.

때문에 mm_struct는 Logical(virtual이라고 볼수도...)과 Physical

Memory간에 Mapping이 필요하게 된다.

쪼~~~기 위에 그림을 다시 보면 mm_struct는 또 pgd(Page Directory Table)를 가지고 있다.

이것이 바로 Logical과 Physical을 Mapping해주는 역할을 한다.

pgd 는 각각에 대해 pmd(Page Middle Directory Table)을 가지며

pmd는 pte(Page Table Entry)를 가진다.

pte는 dirty나 ref copy등을 처리하지만, 여기선 논외로 한다.

이런 방식을 통해 Logical과 physical을 Mapping한다는 것만 알고 있자


보는 바와 같이 task는 처음 생성이 되면 곧바로 실행이 되지 않는다.

대부분 Kernel은 크게 두개의 Queue 를 사용한다.

물론 기법에 따라 다 다르다. 하지만, 사용 개념은 같다.

어떤 Kernel은 몇개의 Queue를 우선순위별로 사용하지만,

큰 개념은 두개의 Queue다.

1. Runnable Queue 혹은 Ready Queue 라고 한다.

2. Blocked Queue 혹은 Sleep Queue 라고 한다.

이 두 Queue는 Multitasking 을 하기 위한 필수 기법이라고 할수 있다.

이를 통해 우리는 여러 Program 을 동시에 수행하듯이 사용할수 있는 것이다.

우선 한 task가 생성이 되면 Runnable Queue에 들어가서

Scheduling을 통해 실행상태(Running State)가 되길 기다린다.

이러다가 Scheduling을 통해 실행상태가 되면 수행을 하다가 두가지 경우가 발생할수 있다.

1. Time Slice Expired

실행상태에서 task에 주어진 시간을 모두 소진 하였을때이다.

고급


2. I/O Request or Event Occured

수행 시간이 오래걸리는 I/O 요청이나

MFC 프로그램 처럼 Event 중심 프로그램이 Event가 발생되기를 기다리는 동안에는

CPU를 할당 받지 않고 수행의 대상이 되지 않는 Blocked Queue에서

대기 하게 된다.

Blocked Queue에 삽입 되면, Interrupt가 발생이 되어야만 다시 Ready Queue에 삽입이 될 수 있다.

이때 Interrupt는 다양한 Signal이 될 수도 있고, Event가 될 수도 있다.

Interrupt가 되어 I/O가 완료되거나, Event가 발생하게 되면

해당 task는 Blocked Queue에서 Ready Queue로 전환되게 된다.
task_struct는 task의 한 단위로서의 역할을 하고 있다.

가끔 process와 thread와의 차이를 말끔히 정의하기 어려운 때가 있다.

하지만, Linux에서는 process와 thread의 차이를 명확히 두고 있지 않다.

즉, 다음에 나오는 task_struct가 task로서 하나의 수행 단위가 되고 있는 것이다.

process이든 thread이든 동일하게 task_struct로 생성이 되어

PCB(Process Control Block)이 된다.

하지만, 분명 thread는 자신이 포함되어 있는 process가 소멸 될 시 자신도 소멸되어야 한다.

때문에 최근에는 pid 부여를 하는 방법에서 특정 기법을 이용하여

thread가 process에 속함을 기록해 놓는다.

자세한 구조체 내용은 밑에 나열하겠다.



*** task_struct 구조체 정의 위치 ***

/usr/src/linux-2.6.12.3/include/linux/sched.h 에 존재함 (일반적으로 Kernel에 Install시에)



struct task_struct {
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
// task 의 상태를 기록하고 있다.
// -1 : Disk I/O 등으로 Blocked 되어 Blocked Queue에 있는 상태
// 0 : 현재 Runnable Queue에 존재하며 언제 실행될지 모르는 상태
// >0 : stopped 상태. Debug나 그 외의 이유로 task가 중지되어 있는 상태임

struct thread_info *thread_info;
atomic_t usage;
unsigned long flags; /* per process flags, defined below */
unsigned long ptrace;

int lock_depth; /* BKL lock depth */

int prio, static_prio;
struct list_head run_list;
prio_array_t *array;

unsigned long sleep_avg;
unsigned long long timestamp, last_ran;
unsigned long long sched_time; /* sched_clock time spent running */
int activated;

unsigned long policy;
cpumask_t cpus_allowed;
unsigned int time_slice, first_time_slice;

#ifdef CONFIG_SCHEDSTATS
struct sched_info sched_info;
#endif

struct list_head tasks;
/*
* ptrace_list/ptrace_children forms the list of my children
* that were stolen by a ptracer.
*/
struct list_head ptrace_children;
struct list_head ptrace_list;

struct mm_struct *mm, *active_mm;

/* task state */ struct linux_binfmt *binfmt;
long exit_state;
int exit_code, exit_signal; // task가 종료시 부모에게 return value int pdeath_signal; /* The signal sent when the parent dies */
/* ??? */

unsigned long personality; // 현재 지원되는 Unix 버전 번호 unsigned did_exec:1; // task가 생성된 뒤에 exec()을 통해 새로운 program이 load되었는지 유무 기록 pid_t pid; // task에게 부여된 고유 번호라고 할 수 있음 pid_t tgid;
/*
* pointers to (original) parent process, youngest child, younger sibling,
* older sibling, respectively. (p->father can be replaced with
* p->parent->pid)
*/

struct task_struct *real_parent; /* real parent process (when being debugged) */
struct task_struct *parent; /* parent process */
/*
* children/sibling forms the list of my children plus the
* tasks I'm ptracing.
*/
struct list_head children; /* list of my children */
struct list_head sibling; /* linkage in my parent's children list */
struct task_struct *group_leader; /* threadgroup leader */

/* PID/PID hash table linkage. */ struct pid pids[PIDTYPE_MAX];

struct completion *vfork_done; /* for vfork() */
int __user *set_child_tid; /* CLONE_CHILD_SETTID */
int __user *clear_child_tid; /* CLONE_CHILD_CLEARTID */

unsigned long rt_priority;
cputime_t utime, stime;
unsigned long nvcsw, nivcsw; /* context switch counts */
struct timespec start_time;
/* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */ unsigned long min_flt, maj_flt;

cputime_t it_prof_expires, it_virt_expires;
unsigned long long it_sched_expires;
struct list_head cpu_timers[3];

/* process credentials */ uid_t uid,euid,suid,fsuid;
gid_t gid,egid,sgid,fsgid;
struct group_info *group_info;
kernel_cap_t cap_effective, cap_inheritable, cap_permitted;
unsigned keep_capabilities:1;
struct user_struct *user;
#ifdef CONFIG_KEYS
struct key *thread_keyring; /* keyring private to this thread */
#endif
int oomkilladj; /* OOM kill score adjustment (bit shift). */
char comm[TASK_COMM_LEN]; /* executable name excluding path
- access with [gs]et_task_comm (which lock
it with task_lock())
- initialized normally by flush_old_exec */
/* file system info */
int link_count, total_link_count;
/* ipc stuff */ struct sysv_sem sysvsem;
/* CPU-specific state of this task */ struct thread_struct thread;
/* filesystem information */ struct fs_struct *fs;
/* open file information */ struct files_struct *files;
/* namespace */ struct namespace *namespace;
/* signal handlers */ struct signal_struct *signal;
struct sighand_struct *sighand;

sigset_t blocked, real_blocked;
struct sigpending pending;

unsigned long sas_ss_sp;
size_t sas_ss_size;
int (*notifier)(void *priv);
void *notifier_data;
sigset_t *notifier_mask;

void *security;
struct audit_context *audit_context;
seccomp_t seccomp;

/* Thread group tracking */ u32 parent_exec_id;
u32 self_exec_id;
/* Protection of (de-)allocation: mm, files, fs, tty, keyrings */ spinlock_t alloc_lock;
/* Protection of proc_dentry: nesting proc_lock, dcache_lock, write_lock_irq(&tasklist_lock); */ spinlock_t proc_lock;
/* context-switch lock */ spinlock_t switch_lock;

/* journalling filesystem info */ void *journal_info;

/* VM state */ struct reclaim_state *reclaim_state;

struct dentry *proc_dentry;
struct backing_dev_info *backing_dev_info;

struct io_context *io_context;

unsigned long ptrace_message;
siginfo_t *last_siginfo; /* For ptrace use. *//*
* current io wait handle: wait queue entry to use for io waits
* If this thread is processing aio, this points at the waitqueue
* inside the currently handled kiocb. It may be NULL (i.e. default
* to a stack based synchronous wait) if its doing sync IO.
*/

wait_queue_t *io_wait;
/* i/o counters(bytes read/written, #syscalls */ u64 rchar, wchar, syscr, syscw;
#if defined(CONFIG_BSD_PROCESS_ACCT)
u64 acct_rss_mem1; /* accumulated rss usage */ u64 acct_vm_mem1; /* accumulated virtual memory usage */ clock_t acct_stimexpd; /* clock_t-converted stime since last update */#endif
#ifdef CONFIG_NUMA
struct mempolicy *mempolicy;
short il_next;
#endif
#ifdef CONFIG_CPUSETS
struct cpuset *cpuset;
nodemask_t mems_allowed;
int cpuset_mems_generation;
#endif
};
◈ 자바언어의 개요

▶ Simple

자바의 개발자들은 C++ 프로그래밍 언어를 기반으로 이 언어를 개발하였지만, 자주 사용하지 않거나 거의 사용하지 않는 객체 지향적인 특징의 많은 부분을 제거하였다. C++언어는 객체 지향적인 프로그래밍 언어이며, 매우 강력한 기능을 제공한다. 그러나 강력한 기능을 제공하도록 설계한 많은 언어와 마찬가지로 오류가 포함되거나 이해하기 어려운 코드를 작성하는 경우처럼 일부 특성은 프로그래머들에게 문제를 야기하고 있다. 소프트웨어 엔지니어링에 필요한 대부분의 비용을 창조적인 활동보다는 코드 정비에 사용하곤 하였다. 그래서 강력하지만 이해하기 힘든 코드보다는 이해하기 쉬운 코드로 변환함으로써 소프트웨어 유지비용을 상당히 절약할 수 있다. 특히 자바는 다음과 같은 면에서 C++(C)와 차이가 난다.

- 자바는 struct와 union, pointer 데이터형을 지원하지 않는다.

- 자바는 typedef나 #define 을 지원하지 않는다.

- 자바에서는 특정 연사자의 처리 방법이 다르며, 연산자 다중 정의(operator overloading)를 허용하지 않는다.

- 자바는 다중 상속(multiple inheritance)을 지원하지 않는다.

- 자바는 명령 인수의 처리에서 C나 C++와는 다르다.

- 자바는 java.lang 패키지의 일부로서 String 클래스를 제공한다. 이것은 C나 C++에서 사용하는 널(null)로 끝나는 문자 배열과는 다른 것이다.

- 자바는 메모리 할당과 회수(쓰레기 수집)를 위한 자동 시스템을 제공하므로, C나 C++에서 사용하는 메모리 할당과 회수 함수를 사용할 필요가 없다.

▶ Object-oriented

객체 지향 디자인을 함으로써 인터페이스의 정의를 명확히 할 수 있고, 재사용 가능한 코드를 만들 수 있게 하였다. 간단하게 말해서, 객체 지향 디자인은 데이터(객체)와 그 데이터와의 인터페이스의 디자인에 초점을 둔다. 또, 객체 지향 디자인은 "plug and play"를 정의하기 위한 메커니즘이다.


▶ Network-Savvy

자바는 HTTP나 FTP같은 TCP/IP 프로토콜을 처리하는 많은 라이브러리를 가지고 있다. 이러한 점들이 C나 C++보다 네트워크 접속을 더 쉽게 할 수 있는 특징이다. 자바 응용들은 프로그래머가 자신의 로컬 파일 시스템에 액세스하는 것과 같은 식으로 URL을 통해서 네트워크에 있는 객체를 열고 접근할 수 있다.

▶ Robust

튼튼한 소프트웨어란 프로그램에 버그가 있더라도 쉽게 문제를 유발하지 않는다는 것을 뜻한다. 튼튼한 소프트웨어를 추구하는 프로그래밍 언어는 보통 프로그래머가 소스 코드를 작성할 때 더 많은 제약을 둔다. 이러한 제한에는 데이터형과 포인터의 사용 등이 포함된다. C언어는 컴파일과 실행 시에, 호환되는 데이터형을 확인하는데 굉장히 느슨하다는 평을 받아왔다. 그러나 C++에서는 강력하게 이 데이터형을 규제하므로, C의 느슨한 접근법을 제한하고 있다.

이 입력에 대한 규제가 더 강력하며, 예를 들어 프로그래머는 자료 변환에서 임의의 정수를 포인터로 변환할 수 없다. 또한 자바는 포인터 연상을 지원하지 않는 대신에 배열을 지원한다. 이러한 단순한 접근법을 통해 C 프로그래머의 메모리 내 임의의 영역 접근을 일부 제거하였다. 특히 자바는 프로그래머가 포인터를 통해 메모리를 겹쳐 쓰거나 다른 데이터를 손상시키는 것을 허용하지 않는다.


▶ Secure

자바는 분산 네트워크 환경에서 사용되는 것을 전제로 만들어졌다. 데이터 접근을 제한하기 위해 공용키(public key) 암호화 기법을 자바에 포함시켰다. 포인터에 대한 자바의 제한은 허용하지 않는 메모리에 개발자가 접근하는 것을 금지한다. 자바는 이러한 방식을 통해 보안성이 더 놓은 소프트웨어 환경을 제공한다.

▶ Architecture Neutral

자바는 네트워크 상의 응용들을 지원하기 위해 만들어졌다. 대개 네트워크는 다양한 CPU와 OS 아키텍쳐를 가지고 있다. 자바 응용이 네트워크의 어떤 상황에도 실행되게 하기 위해 컴파일러는 아키텍처 중립적 객체 파일 포맷을 만들어낸다. 또한, 네트워크뿐만 아니라 단일 시스템 소프트웨어 배포에도 유용하다.

자바 컴파일러는 특별한 컴퓨터 아키텍처와 관계없는 바이트코드 명령어를 생성시킴으로써 이러한 것을 처리한다.

▶ Portable

아키텍처 중립적이라는 말은 이식성을 가지고 있다는 것을 포함한다. 그러나 이식성이 높을 경우 단점은 하드웨어가 수치 연산을 해석하는 방식에 문제가 있을 수 있습니다. C나 C++에서 소스 코드는 하드웨어 플랫폼에 따라 약간 다르게 실현되는데, 이것은 해당 플랫폼이 수치 연산을 하는 방식이 다르기 때문이다. 자바에서는 이러한 면을 단순하게 구현하였다. 자바에서 정수형인 int는 부호를 사용한 2의 보수인 32비트 정수이다. 실수형인 float는 IEEE754표준에 정의한 32비트 부동 소수점 수이다.


▶ High Performance

자바의 바이트코드는 해석할 수 있기 때문에, 때로는 특정 하드웨어 플랫폼을 위해 직접 컴파일하고 실행하는 것만큼 성능이 뛰어나지는 않다. 자바의 컴파일 과정에서는 바이트코드를 특정 하드웨어 플랫폼을 위한 기계어 코드로 바꾸는 옵션이 포함되어 있다. 이것을 사용하면, 전통적인 컴파일이나 불러오기 과정과 같은 효과를 제공한다. Sun Microsystems는 자사의 테스트 결과, 바이트코드를 이러한 기계어 코드로 변환하는 성능은 C나 C++ 프로그램을 직접 컴파일 하는 것과 차이가 없다고 발표한 바 있다.

▶ Multithreaded

자바를 이용할 경우 한 번에 여러 작업을 수행할 수 있는 애플리케이션을 작성할 수 있다. 자바는 C.A.R. Hoare의 모니터와 조건 패러다임을 바탕으로 다중스레드 이벤트를 허용하는 시스템 루틴에 기반을 두고 있기 때문에, 프로그래머들은 프로그램 내에서 실시간 상호 작용할 수 있다.

▶ Dynamic

부모 클래스가 바뀌면, 완전히 재컴파일해야하는 C++ 코드와는 달리, 자바는 이러한 종속성을 완화시키는 인터페이스 메소드를 사용한다. 그 결과 자바 프로그램들은 종속적인 클라이언트 객체에 영향을 미치지 않고 객체 라이브러리에 새로운 메소드나 인스턴스 값을 추가할 수 있다.
MFC에서는 일반적으로 많이 사용하는 Dialog를 Library로 제공한다.

이때 Header 파일은 : afxdlgs.h을 요구한다.

CFileDialog
참고 : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_mfc_cfiledialog_class_members.asp
_M#]
CFontDialog

CColorDialog


CPageSetupDialog

CPrintDialog

CPrintDialogEx

CFindReplaceDialog

COleDialog

'도서관 I > MFC' 카테고리의 다른 글

[펌] #define new DEBUG_NEW 의 비밀  (0) 2006.07.26
Pocket Plus를 깔면

자동적으로 네비게이터바 쪽에 상단에 먼가가 쭉~~~내려와 버린다.



이는 [시작-설정-시스템-spb pocket plus] 으로 들어간 뒤

Taskbar Battery Indicator 를 해제하면 되는데

한글 패치를 한 경우에는 테스크바 배터리 표시기를 체크 해제하면 된다.
Java에서 Serializable 이라는 Interface가 있다.

이 Interface는 객체 직렬화인데, 이는 어떤 구조화된 객체를

Bytes Stream으로 전송하는 것을 말한다.

Serializable Interface를 구현한 Class는 직렬화가 가능하여

writeObject(Object obj) 나 readObject(Object obj) 등을 통해

전송이 가능하다.

Serializable의 예를 보도록 하자

import java.io.*;

class NonSerial
{
int v1;
public NonSerial() // needed for serialzation
{}

public NonSerial( int v1 ) {
this.v1 = v1;
}
}

public class MyList extends NonSerial implements Serializable
{
int v2;
transient String v3;
MyList next;
public MyList(int v1, int v2, String v3) {
super(v1);
this.v2 = v2;
this.v3 = v3;
}

public void print() {
System.out.print(v1 + ", " + v2 + ", " + v3 + ": ");
if (next == null)
System.out.println();
else
next.print();
}

public static void main(String[] args) {
MyList node1 = new MyList(1, 11, "first");
MyList node2 = new MyList(2, 12, "second");
MyList node3 = new MyList(3, 13, "third");
node1.next = node2;
node2.next = node3;
node3.next = null;
try {

FileOutputStream outFile
= new FileOutputStream("test.out");
ObjectOutput out = new ObjectOutputStream(outFile);
out.writeObject(node1);
out.close();

FileInputStream inFile
= new FileInputStream("test.out");
ObjectInput in = new ObjectInputStream(inFile);
MyList inNode = (MyList) in.readObject();

node1.print();
inNode.print();

in.close();
} catch( Exception e ) {
e.printStackTrace();
}
}
}


이 예제는 MyList Class가 Serializable Interface를 상속받지 않은 Class인

NonSerial 이라는 Class를 상속 받고 Serializable을 구현하였기에

NonSerial Class에 있는 v1 변수의 값은 기록되지 않고,

MyList에 있는 v2 변수와 next 변수만이 전송되어 기록되어지는 모습을 보인다.

MyList의 내부적인 모습은 다음과 같다.



이때 transient로 선언이 된 v3는 Serializable Interface를 구현한 MyList Class의

멤버 변수 임에도 불구하고 Serializable 특성을 가지지 않게 되어

실제 writeObject()나 readObject()함수를 사용하여도 전송되지 않는다.

따라서 위에 MyList를 실행한 결과는

1, 11, first: 2, 12, second: 3, 13, third:
0, 11, null: 0, 12, null: 0, 13, null:

이 된다.

또한 "test.out"의 파일을 열어보면 다음과 같은 기록이 보인다.

ы ?sr ?MyList?熬[?f? ?I ?v2L ?nextt ?LMyList;xp ?sq ~ ?sq ~
p

위에 MyList라는 문자가 듬성듬성 보인다.

이를 이용해 읽어들일때에는 다시 MyList를 생성하여 그 객체에 채워 넣은뒤 리턴하게 된다.



이때 주의 해야 할 점은 Serializable을 이용하여 전송을 할경우

위의 예처럼 Node1만을 writeObject()하여도 Node1,2,3가 모두

연달아 전송이 된다는 것이다. 이는 Node1에 있는 next 변수가 node2를 가리키고 있기때문에 따라가서 실제 객체를 저장하는 것이며

읽을때에도 또안 readObject()를 수행하면 자동으로 연결되어 있는 객체는 모두 read 된다.

유의 할 것!!!

+ Recent posts