'비스타'에 해당되는 글 8건

  1. 2008/07/12 윈도우즈 업데이트 (3)
  2. 2007/09/18 비스타 (Vista) 에 기존 입력기 (legacy IME) 설치하기 (1)
  3. 2007/09/15 TSF 디버깅 문제
  4. 2007/08/31 비스타의 네트워크 속도 저하 버그
  5. 2007/08/30 영문 비스타 (Vista) 시스템에서 기존 입력기 (legacy IME) 사용 방법
  6. 2007/08/23 길드워의 비스타 입력 시스템 (TSF) 지원
  7. 2007/06/30 비스타(Vista)에서 Visual Studio 2005 버그
  8. 2007/02/28 인텔 4세대 센트리노 CPU 곧 발매 예정 (2)
멀티프로그래밍 위키로 바로가기 → http://www.devnote.net/wiki

윈도우즈 업데이트

기타/잡담 2008/07/12 04:29
오늘 "중요 (Important)"로 분류된 윈도우즈 업데이트 중 하나를 살펴 본 결과 아래와 같은 내용이었습니다. 아래 5개의 단어를 윈도우즈 철자 검사기 사전에 추가하는 것인데, 사람 이름이거나 인터넷 싸이트 이름들 입니다. 그 중 민주당 대선 후보인 "Obama"의 이름이 있는 것도 흥미롭습니다.

The words "Friendster," "Klum," "Nazr," "Obama," and "Racicot" are not recognized when you check the spelling in Windows Vista and in Windows Server 2008

http://support.microsoft.com/kb/955020


그런데, 이 업데이트가 "중요"로 분류된 것은 좀 이해할 수 없습니다. 게다가 이 업데이트는 약 50MB의 디스크 영역를 차지한다고 하며 설치후에 시스템 리부팅도 필요합니다.

이 업데이트는 모든 언어버전의 윈도우즈에 적용되는 것 같습니다. 따라서 마이크로소프트의 주장대로 전세계에 모두 1억개의 윈도우즈 비스타가 팔렸고, 모든 비스타 사용자가 이 업데이트를 받는다면, "50 MB * 1억 = 4.8 PT(Peta Bytes)"라는 천문학적인 디스크 용량이 소모됩니다. 물론 요즘 1GB 디스크 용량에 1$도 안된다고 하지만, 그래도 약 480만 달러 즉 58억원 가량의 디스크 비용이 소요되는 것 입니다. 그러니까 단지 5개의 단어를 사전에 추가하기 위해서 말이지요.

만약 웹기반의 클라이언트 서버방식의 철자검사 시스템을 사용한다면 이러한 사전 업데이트는, 클라이언트에 영향을 미치지 않고 언제라도 진행될 수 있었을 것입니다. 물론 이 방식은 철자 검사를 하려면, 인터넷 연결이 필요합니다.

마이크로소프트의 단어사전은 일종의 Suffix Tree인 Trie 구조를 사용하고 있어, 검색속도가 매우 빠르며 사전 자체 파일 싸이즈도 크게 줄어들어 메모리에 로드될 수 있을 정도이나, 단어 하나의 업데이트라 해도 사전 전체를 다시 빌드해야하는 단점을 지니고 있습니다. (부연설명하면 하나의 단어 업데이트라도 최종 빌드되는 사전 데이터 중 다른 여러 단어 데이터에 영향을 미치게 된다는 것 입니다)

크리에이티브 커먼즈 라이센스
Creative Commons License
마이크로소프트, 비스타, 윈도우즈 업데이트
트랙백 0 : 댓글 3

비스타 (Vista) 에 기존 입력기 (legacy IME) 설치하기

텍스트 입력 시스템/IME 2007/09/18 10:18
이전에 비스타에서 Legacy IME를 사용하는 법에 관해 설명하였습니다. 비스타의 TSF 입력기의 호환성 문제 때문에 한글과 일본, 중국어 입력에 심각한 문제를 겪고 있는 사람들을 위해 한글 입력기를 포함한, 아시아 국가들의 기존 legacy IME를 간단하게 설치하는 방법을 알아보겠습니다.

