1.

잘 알다시피 올해 하반기부터 드디어 <날개셋> 한글 입력기가 7.x 시대로 진입했다. 1.0이 개발된 지 13년 만의 일이다.
수없이 많은 소프트웨어들이 넘쳐나는 시대에 딱 하나 정도는 내 손으로 직접 만든 프로그램을 나 자신이 유용하게 쓰고 있다는 게 뿌듯하다. 그것도 우리나라의 고유 문자인 한글을 전문적으로 다루는 독특한 프로그램이고, 사람이 다루는 수많은 정보들 중 가장 기본적이고 원천적인 것에 속하는 텍스트 데이터를 취급하는 프로그램이니 말이다.

7.0은 공개된 지 40일이 넘게 지난 현재까지 다음과 같은 몇몇 버그들이 발견되어 고쳐졌다.

편집기

(1) 한 줄당 200칼럼이 넘는 1920급의 가로 해상도에서, 그리고 '자동 줄바꿈' 옵션을 끈 상태에서 <날개셋> 편집기의 문서창을 최대 크기로 곧장 열었을 때 글자가 제대로 표시되지 않고 오동작이 발생하는 문제를 확인하여 고쳤다.
이것은 이번 7.0에서 처음으로 등장한 문제는 아니고 예전 버전부터 있었다. 단지 재연 조건이 흔치 않기 때문에 지금까지 발견되지 않았던 것이다.

(2) 사용자 정의 후보 변환을 쓰면, 사용자가 선택한 후보의 다음 후보들까지 한 줄에 하나씩 나란히 다 삽입됨

외부 모듈

(1) Windows 8의 Modern UI에서 옛한글이 여전히 입력되지 않음.
이것은 다른 문제가 아니라, Modern UI에서는 레지스트리에 접근이 되지 않아서 옛한글 표현 방식 옵션이 제대로 전달되지 않아서 발생한 현상이다. 내가 미처 생각하지 못한 상황이었으며 문제는 즉시 해결했다.

(2) Visual Studio 2012의 일부 검색 입력란에서 한글이 연속 입력될 때 다음 음절의 첫 타가 씹히던 문제.
<날개셋> 한글 입력기로부터 받은 문자 조작을 운영체제의 TSF layer로 옮기는 핵심 루틴을 모처럼 고쳐야 할 정도로 대단히 어려운 문제였다. 다른 프로그램들은 이렇게만 써 주면 아무 문제 없이 동작하는데, 저 프로그램은 특이하게 동작해서 그랬다.

(3) 이 외에 프로그램을 아주 극단적으로 특수하게 사용하지 않는다면 마주칠 일이 거의 없는 사소한 문제

또 일부 제어판 GUI에서 리스트박스의 아이템 높이가 현재 시스템 글꼴의 세로 크기를 정확하게 반영하도록 고치고(고해상도 환경 대비), 일부 영문 GUI의 텍스트와 도움말 본문을 살짝 수정했다.

2.

<날개셋> 한글 입력기 7.0에 뒤이어 올여름엔 Windows도 8.1이 나왔다.
윈도 8과 윈도 8.1의 관계는
윈도 98과 98 SE
윈도 95와 95 OSR2
윈도 XP와 XP sp2

의 관계에 얼추 대응하는 듯하다. 이제는 버전도(3.x, 4.0)도, 연도(95/98/2000)도, 고유명사도 아니고(XP/Vista), 버전과 무관한 숫자를 브랜드명으로 쓰는 이상한 관행이 생겼다. 잘 알다시피 윈도 7의 내부 버전은 6.1이고, 8과 8.1의 버전은 6.2이다.

잠깐 써 봤는데 생각만치 큰 차이는 없다. 시작 '버튼'만이 부활했을 뿐 그걸 클릭한다고 해도 과거의 시작 메뉴가 뜨는 것은 아니며, 여전히 전체 화면을 차지하는 시작 화면이 나온다.
<날개셋> 한글 입력기나 타자연습, 파워업이 윈도 8.1만을 위해 딱히 업데이트되어야 할 필요는 다행히 없는 것 같다. 다들 주요 기능들이 잘 동작한다.

차이라면 차이를 찾은 게 뭐냐 하면 8.1의 Metro(Modern) UI는 보안 모드에서도 TSF A급으로 동작하게 된 듯하다.
한글에 대해 한자 변환을 해 보면 한자들의 훈과 음이 뜨지 않고 유니코드 BMP 한자가 아니라 한국 상용 한자 4888자만 달랑 뜨는 모드가 있는데, 그게 바로 보안 모드이다.
날씨 앱을 실행한 뒤, 지역 추가 버튼을 눌렀을 때 뜨는 입력란이 보안 모드에 속한다.