전에 설명한 바와 같이 비스타에는 이전 IME 파일은 그대로 존재 하지만, 레지스트리에서만 제거 되었습니다. 아래 첨부된 레지스트리 파일은 비스타에 포함된 모든 아시아권 IME를 사용 가능하게 해줍니다. 이 파일은 HKLM의 키보드 레이아웃 시스템 레지스트리를 바꾸므로 관리자(administrator) 권한을 필요로 합니다. 이 파일에 특별히 시스템 보안에 문제되는 내용은 없다. 그러나, 보안을 조금 이라도 염려하는 사용자라면, 곧바로 실행하지 말고, 디스크에 저장한 후 내용을 살펴보고 실행하시기 바랍니다.


OldImeKL.reg

비스타에서 이전 legacy IME를 추가하는 레지스트리 파일


위의 레지스트리 등록이 끝나면, 입력도구의 등록정보에서 아래와 같이 이전 IME가 추가되어 있음을 알 수 있습니다. 빨간 상자에 있는 것들이 이전 IME들 입니다.

한국어의 경우 한글 MS-IME2002를 기본(default) IME로 선택하시기 바랍니다. (아래 스크린캡쳐는 영문 비스타에서 얻은 것입니다). 이렇게 설정을 바꾼 후에 시스템 리부팅은 필요 없으며, 이 후에 실행되는 어플리케이션은 자동으로 IME2002를 사용하게됩니다.

이전 Legacy IME 레지스트리 입력 후 입력기 설정 화면

크리에이티브 커먼즈 라이센스
Creative Commons License
IME, Vista, 비스타, 입력기
트랙백 0 : 댓글 1

TSF 디버깅 문제

텍스트 입력 시스템/TSF 2007/09/15 09:13

오늘 TSF (Text Service Framework)를 지원하는 Application을 개발하는데 있어, 디버깅 하는데  큰 문제가 있음을 알아 냈습니다.

먼저 자세한 설명을 하기 전에 증상부터 알아 봅시다. 아래 소스는 Vista SDK에 TSF 예제로 포함된, TSFAPP의 TEXTSTOR.CPP의 일부입니다. InsertTextAtSelection 함수는 새로운 글자가 입력될 때 마다 호출되는 함수입니다. 함수 시작 부분에 메모리 주소 0 에 쓰기를 시도하여 Access Violation을 유발 시켜보았습니다. 이것은 심각한 버그가 있는 것을 시뮬레이션 하는 것입니다.


/**************************************************************************

  CTSFEditWnd::InsertTextAtSelection()

**************************************************************************/

STDMETHODIMP CTSFEditWnd::InsertTextAtSelection(    DWORD dwFlags,
                                                   const WCHAR *pwszText,
                                                   ULONG cch,
                                                   LONG *pacpStart,
                                                   LONG *pacpEnd,
                                                   TS_TEXTCHANGE *pChange)
{
  OutputDebugString(TEXT("CTSFEditWnd::InsertTextAtSelection \n"));

  *(int *) 0 = 0;  // <-- Access Violation 유발


이제 TSFAPP.EXE를 컴파일시켜, 한글을 입력해 봅시다.  그런데,  예상과 달리 이 어플리케이션은 크래시되지도 않고 우리가 흔히 보는 윈도우즈 에러 리포트 다이얼로그도 나타나지 않습니다. 단지 원하는 한글 입력은  되지 않습니다. 이것이 왜 디버깅에 문제가 되는 지, 아마 어느 정도 짐작하였을 것입니다. 어플리케이션이 제공하는 TSF 인터페이스 내부에, 아무리 심각한 버그가 있어도 프로그램이 죽거나 에러를 리포트하지 않는다는 것입니다.  이유는 무엇일까요? 다름 아닌 윈도우즈의 TSF입력 지원 모듈이 자체 예외처리기를 가지고 있기 때문입니다.

따라서, 디버거를 처음에 attach시켜 프로그램을 실행하지 않는 한, access violation과 같은 심각한  버그가 있어도, 어느 순간 입력에 이상이 생기는 현상만 나타나며, 원인을 알아내기 어렵다는 점 입니다. 특히 어플리케이션이 자체 예외처리기(SEH)를 가지고 콜스택을 로그파일로 만들거나 덤프파일을 만드는 것이 불가능해 집니다. 따라서, 어플리케이션 버그로 인한 입력 문제가 발생함에도 불구하고 사용자나 개발자는 OS에 문제가 있는 것으로 오인할 가능성도 많습니다.

윈도우 TSF 모듈이 자체 예외처리기를 가지는 것을 확인하기 위해서, 우선 위에서 만든 TSFAPP.EXE를 실행해 봅시다. 그리고 VS에서 Attach to Process를 선택하거나, 이 프로세스의 ID를 알아낸 다음, "ntsd -p <프로세스 ID>"와 같이 커맨드라인 디버거를 이용하여 디버거를 attch 합니다. 이제 한글을 입력하려고 하면 디버거에서 이 메모리 오류(Access Violation)을 캐치함을 알 수 있습니다. 이것은 First chance exception 입니다. 여기서 다시 계속 진행시키기 위해 디버거에서 "go"를 선택하면, 아래와 같은 콜스택을 볼 수 있습니다.

TSF 핵심 모듈인 MSCTF.DLL이 자체 exception handler를 가지고 있는 것을 알 수 있다. 여기서 다시 "go"를 하면 프로그램은 종료되지 않고 계속 실행된다.

여기서 CicExceptionFilter가 EXCEPTION_EXECUTE_HANDLER 값을 리턴하는 것을 짐작할 수 있습니다. 즉, MSCTF 자체 예외처리기에 걸리면 다른 SEH는 이것을 알지 못합니다.  내가 아무리 최고의 unhandled exception handler를 가지고 있다 해도 무용지물입니다. 여기서 한가지 해결책은 XP이후부터 지원되는 Vectored Exception Handler를 사용하는 것입니다.


0012f434 77999b31 ntdll!DbgBreakPoint
0012f46c 77999b94 ntdll!RtlUnhandledExceptionFilter2+0x2a4
0012f47c 767ec8f5 ntdll!RtlUnhandledExceptionFilter+0x12
0012f488 767dc902 MSCTF!CicExceptionFilter+0xe
0012f490 7672669b MSCTF!CInputContext::_DoEditSession+0x49
0012f4a4 76726620 msvcrt!_EH4_CallFilterFunc+0x12
0012f4d0 76812a3b msvcrt!_except_handler4_common+0x8e
0012f4f0 77951039 MSCTF!_except_handler4+0x20
0012f514 7795100b ntdll!ExecuteHandler2+0x26
0012f5bc 77950e97 ntdll!ExecuteHandler+0x24
0012f5bc 00402a26 ntdll!KiUserExceptionDispatcher+0xf
0012f8d0 76803991 TSFApp!CTSFEditWnd::InsertTextAtSelection+0x6
0012f90c 767ee809 MSCTF!CACPWrap::InsertTextAtSelection+0x38

0:000> uf MSCTF!CicExceptionFilter
MSCTF!CicExceptionFilter:
77bbc8e7 mov     edi,edi
77bbc8e9 push    ebp
77bbc8ea mov     ebp,esp
77bbc8ec push    dword ptr [ebp+8]
77bbc8ef call    dword ptr [MSCTF!_imp__RtlUnhandledExceptionFilter (77b811d8)]
77bbc8f5 xor     eax,eax
77bbc8f7 inc     eax => retrun EXCEPTION_EXECUTE_HANDLER
77bbc8f8 pop     ebp
77bbc8f9 ret     4



그런데, 왜 MSCTF는 Access Violation과 같은 심각한 예외상황을 무시하고 지나가도록 한 것일까? MSCTF가 모든 경우 자체 예외 처리를 통해 이런 심각한 예외를 무시하도록 하고 있지는 않다. 간단한 예로 InsertTextAtSelection가 아닌 다른 함수들 안에서 잘못된 메모리 참조하면 정상적으로 프로그램이 종료되고, 윈도우즈 오류 리포팅과 같은 Post Mortem Debugger가 실행된다. 이유는 좀 황당하지만 이렇다.

MS 내부에서 TSF를 지원하는 어플리케이션과 입력기들이 많이 개발되었고, 어플리케이션 혹은 입력기들의 자체 버그로 인해 중요 어플리케이션이 종료되는 현상이 자주 나타나자, TSF 팀은 많이 사용되는 Callback 함수들을 아예 자체 예외처리기로 묶어서 심각한 문제가 발생해도 어플리케이션을 죽이지 않고, 현재 입력만을 취소한 채로 계속 수행되도록 만든 것이다.

특히 TSF의 내부 구조의 복잡성으로 인해, 사소하고 미묘한 문제가 어플리케이션을 죽이는 상황으로 쉽게 니티나기 시작하였다. TSF 팀은 이들 입력기를 개발한 팀에 수정을 요구하기 보다는 자체적으로 이러한 버그를 피해가는 방법을 선택하였다. (많은 종류의 어플리케이션들이 TSF를 잘못 사용하여 문제를 일으켰기 때문일 것이다)

어플리케이션이 죽지 않아 입력된 데이터의 손실은 막을 수 있겠으나, 이로인한 부작용은 앞서 설명한 바와 같이 TSF를 사용하는 어플리케이션이나 입력기의 심각한 문제를 발견하기 어렵게 되었을 뿐 아니라, 입력 중인 글자가 취소되거나 한영 변환이 되지 않는 등 가끔 매우 이상한 현상이 감지될 수 있다.

TSF 어플리케이션을 제작할 때 입력에 문제가 발생한다면, 디버거를 attach시키고 실행하여야만 access violation과 같은 심각한 버그가 숨어 있음을 알 수 있다.



크리에이티브 커먼즈 라이센스
Creative Commons License
IME, TSF, 디버깅, 비스타
트랙백 0 : 댓글 0

비스타의 네트워크 속도 저하 버그

프로그래밍 일반/네트워크 프로그래밍 2007/08/31 08:39
Mark의 블로그에 흥미로운 내용이 올라왔다. 비스타 미디어 플레이어로 음악을 듣는 도중에 네트웍 속도가 크게 저하된다는 것이다.

이것은 비스타에 새롭게 추가된 Multimedia Class Scheduler Service (MMCSS)에 의해 "미디어 플레이어"의 우선 순위가 높아진 때문이지만, 네트워크 속도에 영향을 미친다는 것은 매우 흥미로운 일이다.

Mark의 말에 따르면 1GB 네트웍 카드에 1GB 네트웍에 연결된 경우에 속도저하를 느낄 수 있다는 것이다. 또, 100 MBps 네트웍이라하더라도 2개이상의 네트웍 카드가 연결되어 있다면 속도저하가 나타난다고 한다. 이것은 NDIS 드라이버의 버그라고 하며 MS는 이 버그 수정을 하고 있다고 한다. 하지만, 또 어떤 다른 버그가 숨어 있을지는 아무도 모를 일이다.

게임의 경우에도 비스타에서는 사운드를 담당하는 스레드가 높은 우선순위를 가지게 되는데, 이것이 네트워크나 그래픽 속도에 영향을  미칠 가능성이 있다.
크리에이티브 커먼즈 라이센스
Creative Commons License
Vista, 네트워크, 버그, 비스타
트랙백 0 : 댓글 0

영문 비스타 (Vista) 시스템에서 기존 입력기 (legacy IME) 사용 방법

텍스트 입력 시스템/IME 2007/08/30 10:39
비스타는 TSF (Text Service Framework)을 이용한 입력을 기본으로하여 기존 IME는 더 이상 사용하지 않는다. 그런데 흥미롭게도 기존 IME파일은 그대로 남겨두었다.

아래와 같이 %WINDIR%\system32 폴더에 *.IME 파일들이 존재한다. 다만, 이들은 레지스트리에서 제거되어 기본적으로 사용되지 않을 뿐이다. 게다가 이들은 XP에 들어 있는 IME보다 모두 버전업된 것 들이다. 기존 IME 지원 코드가 여전히 남아 있는 가장 큰 이유는 서드파티 IME들 때문일 것이다. 일본이나 중국의 경우 서드파티 IME들이 상당히 많이 존재하며. 이들이 TSF를 지원하기 위해 코드변경을 하는 것은 상당한 작업이기 때문에 기존 IME지원 코드를 그대로 남겨둔 것으로 보인다.

그렇다 해도 MS IME 파일들을 그대로 남겨두고 레지스트리에 추가하지 않아 사용하지 못하게 한 것은 어쨋든 좀 이상하다. 어쩌면 비스타의 기본 입력시스템인 TSF가 불안할 경우, 기존의 IME를 다시 사용할 수 있는 방법을 남겨두었는지도 모른다.

dir %WINDIR%\system32\*.ime

11/02/2006  02:39 AM           124,928 chajei.ime
11/02/2006  02:39 AM           124,928 cintlgnt.ime
11/02/2006  02:39 AM           881,152 IMJP10.IME
11/02/2006  02:39 AM           412,160 imkr80.ime
11/02/2006  02:40 AM             7,168 msctfime.ime
11/02/2006  02:39 AM           124,928 phon.ime
11/02/2006  02:39 AM            88,576 pintlgnt.ime
11/02/2006  02:39 AM           124,928 qintlgnt.ime
11/02/2006  02:39 AM           124,928 quick.ime
11/02/2006  02:39 AM           125,440 tintlgnt.ime

TSF는 코드네임 Cicero로 1990년대 말부터 시작된 프로젝트이다. COM인터페이스를 기본으로 설계된 TSF는 기존 IME와의 호환성을 위해 CUAS (Cicero Unaware Application Support)를 구현하였다. 하지만, CUAS가 100% 완벽한 호환성을 지원하지 못하기 때문에 여러 어플리케이션에서 문제가 발생할 수 있다. 기본적으로 TSF만을 지원하는 비스타이지만, 실제로는 모든 기존 IME지원 파일들이 존재하기 때문에, 기존 IME를 쉽게 재설치 가능하다. 특히, 이는 TSF와 문제를 일으키는 어플리케이션을 사용해야만 하는 경우 유용한 팁이 될 수 있다.

그럼 이들을 비스타에서 사용하려면 어떻게 하면 될까? 아래 reg파일과 같이 HKLM에 IME를 등록해주면, 기존 IME의 추가가 가능해진다. (여기서는 한글 IME의 예를 들은 것이고, 다른 언어 IME의 경우도 WIn XP의 레지스트리를 참고하여 같은 방법으로 비스타에서 문제없이 사용할 수 있다)

http://www.devnote.net/45 에 모든 아시아권 legacy IME를 포함하는 레지스트리 파일을 올려 놓았음

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\E0010412]
"Layout File"="KBDKOR.DLL"
"Layout Text"="Korean Input System (IME 2002)"
"IME file"="imkr80.ime"
"Layout Display Name"="@%SystemRoot%\\system32\\input.dll,-5064"