보안 모드에서는 IME가 ProgramData나 사용자의 문서 디렉터리에도 전혀 접근을 할 수 없어서 자신의 동작에 필요한 파일을 제대로 읽을 수 없다. 그래서 한자 후보도 그렇게 볼품없게 나오는 것이다.
다만, 모든 Metro UI가 보안 모드인 건 아니다. 가령, Metro용 Internet Explorer는 주소 입력란이 보안 모드가 아니기 때문에 한자 후보가 데스크톱과 똑같이 제대로 뜬다.

8 시절에는 보안 모드에서는 파일도 제대로 못 읽을 뿐만 아니라 입력란이 TSF A급으로 동작하지도 않았는데
8.1 평가판을 써 보니, 그때도 비록  한자의 훈과 음은 안 뜨지만 TSF A급으로 동작하여 backspace 달라붙기 기능도 잘 되고, 단어 단위 한자 변환도 잘 되더라. 이걸 확인했다.

2-1.

8.1에만 해당되는 건 아니고 8부터 그랬던 것이긴 하지만,
원래 운영체제의 에디트 컨트롤은 특별히 TSF A급 확장으로 동작하고 있지 않을 때는 딱히 후보 창을 표시할 위치를 설정해 주지 않았었다. 그래서 MS IME든 날개셋에든 한자 후보 변환을 시켜 보면, 한자 선택창이 cursor의 위치와 관계없이 언제나 화면 우측 하단에 고정되어 나타나곤 했다. 윈도 7까지만 해도 말이다.

그랬는데 8부터는 에디트 컨트롤도 후보 창이 cursor의 아래에 나타난다.
MS에서 딱히 이런 동작까지 일부러 신경 써서 바꿀 것 같지는 않았는데 의외이다.

하지만 메뉴를 오른쪽 정렬로 띄우는 옵션은 도대체 왜 넣었는지 알 길이 없다. 아랍권이 아니면 전혀 필요 없을 기능인데 왜 한글/영문판에다가도 기본으로 선택시켰는지 원?

3.

드디어 공개한다. 내 홈페이지의 영문 버전을 개설했다.
본인에 대한 아주 최소한의 소개와 <날개셋> 한글 입력기 페이지만 존재한다.
Kim Yongmook's Official Home Page
Nalgaeset Hangul Input System

새로 만드는 영문 사이트는 prg4.html 같은 구식 주소 대신 ngs라는 디렉터리를 통째로 사용하며, 인코딩도 UTF8로 돼 있다.
도움말 전문이 영어로 좀 번역돼야 하는데 도저히 그럴 엄두가 안 나니, 외국인에게는 세벌식 같은 것보다는 현실적으로 훨씬 더 필요한 기능만 중점적으로 소개해 놨다. 바로 한글 로마자 입력 기능. 한영, 한자 키를 재정의 가능한 것도 덤이다.

그나저나 설치 프로그램 자체도 다국어 UI가 지원돼야 하는데 이건 비주얼 스튜디오가 기본으로 제공하는 설치/배포 프로젝트만으로 어찌할 수 없는 사항인지? 이 역시 아쉬운 점이다.
어쨌든, <날개셋>이 벌써 7.0까지 나왔으니, 이제는 내 프로그램을 국제적으로 알리는 것에도 신경을 쓸 계획이다.

Posted by 사무엘

2013/08/20 08:37 2013/08/20 08:37
Response
No Trackback , 29 Comments
RSS :
http://moogi.new21.org/tc/rss/response/868

Trackback URL : http://moogi.new21.org/tc/trackback/868

Comments List

  1. 김기윤 2013/08/20 09:19 # M/D Reply Permalink

    윈도우 8.1의 버전이 6.2 었나요!? 6.3으로 알고 있었는데 제가 잘못 알고 있었군요..

    Windows 8 영문 위키 페이지의 latest preview release 에 버전이 6.3 (Build 9431) 이라 적혀 있어서 영락없이 6.3 인줄 알고 있었습니다..

    1. 사무엘 2013/08/20 09:44 # M/D Permalink

      응? 저의 정보가 out-of-date인 걸수도 있습니다. 제가 지난 6월? 7월쯤에 직접 받아서 써 본 8.1 preview는 내부 버전이 여전히 6.2여서 말이죠~! 그 새 버전도 올라갔는가 봅니다.
      Modern UI가 모두 TSF A급으로 바뀌고 내부적인 안정성도 더욱 향상되었더군요. 문자 입력 쪽으로는 확실히 좋아진 점이 있었습니다.

    2. 김기윤 2013/08/24 01:57 # M/D Permalink

      이런 글을 보았습니다.

      http://www.neowin.net/news/final-windows-81-rtm-version-number-may-be-639600

      최종적으로는 6.3 이 되는 듯 합니다~

    3. 사샤나즈 2013/08/29 18:22 # M/D Permalink

      6.3 맞습니다. 8.1 프리뷰에서 빌드가 6.3.9431로 나와요.

  2. 근성인 2013/08/20 15:11 # M/D Reply Permalink

    영문 페이지에서도 룩킹포유 소개에 많은 내용을 쓸 것이라 생각하고 눌러봤는데, 진짜였어...

    1. 사무엘 2013/08/20 21:31 # M/D Permalink

      후훗~~~ 그건 당연한 거 아님?? ㅋㅋㅋ

  3. 사샤나즈 2013/08/29 18:49 # M/D Reply Permalink

    8.1은 프리뷰 버전일 뿐이라 보고를 보류하고 있었는데, 이번 유출된 RTM 버전에서 해 보니 같은 문제가 있길래 올려 봅니다.
    http://sdrv.ms/19Pt9SX (기본 입력기)
    http://sdrv.ms/17kZUZM (날개셋)

    Modern UI IE11에서 주소를 칠 때 기본 입력기에서는 자동완성이 되는데, 날개셋 입력기에서는 자동완성이 되지 않는 문제가 있습니다. 프리뷰에서도 RTM에서도 같은 현상이 있네요..

    1. 사무엘 2013/08/30 04:29 # M/D Permalink

      흠, 한글도 아니고 영문 모드의 동작 방식 차이는 IME 차원에서 만들어 낼 수 있는 게 아닌 거 같은데.. ㅡ,.ㅡ;; 두 가지 사항을 추가적으로 확인 부탁드립니다.

      1. 날개셋의 영문 자판도 드보락 같은 게 아니라 '빈 입력 스키마와 호환' 옵션이 맞춰진 쿼티이죠?

      2. 예전의 윈도 8은 안 이랬는데 8.1부터만 차이가 발생하나요?

    2. 사무엘 2013/08/30 05:17 # M/D Permalink

      내부 버전이 여전히 6.2이던 시절의 8.1 초기 스냅샷으로도 말씀하신 현상을 정확하게 재연 확인하였기에 자문자답을 하겠습니다.

      '빈 입력 스키마와 호환' 옵션이 맞춰진 쿼티는 자동 완성이 되고, 드보락처럼 IME가 인위로 생성한 영문 입력은 suggestion만 위에 뜨지 자동 완성이 되지는 않는군요.
      이것은 IE의 동작 방식 자체가 일부러 바뀐 것입니다. 제 프로그램과는 무관한 현상입니다.
      게다가 과거의 윈도 8은 둘 모두 자동 완성이 됐는데 8.1부터는 둘을 구분하게 바뀐 것이네요..! 생각도 못 했는데 꽤 재미있는 차이를 발견하셨습니다.

    3. 사샤나즈' 2013/08/30 16:23 # M/D Permalink

      그럼 현재는 딱히 해결책이 없는 거군요. 답변 감사합니다. ㅠㅠ

      그런데 윈도8.1이 최초로 유출되었던 빌드 9364, 이후 빌드 9385, 프리뷰로 정식 배포된 빌드 9431, 유출된 RTM 빌드 9600 모두 6.3이었는데 6.2인 적이 있었나요..?

    4. 사무엘 2013/08/30 22:26 # M/D Permalink

      1. 제가 갖고 있는 물건은 빌드 번호가 9431짜리인 프리뷰입니다.
      윈도 운영체제의 About 화면에서는 버전 6.3, 빌드 9431이라고 나타나지만,
      윈도 API로 내부 버전값을 구해 보면 6.2.9200가 잡히거든요. (날개셋 편집기의 About 대화상자에서 확인 가능)
      RTM은 어찌 되었나 궁금합니다.

      2. 음 그리고 말이 나온 김에.. 하나 좀 여쭙시다.
      윈도 8이나 8.1에서..
      날개셋 프로그램들의 대화상자 중에 수식을 입력받는 입력란을 아무거나 가 보세요.

      가령, 편집기에서 "찾기-문자 영역", 혹은 입력기 제어판에서 "편집기 계층-최종 변환 -> 적용 조건" 등.
      거기서 A+B를 입력해 보면, A+B가 되는 순간 cursor가 왼쪽으로 가 버리는 현상이 있습니까?
      윈도 8부터만 나타나는 버그 같거든요. 확인 부탁드립니다.

  4. ellif 2013/09/13 08:53 # M/D Reply Permalink

    오랜만입니다.

    혹시 나래셋에 가능하시다면 리프식 로마자 표기법 인풋 추가 가능한가요.
    http://e11if.tk/lifroma

    검토해주시고 적용해주시면 표기법 홍보에도, 외국인분들에게도 도움이 될 것 같습니다.
    댓글 읽어주셔서 감사합니다.

    1. 사무엘 2013/09/13 21:11 # M/D Permalink

      안녕하세요?
      연구하신 것은 한글→로마자로 대응하는 변환 규칙일 뿐이지 딱히 글쇠배열 같은 입력 방식을 규정하고 있지는 않네요.
      원하는 것을 분명히 해 주시고, 직접 입력 방식을 만들다가 모르는 기능이나 기술적으로 막히는 게 있으면 제게 질문해 주시면 좋겠습니다.

      그나저나 규칙이 굉장히 파격적인 한편으로 흥미롭네요. 특히 쌍자음을 알파벳 하나에다 대응시킨 건 F-ㄸ 하나만 어쩔 수 없이 좀 이질적이고 나머지는 생각보다 직관적인 거 같습니다. ㅎㅎ

    2. 사샤나즈 2013/10/09 21:14 # M/D Permalink

      글 아래쪽에 링크하신 프로그램을 보고 유추하건대 아마 원하시는 것이 아마 리프식 로마자 표기법으로 입력하면 그에 따라 한글이 입력되는 그런 것인 듯합니다. 아마 히라가나 입력처럼 만들 수 있을 것 같네요.

    3. ellif 2013/10/09 22:49 # M/D Permalink

      예를 들어서 '.arira@' 이라고 입력하거나 'arira@', 또는 'arirang'을 입력하면 '아리랑'이 나오는 경우이겠지요. 리프식 로마자로 입력시에는 몇가지 고려해야 할 스펙이 더 있어서 고민되기는 합니다. 가령 '^'나 '@', '~'의 입력시에는 ㅇ이 아니라 @, ㅐ가 아니라 '~'를 넣어야 할 때는 어떻게 해야 하냐라던가...()

      이런 스펙은 문과인 저의 한계상 개발할 수 없습니다. 그래서 굳이 부탁을 드리려고 했던 것입니다.

    4. 사무엘 2013/10/10 00:15 # M/D Permalink

      한글을 조합 중일 때의 여부에 따라(초성 입력 중일 때, 중성 입력 중일 때, 한글을 조합하는 상태가 아닐 때 같은) 조건부로 다른 글자가 입력되는 글쇠 정도는 제 프로그램으로 구현이 가능하지만,
      cursor 앞뒤에 있는 글자 문맥에 따라 서로 다른 글자가 조건부로 찍혀야 하는 것은 구현할 수 없습니다.
      리프식 로마자 표기법에 기반한 로마자 한글 입력법은 모든 규칙을 딱 저 형태로 추스릴 수 있는가요?
      스스로 생각하기에, 아래아한글이 제공하는 것 같은 기존 한글 로마자 입력 방식보다 기술적으로 더 변칙적인 게 존재한다고 여겨지는지요?

    5. ellif 2013/10/17 23:07 # M/D Permalink

      리프식 로마자 표기법이 일반적인 한글 자판 입력과 다른 매커니즘이 발생하는 경우는 다섯 가지 정도입니다.

      1) 초성 .의 경우에는 처음에 어두에 찍는 .를 ㅇ로 변환,
      2) 입력 중 .을 찍고 곧바로 모음 입력이 이루어지는 경우는 'ㅇ+자음'으로 자동 변환, 자음 모음이 이루어지면 .를 그대로 유지 (ga. → '가.' ga.a → '가아' ga.q → '가.ㄱ' )
      3) y는 'ㅣ' 출력 후 추가 모음에 따라 처리, 마찬가지로 w도 'ㅡ'출력 후 추가 모음에 따라 처리.
      4) .e의 경우에는 'ㅇ'-'의'로 입력했다가 다음에 .ege 를 '의게'로 읽지 않도록 몇몇 경우에는 자동 보정을 해준다거나,정확하게 .Ege로 입력할 때만 '에게'로 출력하면 될 문제(이 경우 .ege는 '의게'로 입력됩니다. 워드프로세서에서도 쉽게 정정할 수 있는 부분이지요.) '엑에'를 입력할 경우는 '.Eg.e'로 중간에 .을 찍으면서 초성 구분이 되니까 매커니즘이 헷갈릴 이유는 없다고 봅니다.
      5) @, ~, ^, _, )는 초성에서는 그대로,
      중성 입력시에는 ~, ^, _, )는 ㅐ, ㅓ, ㅡ, ㅚ로 변환, 그 상태에서 한 번더 입력할 시에는 ㅐ~, ㅓ^, ㅡ_, ㅚ)를 출력
      종성에서는 @-> 종성ㅇ, @@ ->'ㅇ@'를 출력하면 됩니다.

      일단 고어 지원까지 당장 고려하기는 어렵지만, A는 아래아,B는 여린비읍(cf. BAig ㅸ.ㅣㄱ) (. Z는 반시옷(Zam - △ㅏㅁ), H는 여린히읗 정도 입력까지 지원해두면 좋을 것 같습니다.

    6. 사무엘 2013/10/19 20:31 # M/D Permalink

      2) '.'가 '아'로 바뀌는 부분은 현재의 <날개셋> 한글 입력기로 구현 가능한 기술 수준이 아니네요.

      한 글쇠가 현재 초/중/종성을 입력하는 상황이냐, 한글 조합 중이 아니냐에 따라서 조건부로 서로 다른 문자나 한글 자모를 입력시키는 것은 괜찮지만, 이미 화면에 표시된 문자가 한글과 비한글 사이를 왔다 갔다 해야 하는 것은 일반적으로 구현 가능하지 않다고 생각하시면 됩니다.

      또한 이미 입력된 자모가 다른 성분의 자모로(가령, 초성에서 중성으로) 변하는 것은 불가능은 아니지만 굉장히 복잡한 편법을 동원해야 하며 어렵습니다. 같은 성분의 자모로의 변화는 문제 없이 가능합니다.

    7. ellif 2013/10/19 21:25 # M/D Permalink

      제가 글을 쓰면서 혼선을 드렸던 모양인데요, .를 치면 그냥 'ㅇ'만 반환하면 됩니다. '.a' 가 '아'가 되지요. 말씀하시는 대로라면 오히려 arira@을 쳤을 때 ㅏ리랑이 아닌 아리랑을 반환하기 어려운 문제가 있다고 보이네요.

      그리고 리프식 로마자 표기법은 하나의 입력 체계만 받아야 할 것입니다. (영어는 한영키로 수정하고요)
      키보드 자판은 조만간 생각해서 만들어보겠습니다.

    8. ellif 2013/10/21 18:24 # M/D Permalink

      일단 키보드 자판안은 이러면 될 것 같습니다.
      http://e11if.tk/lifroma_key

    9. 사무엘 2013/10/21 23:22 # M/D Permalink

      ga. → '가.' ga.a → '가아' ga.q → '가.ㄱ'

      라고 명시를 하셨으니, 이미 입력했던 멀쩡한 마침표가 한글 자모로 바뀌거나 vice versa가 일어나야 하는 건 사실이지 않은가요? 그것이 제 프로그램으로 가능하지 않다는 얘기입니다.
      글쇠배열은 잘 봤습니다. 다만 ㅇ과 .이 중첩 배당되어 있는 건 어떻게 처리해야 할지 고민해 봐야 할 것 같습니다.
      얘기가 길어지는데요, 이와 관련해서 혹시 제게 더 하실 말씀이 있으면 메일로 의견을 주고받는 게 어떨까 싶습니다. ( sebulsik 드림위즈)

  5. 사샤나즈 2013/10/09 21:13 # M/D Reply Permalink

    이전에 윈도8 Modern 환경을 지원해 주실 때 비 Modern 환경에서 한번 입력기 로드를 한 뒤여야 제대로 작동을 한다고 하셨습니다만, PC 사용시에 Modern 환경으로 먼저 들어갈 때가 생각보다 잦아, 설정을 불러오지 못하고 해당 애플리케이션 속에서 강제로 두벌식에 묶이는 현상을 겪습니다.

    말씀해주신 것에 따르면 현재 그럴 수밖에 없는 것이겠습니다만, 혹시 설정을 강제로 다시 불러오도록 시도하는 단축키라든가를 만들 수는 없을까요? 해당 애플리케이션을 완전히 껐다 켜면 어찌됐든 입력기가 다시 제대로 작동합니다만 때때로 이렇게 되면 애플리케이션상에 써놓은 글이 날아가 버린다거나 (따라서 그 전에 어떻게든 백업을 해야 한다거나) 하는 일이 발생하기 때문에 이런 기능이 있으면 어떨까 싶습니다.

    1. 사무엘 2013/10/10 00:16 # M/D Permalink

      예. Modern과 비 Modern 사이엔 레지스트리, 공유 메모리, 파일 등 그 어떤 수단으로도 입력 설정을 주고받을 방법이 절대적으로 없어서 이건 도저히 불가피하게 취해진 제약입니다. 윈도 8이 무슨 철학으로 개발되었는지 이해가 안 되고 참 안타까운 면모이죠. 다른 해결책은 아직 딱히 떠오르는 건 없네요. :-(

      단, Program Files라든가 윈도 시스템 디렉터리처럼, write를 할 때 관리자 권한이 필요한 디렉터리는 Modern 앱들도 read용으로 접근이 됩니다.
      그렇기 때문에 비 Modern 프로그램에서 미리 그런 위치에다가 만들어 놓은 입력 설정 파일을 읽게 하면 문제를 이론적으로 “피해 갈 수는” 있지만..
      그 디렉터리들은 그런 용도로 사용하라고 있는 게 아니며, 입력 설정을 바꿀 때마다 사용자에게 UAC 대화상자를 노출시키면서 지저분한 방법으로 Modern UI를 지원할 의향은 없습니다.

    2. 사무엘 2013/10/14 17:34 # M/D Permalink

      아.. 인제 무슨 뜻인지 알겠네요.
      그 점은 미처 생각을 못 했네요.
      Modern부터 먼저 띄워 버린 뒤에 나중에 데스크톱에서 설정 동기화를 했다면, 이미 띄운 모던 앱으로 돌아오더라도
      현재 프로그램 구조상 거기는 아마 설정 동기화가 안 될 겁니다.
      다음 버전에서 개선 가능한 사항인지 한번 검토해 보겠습니다. :)

    3. 사샤나즈 2013/10/14 17:42 # M/D Permalink

      아뇨, 일단 제약 자체는 이해합니다만 그런 얘기가 아니었습니다.

      비 Modern 환경에서 한 번 불러온 뒤에 Modern 환경에서 불러오면 작동을 하지만, Modern 환경에서 먼저 불러오고 비 Modern 환경에서 불러온 뒤에 다시 아까 그 Modern 환경으로 돌아와도 작동은 하지 않더군요. 그렇다면 이 경우에 강제로 설정을 다시 불러오면 이미 비 Modern 환경에서 불러온 설정을 갖고 다시 Modern 환경에서 작동을 할 수 있지 않을까 해서 문의드린 것입니다.

      사실 Modern 환경에만 해당되는 것이 아니라 데스크탑 IE에서도 설정을 제대로 불러오지 못하는 현상이 이따금 나타나기에 이런 간접적인 해결책이 있다면 좀더 편할 것 같기에 말씀드려 봅니다.
      //오타가 있기에 수정을 했더니 답변보다 아래로 내려와 버렸네요. 하하하...

    4. 사샤나즈 2013/10/14 17:45 # M/D Permalink

      가능하다면 좋겠네요! 완전한 해결책은 아니지만 간접적인 해결책이라도 될 수 있길 바랍니다 :D 감사합니다!

    5. Lyn 2013/10/17 21:53 # M/D Permalink

      소켓 어떤가요 (....)

  6. Lyn 2013/10/17 21:52 # M/D Reply Permalink

    오늘 정식 업데이트 된 빌드 넘버는 6.3(9600) 입니다

    1. 사무엘 2013/10/17 22:26 # M/D Permalink

      1. 오 드디어 8.1 정발됐군요.!

      2. 실제로 MSDN을 보시면요,

      IMEs may need to share data about the user’s input preferences between apps that are in different app containers. Use a web service to share data between Windows Store apps.

      이걸 무슨 도움말이랍시고...
      그런데 소켓 쓰라는 말이나 다름없죠..;;

Leave a comment
« Previous : 1 : ... 1441 : 1442 : 1443 : 1444 : 1445 : 1446 : 1447 : 1448 : 1449 : ... 2204 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Site Stats

Total hits:
3045617
Today:
837
Yesterday:
1972