추가된 IME는 입력도구모음 윈도우에서 선택하여 사용 가능한데 아직 기본으로 설정되어 있지는 않다. 등록정보 UI에서는 기존 IME를 기본으로 설정할 수 있다.  기존 IME를 기본으로 하면 아래 HKCU의 Preload를 변경하면된다. 여기서 E0010412는 한글 입력기의 HKL 핸들값으로 위에 HKLM서 추가된 값이다. 00000412는 TSF 입력기이다. 따라서, IME가 기본으로 나타나게되며 TSF 한글 입력기를 사용하기 원하면, 언어입력도구 상자의 아이콘을 클릭하여 변경할 수 있다.


HKL은 Keyboard Layout Handle이다. HKL 값에 대해 조금 더 자세히 알아보면, IME일 경우 최상위 세비트가 항상 1 이되어 "0xE00N0LLL"와 같은 형태가 되고 IME가 아닌 키보드 드라이버일 경우는 "0x000N0LLL" 형태가 된다. 여기서 N은 일련번호 (1부터 시작) 이며 LLL은 LCID (Locale ID)이다. 한글의 경우는 LLL은 412 (16진수) 가 된다.

윈도우즈에 설치된 모든 키보드 드라이버와 IME는 다음 레지스트리 아래에서 찾을 수 있다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts

또 이들 중에 각각의 사용자들에게 설치된 IME는 아래 HKCU 아래 있다. 숫자 일련번호에 따라 "1" 이 기본 IME혹은 키보드 드라이버이다

HKEY_CURRENT_USER\Keyboard Layout\Preload


Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Keyboard Layout\Preload]
"1"="e0010412"
"2"="00000412"

마이크로소프는 비스타에서 음성인식 지원을 가장 큰 기능 향상 중의 하나로 선전하였다. (음성인식은 XP에도 있었으나 비스타에서 UI가 많이 향상되었다). 하지만, 안타깝게도 한국어 음성인식이 지원되지 않는다. (일본어, 중국어 음성인식은 지원된다). 따라서, 비스타의 TSF를 통해 당장 얻어지는 잇점 이라면 단어 단위의 한글/한자 변환과 사용자 정의 한자 사전일 것이다. 하지만, 이러한 기능을 사용하지 않는다면 기존 (legacy) IME를 사용하는 데 아무런 문제가 없다. 기존 IME는 TSF IME에 비해 메모리도 100 KB이상 덜 사용하며, 전에 언급한 바와 같이 복잡한 함수 호출이 없어 속도도 빠르다. 호환성에 있어서도 물론 기존 IME가 우수하다.

그렇다고 앞으로 계속 기존 IME 쓸 수는 없을 것이다. 비록 비스타에서 IME 파일을 남겨 두었으나, 다음 윈도우즈 버전에서는 IME를 영원히 삭제하게 될 것으로 예상되기 때문이다.
크리에이티브 커먼즈 라이센스
Creative Commons License
IME, Vista, 비스타
트랙백 0 : 댓글 0

길드워의 비스타 입력 시스템 (TSF) 지원

게임/길드워 2007/08/23 16:26
드디어 그동안 작업하던 TSF(Text Service Framework) 지원이 거의 끝나 곧 게임에 업데이트 될 예정입니다. 비스타(Vista)에서는 기존 IME가 사라지고 TSF가 기본으로 작동하는 바람에 시작한 일이지만, TSF라면 제가 오래전부터 관여했던 것이라 제대로 구현하려고 노력했습니다.

만약 실제 사용되는 모든 윈도우즈 OS가 TSF기반의 IME 만을 지원한다면 오히려 문제는 간단해 질 수 있습니다. 왜냐면, 표준을 따르지 않는 중국어 IME들을 지원하기 위해 많은 해킹 코드가 사용되고 있기 때문입니다. 하지만, 불행히도 이제 비스타에서만 기본으로 TSF가 설정되어 있기 때문에, 어플리케이션을 개발하는 입장에서는, 오히려 실행 시간에 윈도우즈 버전을 확인하여 IME 혹은 TSF 중 하나를 선택하여 지원해야 하는 부담이 생겼습니다.

그러니까, 게임과 같이 DirectX를 사용하는 어플리케이션은 IME, TSF 둘 다 지원하는 코드를 작성하고 테스트해야만 한다는 것입니다. 저 같은 경우는 매우 오래전부터 이 일에 직접 관여해왔기 때문에 그나마 쉽게 구현하였으나, 처음 IME와 TSF를 접하는 개발자라면 이해하는 데에만 상당한 시간이 걸릴것으로 예상됩니다.

길드워에 TSF 지원기능을 구현하던 중 DirectX 8월 버전에 TSF 지원 기능이 추가된 CustomUI 예제가 발표되었습니다. 그러나, 이것은 TSF를 완전히 지원하는 것은 아니고 기존의 IME지원 코드 중에 비스타에서 동작하지 않는 부분만을 TSF를 직접 사용하여 해결하는 것 입니다. 게다가 그렇지 않아도 지저분한 기존의 코드에 TSF 코드까지 더해져 DirectX의 CustomUI IME 샘플 코드는 정말로 보기 싫을 정도로 복잡해져 있습니다. 다만, 이 코드를 작성한 사람을 만난 적이 있기 때문에, 더 이상의 코멘트는  하지 않겠다.^^

그런데, 여기서 길드워가 TSF를 완전히 지원 (fully enable) 했다는 것이 무슨 의미인지, 그리고 사용자들에게 어떠한 이득이 있는지 간단히 설명해 보겠습니다. (먼저 말하지만 게임에서는 그다지 유용하지 않은 것 같습니다. 더군다나 한자 변환을 많이 사용하지 않는 한국어 사용자들에게는 TSF가 당장 어떠한 편리함도 제공해주지는 않을 것 같습니다.)

우선, 비스타의 TSF에는 게임과 같이 전체화면을 사용하는 DirectX프로그램을 위해 UI Less mode가 추가 되었습니다. 그러나 UI Less mode 인터페이스로는 원래 추천 리스트 (candidate list) UI에 표시되는 모든 정보를 얻을 수 없는 단점이 있습니다.

길드워는 창모드 (windowed mode)를 지원하고 많은 플레이들이 이를 애용한다는 점을 고려해서, 창모드에서는 원래 위도우즈의 Candidate UI를 보여주고, 전체 화면모드에서만 UI Less mode를 사용한 커스텀 UI를 사용하였습니다.

아래 그림은 창모드에서 한자변환을 하는 예입니다. 보시다시피 원래 TSF Candidate UI를 보여주며 한자의 음과 훈이 표시되고 있습니다.



아래 그림은 전체화면 모드에서 한자변환을 하는 예입니다. 커스텀 UI를 사용합니다. 그리고 TSF를 지원함으로써 단어 단위의 한자변환이 가능함을 알 수 있습니다. (이러한 단어단위 한자 변환은 DirectX의 CustomUI 샘플코드로는 불가능한 것입니다.)



아래 그림은 일본어 입력기를 창모드에서 사용하는 예입니다. 일본어 입력기의 Candidate UI는 추천단어에 관한 보다 자세한 정보를 따로 보여 주고 있습니다.




아래그림은 또 다른 한글의 단어단위 변환예입니다.



TSF는 키보드 입력 뿐만아니라 다양한 종류의 입력 (음성인식, 필기인식 등)을 지원합니다. 또 완성된 글자의 재변환 (reconversion) 혹은 수정 (correction) 기능을 지원하여 추천 단어를 잘못 선택한 경우 아래와 같이 한자키나 수정 버튼을 이용하면 원래 변환한 단어를 자동선택하며 최초 입력했던 한글도 추천단어로 보여줍니다.

또 다른 예를 들어보면, 음성인식이나 필기 인식을 사용하여 글자를 입력한 경우, 재변환 기능을 이용하면, 원래 입력한 음성을 다시 들어 보거나 필기 인식한 글자의 모양을 볼 수도 있습니다.




한국어 사용자들은 게임상에서 실제 이용할지는 의문이나 필기 인식을 통해 한자를 입력하는 화면입니다. (일본인이나 중국사람들은 가끔 이 기능을 이용한다고 합니다.)




어쨋거나, 길드워는 비스타에서 TSF를 제대로 지원하게 되어 한자변환 추천리스트를 표시하는데 아무런 문제가 없어졌습니다.


크리에이티브 커먼즈 라이센스
Creative Commons License
IME, TSF, 게임, 길드워, 비스타, 입력기
트랙백 0 : 댓글 0

비스타(Vista)에서 Visual Studio 2005 버그

프로그래밍 일반/디버깅 2007/06/30 15:28

어제 VS의 디버그 심볼 서버를 사용하다가 VS가 다시 실행되지 않는 심각한 문제가 발생하였습니다.  VS를 실행하면 다음과 같은 다이얼로그 박스만 덩그러니 나타나고 끝나버려, 정말 황당할 수 밖에 없었는데, 오늘 겨우 그 원인과 해결 방법을 찾았습니다.


어제부터 VS를 두번이나 재설치하고 레지스트리를 변경하고 여러 가지 해보았지만 소용 없었습니다. 그런데, 심볼 서버의 캐시 폴더 설정이 제대로 동작하지 않더군요(Tools->Option->Debugging->Symbols 메뉴에서 설정). 즉, c:\websymbols로 캐시 폴더를 설정 하였으나, 실제로는 DevEnv.exe가 있는 폴더에 디버그 심볼 캐시를 만드는 것이었습니다. 이중에 "version.dll" 이라는 폴더도 생성되었는데, 이것이 바로 문제의 원인이었습니다. DevEnv.exe가 현재 디렉토리에서 version.dll을 로드하려다가 실패하고 그대로 종료하는 것이었습니다. 이 디렉토리를 삭제하니 모든 것이 정상 작동하였습니다.

호기심에 이번에는 "c:\Program Files\Microsoft Office\OFFICE11" 폴더에 "version.dll"폴더를 만들어 보았습니다. 그러니 이제 MS Word(winword.exe)를 실행하니 바로 크래시 되는군요. 다른 몇개의 프로그램도 같은 증상이 나타나고 있습니다.

이 문제는 Vista에서만 발생하는 것으로 보이며 생각보다 심각한 것 같습니다. 이를 악용하여 프로그램을 일부러 크래시 시킨다면 시스템 보안에도  문제가 생길 수 있어 보입니다.

크리에이티브 커먼즈 라이센스
Creative Commons License
버그, 비스타, 비주얼 스튜디오
트랙백 0 : 댓글 0

인텔 4세대 센트리노 CPU 곧 발매 예정

CPU 2007/02/28 11:42
요즘 새로운 노트북을 장만하려고 노트북 스펙과 리뷰기사를 읽고 있습니다. 그런데, 최근 기사에 따르면 인텔에서 제4세대 센트리노 플랫폼인 센트리노 프로(Centrino Pro)를 곧 발매할 예정이라고 합니다.

코드네임 산타로사(Santa Rosa)로 명명된 새로운 모바일 플랫폼에는 800Mhz 프런트 버스를 가지고 있는 코드네임 메롬(Merom) 제2세대 듀얼코어 CPU와, 코드명 크레스트라인(Crestline)인 956 익스프레스 칩은 인텔의 GMA X 3000 그래픽 기술과 함께 작동하며 윈도우즈 비스타의 에어로 기능의 가속을 지원하는 엑셀러레이터도 포함된다고 합니다. 자세한 내용은 아래 위키를 참고하시기 바랍니다.

http://en.wikipedia.org/wiki/Centrino

거기다가 차세대 무선랜인 Wi-Max도 포함될 것으로 예상되, 상당히 매력적인 스펙임에 틀림이 없습니다. 5월쯤에는 산타로사 플랫폼 노트북이 대거 출시될 것으로 예상되므로 아무래도 노트북 구입시기를 조금 늦춰야할 것 같습니다.

그리고, 최신 노트북은 모두 윈도우즈 비스타가 설치되어 있는데, 여러 리뷰기사를 통해 나타난 바와 같이, 아직 DirectX 10을 지원하는 그래픽 드라이버가 나올 때까지는 XP가 더 성능이 좋고 안정되어 있는 것으로 보입니다. 특히 아래 리뷰 기사에서는 비스타에 대해 혹평하고 있는데, 상당히 신빙성이 있어 보이는군요. "Windows Vista is Windows ME Part 2." 라고 한 것은 상당히 인상적입니다. ^^

또, 최근 발표된 대부분의 CPU가 64비트 연산을 지원하지만 아직도 비스타는 32비트에 머무르고 있습니다. 64비트 버전의 사용을 원하는 사람에게 발송해준다고 하는데, 아직도 64비트 버전이 불안하거나 성능이 좋지 않기 때문에 본격적인 시판을 하지 않는 것으로 보입니다. 물론 기존 32비트 응용프로그램과의 호환성 문제도 해결하기 힘든 것 중의 하나입니다.

http://www.notebookreview.com/default.asp?newsID=3529
크리에이티브 커먼즈 라이센스
Creative Commons License
CPU, 비스타, 산타로사, 센트리노 프로, 인텔
트랙백 0 : 댓글 2
◀ PREV : [1] : NEXT ▶