Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: '윈도우'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. 엠바카데로 블로그에 Muminjon이 쓴 "7 Signs You Need Help With Development On Windows"를 번역한 글 (원문 작성일: 2022년 3월 25일, 번역일: 2022년 4월 21일) 과거에는 소프트웨어 시스템 개발을 할 때 주로 데스크탑 애플리케이션을 주로 만들었다. 유틸리티, 작은 도구, 구조가 복잡한 앱 등 무엇이든 모두 데스크탑 애플리케이션이었다. 이후 인터넷 기술이 개발 세상을 바꿔 놓았다. 예를 들면, 당신이 앱을 만들면 모두가 자동으로 업데이트를 받을 수 있다. 하지만, 복잡한 시스템을 구축하기에는 당시 인터넷 아키텍처 인프라, 기반 프로토콜, HTTP 이나 HTML 같은 표준들이 충분히 준비되어 있지 않았다. 데스크탑 애플리케이션을 사용하면 웹 앱이나 모바일 앱으로는 도달할 수 없는 수준으로 때 생산성이 높고 성능이 매우 빠르기 때문에, 웹 앱과 모바일 앱에 대한 통계에도 불구하고 데스크탑 애플리케이션은 여전히 고유한 영역을 지배하고 있다. 많은 개발자들이 델파이, C++, C#을 가지고 프로젝트를 구축하는 이유가 바로 이것이다. 많은 경우 첫 선택은 윈도우로 개발하는 것이다. 목차 데스크탑 애플리케이션을 개발하는 이유는? 복잡한 UI 디자인은 올바른 도구를 사용하면 훨씬 쉽게 구현할 수 있다 잘못된 도구를 선정하면 생산성이 낮아지거나 오히려 더 나빠지기도 한다. 더 좋은 코드 가독성은 더 좋은 생산성으로 직결된다 잘못된 도구 선정은 윈도우의 최신 기능을 당신의 앱에서 지원하지 못하게 된다는 의미가 될 수 있다 새 네이티브 UI 프레임워크 – WinUI 3 느린 컴파일러가 당신의 개발 시간을 잡아먹고 있지는 않는가? 당신이 사용하고 있는 도구체인이 불필요하게 복잡한가 아니면 RAD 스튜디오처럼 클릭 한번으로 작동하는가? 핵심 런타임 패키지를 당신의 앱에서 놓치고 있지는 않은가? 데스크탑 애플리케이션을 개발하는 이유는? 다음과 같은 이유들로 인해 당신은 개발을 할 때 데스크탑 애플리케이션을 만들게된다. 성능이 훨씬 높다 멀티-쓰레딩 앱이 훨씬 효율적이다 하드웨어 장비에 접근하기 쉽다 윈도우 데스크탑 애플리케이션 개발에 관한 전문가와 KB(축적된 지식)이 많다 덜 복잡하고 쉽게 시작하기 쉽다 데스크탑 개발은 그 범위가 상당하기 때문에, 데브스탑 애플리케이션을 개발하는 도구 역시 수천가지에 이른다. 예상할 수 있겠지만, 모든 도구들이 효율적이거나, 사용하기 쉽거나, 윈도우의 최신 기능을 지원하는 것은 아니다. 이 글은 더 좋은 결과를 만들 수 있는 윈도우 소프트웨어 개발 도구에 대해서 논의한다. 복잡한 UI 디자인은 올바른 도구를 사용하면 훨씬 쉽게 구현할 수 있다 마이크로소프트는 어떤 애플리케이션도 만들 수 있도록, 모든 도구와 개발 라이브러리와 프레임워크를 제공한다. WPF, 윈도우 데스크탑 개발용 UWP, 크로스-플랫폼 앱 개발 용 MAUI 등이 그것이다. 그러나 UI(사용자 화면)를 디자인하려면 XAML을 사용해야 한다. 이와 달리 RAD 스튜디오의 델파이는 UI를 매우 빠르게 개발할 수 있는 환경을 제공한다. 시각적 컴포넌트 또는 기능 컴포넌트를 폼(form) 위에 끌어다 놓기만 하면 된다. 게다가, 크로스-플랫폼 앱 개발 프레임워크인 파이어몽키(FireMonkey)에서는 UI 요소 안에 다른 UI 요소를 놓아 둘 수 있기 때문에, 수준높은 UI가 필요할 때 특히 유용하다. 더 나아가, 스타일난 적용해도 UI/UX 전체를 완전히 다르게 바꿀 수 있다. 델파이의 시각적 컴포넌트 라이브러리 중 하나인 수상 경력이 빛나는 VCL은 윈도우 앱 개발 산업 분야에서 가장 안정적인 프레임워크이다. 이유는? 델파이는 27년이 넘도록 사용되고 있고 지금도 적극적으로 개발되고 있다. 그리고 20년 전에 델파이로 개발된 앱이 현대식 윈도우 운영체제와 장비에서도 여전히 잘 작동한다. 델파이에서 크로스 플랫폼 반응형 UI를 구현하는 시각적 프레임워크인 파이어몽키(FMX)는 안드로이드, iOS, 맥OS, 리눅스, 윈도우, 웹 애플리케이션을 코드 베이스 하나에서 만들려고 할 때 사용하는 크로스-플랫폼용 고급 개발 프레임워크이다. 잘못된 도구를 선정하면 생산성이 낮아지거나 오히려 더 나빠지기도 한다 화면이 있는 애플리케이션을 개발할 때 델파이는 시중에 있는 어느 GUI 개발도구보다 5배 이상 빠르게 개발할 수 있다. 델파이로 몇 초 만에 데스크탑 화면과 모바일 애플리케이션 UI를 아름답게 디자인 할 수 있다. 툴 팔레트에서 시각적인 컴포넌트와 기능 컴포넌트를 쉽게 끌어다 놓을 때는 시각적인 디자인 메뉴를 사용한다. 프로토타입을 더 빠르게 만들 수 있도록 디자인 화면에는 위치 보조선이 표시되고 여백(margin, 바깥쪽 여백)과 패딩(padding,안쪽 여백)을 사용할 수도 있다. 개발 화면에서 VCL 스타일을 사용해보라! 멋진 스타일이 반영된 UI를 훨씬 더 빠르게 만들 수 있다. 스타일이 적용된 폼과 컴포넌트가 실행 시 어떻게 보일 지는 개발 화면에서 바로 볼 수 있다. 더 좋은 코드 가독성은 더 좋은 생산성으로 직결된다 델파이를 사용하고 VCL 또는 FMX 프레임워크를 경험해 본 개발자는 크로스-플랫폼과 반응형 UI를 구축하는 것이 쉽고 UI/UX에 관련된 코드가 많이 필요없다는 사실을 알고 있다. 예를 들어 마이크로소프트의 UI 프레임워크를 사용한다면 복잡한 UI를 구축할 때 XAML을 사용해야 한다. 그래도 괜찮다고 생각할 수 도 있겠지만, 델파이의 VCL과 파이어몽키로 앱을 만들어 보게 된다면, 델파이로 앱을 개발하는 경험이 얼마나 좋은가에 대해 우리가 왜 이렇게 강조하는 지를 이해하게 될 것이다! 게다가, 델파이의 구문(syntax)은 현존하는 개발 구문(syntax)들 중에서 가장 쉽다. 다른 개발 구문에서는 띄어쓰기와 괄호 맞추기 등을 주의해서 작성하지만, 델파이로 코드를 작성하는 일은 마치 영어로시를 쓰는 것과 같다. 잘못된 도구 선정은 윈도우의 최신 기능을 당신의 앱에서 지원하지 못하게 된다는 의미가 될 수 있다 이로 인해 자칫 사용사의 사용성을 위축시킬 수도 있고 당신의 앱이 구식이고 퇴물이라는 인식을 사용자에게 줄 수 있다. 델파이의 시각적 컴포넌트 라이브러리 아키텍처는 매우 잘 구현되어 있어서 장비의 순수한 성능과 윈도우 운영 체제 개발 도구의 최신 기능들을 모두 얻을 수 있다. RAD 스튜디오 IDE(통합 개발 환경)에는 당신이 현대적인 윈도우 11 애플리케이션을 개발할 때 필요한 모든 도구들이 들어 있다. 예를 들어 윈도 11에는 웹뷰2(WebView2) 컨트롤이 들어 있는데, 델파이의 VCL에는 TEdgeBrowser가 있고 MSIX 배포를 부드럽게 할 수 있다. 게다가, 윈도우 11 최신 VCL 스타일들을 겟잇 패키지 매니저에서 받을 수도 있다. 윈도우 11에서 가장 눈에 띄는 시각적인 요소는 corners 같이 둥근 모서리가 적용된 UI 컨트롤들이다. 당신이 만드는 앱에서 윈도우 11 둥근 모서리를 제어하는 방법에 대해서는 Ian Barker (MVP)가 쓴 이 튜토리얼을 따라해보라. 마이크로소프트에서 진행되는 모든 변화를 보면, 윈도우 에코시스템 환경에 맞는 앱 개발에 있어서, 네이티브 윈도우 개발이 가장 중요하며 앞으로도 계속 중심을 차지하는 방향으로 가고 있다는 점을 파악할 수 있다. 델파이의 시각적 컴포넌트 라이브러리는 클래식 API와 현대식 API (WinAPI, COM, and WinRT APIs)를 모두 맵핑하고 현재 트렌드를 지원한다. 새 네이티브 UI 프레임워크 – WinUI 3 윈도우 앱 SDK(Windows App SDK)에는 새 네이티브 UI 프레임워크인 일명 WinUI 3가 들어 있다. 윈도우 런타임 아키텍처에서 현재의 프레임워크는 WinUI 3이며, 델파이 애플리케이션에서는 이 WinUI 3 컨트롤을 쉽게 사용할 수 있다. 델파이 앱에서 WinUI 3를 활용하는 방법은 아래 이 튜토리얼을 통해서 배울 수 있다 델파이 WinUI 3 데모 네이티브 윈도우, 다시 중심으로 돌아오다. 느린 컴파일러가 당신의 개발 시간을 잡아먹고 있지는 않는가? 윈도우 데스크탑 개발 IDE는 여러 가지가 있고 모두 높은 생산성과 빠른 빌드/컴파일 시간을 약속하지만, 실제로는 모두 그렇게 되지 않는다는 사실을 알 수 있다. 델파이의 컴파일러는 시장에서 가장 좋고 가장 빠른 컴파일러 중 하나이다. 증거가 필요하다면 아래의 간단한 데모를 확인해보라: 빠르고 강력한 컴파일러 외에도, 델파이에는 신속한 애플리케이션을 개발하고 향상할 수 있는 방법들이 많다. RAD 스튜디오 IDE와 디버깅 기능을 지능적으로 활용하는 방법은 이 튜토리얼을 통해서 배울 수 있다. https://blogs.embarcadero.com/the-dark-secrets-of-faster-compilation-with-delphi/ 당신이 사용하고 있는 도구체인이 불필요하게 복잡한가 아니면 RAD 스튜디오처럼 클릭 한번으로 작동하는가? 소프트웨어 도구체인(toolchain)이란 복잡한 소프트웨어 개발을 완성하거나 소프트웨어 제품을 제공하기 위해 사용되는 소프트웨어 개발 도구들의 집합을 의미한다. 개발 도구들을 잘 엮으면(chain) 소프트웨어 개발 절차를 최적화 할 수 있다. RAD 스튜디오 IDE는 어느 애플리케이션을 개발하든 가장 가치있는 플랫폼이다. 여기에는 도구들과 자동화 기능들이 안에 모여있기 때문이다. 예를 들면, 윈도우 용 애플리케이션을 개발한다면, 개발을 시작해서 마이크로소프트 스토어에 배포할 때 까지 필요한 모든 것들이 들어 있다. RAD 스튜디오 IDE 안에 있는 기능들을 활용할 수 있으면 가장 좋다. 또는, 리눅스, 맥OS, iOS, 안드로이드, 윈도우에 배포할 크로스-플랫폼 애플리케이션을 만들 때에도, RAD 스튜디오 IDE 안에는 모든 기능이 들어있다. 개발 절차가 성가시게 되지 않게 한다. 멀티-디바이스 애플리케이션을 만드는 절차(영문) 핵심 런타임 패키지를 당신의 앱에서 놓치고 있지는 않은가? 델파이 네이티브 윈도우 애플리케이션을 처음 작성하고 구축할 때, 당신은 효율적으로 배포할 수 있다. 구축된 애플리케이션은 어떤 윈도우 장비에서도 장비 안에 있는 라이브러리 또는 런타임을 요구하지 않고 잘 작동한다. 왜냐하면, 기본 설정인 경우, RAD 스튜디오는 컴파일을 한다. 그리고 필요한/사용되는 라이브러리/패키지를 실행파일(executable)안에 넣기 때문에 효율적으로 작동하게 된다. 그렇다. 아마 그렇게 하면 다른 솔루션들에 비해 실행파일의 크기가 더 크게 된다고 말할 수도 있겠다. 사실이다. 그러나 사용자 경험을 최우선으로 한다면, 애플리케이션이 올바르게 실행되기 위해 어떠한 런타임도 요구할 필요가 없게 만드는 것이 훨씬 더 좋고 애플리케이션 배포도 훨씬 더 손쉽다. 만약 실행파일 크기를 중요시 한다면, 구축한 애플리케이션 안에 패키지들을 포함하지 말고, 애플리케이션을 배포할 때 그 라이브러리/패키지 들을 함께 배포할 수도 있다. RAD 스튜디오의 최신 버전인 RAD 스튜디오 11 알렉산드리아를 다운로드 받아서 직접 보는 건 어떨까?
  2. 원문 링크: https://blogs.embarcadero.com/native-windows-is-back-to-center-stage/ 작성자(작성일): Marco Cantu (2021.11) UWP의 입지가 줄어들면서, 네이티브 개발이 다시 윈도우 개발의 주된 모델이 되었다. 그 사이에 있었던 닷넷까지 포함하면 20년만이다. 네이티브는 델파이가 가장 잘 하는 분야이므로, 델파이 개발자에게 정말 좋은 소식이다. ------------------------------------------------------------------------------------------------------------------------------------------------ 지난 몇 주 동안, 마이크로소프트는 윈도우 개발 면에서 과거의 방향을 일부 역행하는 발표를 했다. 요약하면, 마이크로소프트는 (완전히 버려지지는 않겠지만) UWP(Universal Windows Platform) 모델의 비중을 줄이고 있다. 이와 관련된 링크들은 다음과 같다: 마이크로소프트는UWP에서 Win32로 마이그레이션하는 방법에 대한 세부 사항들을 공개했지만, 아마 당신이 생각하는 것은 아닐 것이다: https://www.windowscentral.com/microsoft-publishes-uwp-win32-migration-details UWP는 더 이상 대세가 아니다. 마이크로소프트는 UWP 앱을 윈도우 앱으로 마이그레이션하는 가이드를 발표했다: https://www.neowin.net/news/uwp-no-longer-fashionable-as-microsoft-releases-guidance-for-migrating-apps-to-windows-app-sdk/ 마이크로소프트는 공식적으로 UWP를 더 이상 유지하지 않으려고 한다: https://www.thurrott.com/dev/258377/microsoft-officially-deprecates-uwp UWP가 당시 윈도우 개발의 중심 플랫폼이었던 닷넷 아키텍처를 대신하면서, 윈도우 8 이후부터 현재까지 UWP는 마이크로소프트 애플리케이션 개발의 중심이었다. 전통적인 네이티브 윈도우 개발 모델에 대한 집중을 유지해 온 개발자 (와 엠바카데로와 같은 도구 제조사)의 입장에서 볼 때 이 UWP의 쇠퇴는 매우 흥미있는 진화이다. 오랜 시간이 지난 뒤 네이티브 개발자가 다시 주류가 되었기 때문이다. 네이티브에서 .NET과 UWP까지 수년간, 네이티브 개발 모델 즉 클래식 윈도우 API를 사용하고, 윈도우의 3가지 핵심인 커널/유저/GDI 라이브러리와 그와 관련된 확장 모듈을 활용하는 개발 모델은 구식이고 더이상 사용되지 않고 곧 버려질 것으로 여겨졌다. 이 클래식한 방식은 델파이와 C++빌더 (VCL 라이브러리 포함) 뿐만 아니라 Visual C++ (MFC 라이브러리 포함)에서도 사용하는 방식이다. 처음에는 윈도우 개발자들에게 닷넷으로 옮겨가도록 권장했다 (앞으로는 닷넷이 있어야 플랫폼 API가 작동할 수 있게 되고, 클래식 애플리케이션은 언젠가 윈도우에서 실행되지 않을 것이라는 생각을 갖도록 만들었다). 시간이 지나면서, 그렇게 되지 않는다는 점이 분명해졌다. 닷넷 중심 방식이 약해지자, 마이크로소프트는 그 다음 아이디어를 밀어붙였다. 그것은 바로 UWP, 즉 유니버설 윈도우 플랫폼이었다. UWP는 두 가지 기본 컨셉을 중심으로 추진되었다. 첫번째는 동일한 애플리케이션이 데스크탑 PC 뿐만 아니라 윈도우 폰, 게임 콘솔, 바이저(역자주: 홀로렌즈와 같은 착용형 장비)에서 작동할 수 있다는 것이고, 두번째는 보다 안전한 플랫폼 즉 기본 운영 체제에 대해 제한된 접근이었다. API 수준에서 볼 때, UWP 지원은 곧 WinRT 플랫폼 API를 사용한다는 의미이다. 그런데 WinRT는 클래식 API와는 완전히 다르고 호환도 되지 않았다. UWP는 따라잡는 속도가 느렸다. 델파이와 RAD스튜디오에서 선택할 수 있는 것은 없었다. 뿐만 아니라 Visual C++, 닷넷, C#에서 UWP로 마이그레이션하는 작업은 기존에 사용되던 것과는 다른 런타임 라이브러리 그리고 다른 UI 컨트롤들을 사용해야 한다는 의미였다. 즉, 기존 애플리케이션 중에서 많은 부분을 다시 작성해야 했다. 윈도우 8이 처음 출시되었을 때 (기존 API 애플리케이션을 허용했던 시기)에는, 사용할 수 있는 UWP 앱이 마이크로소프트에서 제공하는 것까지 합쳐도 거의 없었다. 하지만, 윈도우의 새 플랫폼 기능 몇가지는 WinRT API를 통해서만 사용할 수 있었다. 바로 이 점 때문에 개발자와 (RAD스튜디오 등) 개발도구가 클래식 애플리케이션 안에서 WinRT API를 호출하는 방안을 고안하게 되었다. RAD스튜디오에서 윈도우 알림 기능을 지원하는 기능이 바로 이 접근 방식으로 구현되었다. 마이크로소프트는 UWP를 밀어붙이는 동안, 클래식 앱은 더이상 사용되지 않을 것이라는 암시를 해왔지만, 개발자들은 실제로 그 말을 듣지 않았다. 그 다음 단계로 마이크로소프트가 추진한 것은 일명 “데스크탑 브릿지(Desktop Bridge)”이다. 이것은 네이티브 애플리케이션이 WinRT API를 더 많이 활용할 수 있도록 하고, 가벼운 컨테이너 안에 “패키징”하여 추가 보안을 할 수 있는 기술이다. 패키징은 APPX로, 그 이후에는 MSIX로 구현되었다. 다시 말하지만, RAD스튜디오에서는 데스크탑 브릿지를 꽤 오래 전부터 IDE 안에서 직접 지원해왔다. 마이크로소프트는 데스크탑 브릿지에 대해 처음에는 애플리케이션을 UWP로 마이그레이션 하는 것을 도와주는 길이라고 설명했다. 당시에는 UWP가 여전히 마이크로소프트의 목표였다. 개발자는 기존의 애플리케이션 폼을 한번에 하나씩 변경할 수 있었는데, 얼마 지나지 않아 개발자는 방대한 코드 베이스를 이런 식으로 전환하는 작업에 실제로 전혀 관심이 없고, 오히려 플랫폼 기능을 사용하는 것에 관심을 가진다는 점이 명백해졌다. 이와 더불어 APPX와 MSIX는 클래식 애플리케이션이 마이크로소프트 스토어에 들어갈 수 있도록 하는 문도 열었다. 작년을 잠깐 떠올려보면, 마이크로소프트는 프로젝트 리유니언(Project Reunion, 지금은 Windows App SDK로 불린다)을 발표하면서 UWP 애플리케이션에서 모든 네이티브 API를 호출할 수 있고, 네이티브 애플리케이션 역시 모든 UWP API를 호출할 수 있도록하는 상호 운용성을 완벽하게 제공하겠다는 목표를 내세웠다. 하지만 결국 네이티브 애플리케이션 지원을 훨씬 더 우선하고 UWP는 뒤로 밀렸다. 다시, 네이티브 자, 다시 말해서, 지난 15년 즉 마이크로소프트에서 네이티브 윈도우 애플리케이션을 곧 사라질 이등 계급으로 취급하던 시대가 끝남에 따라, 이제는 그 위치가 완전히 뒤바뀌었다. 네이티브 앱 즉 클래식 API앱은 지금 이자리에 있고, 현대화, 새 API 지원, 윈도우11 지원 등의 맥락에서 우선 순위에 있다. 마이크로소프트는 네이티브 세계에 UWP 동의와 API를 제공할 계획이다. 이 현상은 점점 증가하고 있다. 예를 들어, WebView 2 컨트롤(내장된 Chromium Edge로써 델파이, C++빌더에서도 이것을 래핑하여 지원하고 있다)은 COM 컴포넌트이다. 다른 새 API들 역시 COM을 사용한다. 물론 일부는 네이티브에 또 다른 일부는 WinRT에 기반을 두고 있지만 모두 네이티브 애플리케이션에서 액세스 할 수 있다. 네이티브 API 모델이 여전히 지금 이자리에 있다는 사실은 델파이와 C++빌더에게 정말 멋진 소식이다. 이 모델은 엠바카데로가 항상 가장 우선 순위에 놓고 지켜오고 있었기 때문이다(글쎄, 델파이 닷넷 시절이 잠시 있긴 했지만), 뿐만 아니라 오랫동안 우리는 경쟁자들의 라이브러리보다 훨씬 많이 이 모델을 확장시켜왔다. 클래식 API를 사용하는 대체 UI 프레임워크, 예를 들어 MFC 라이브러리나 마이크로소프트 WinForms 라이브러리 등을 보면, VCL 라이브러리가 해왔던 것들에 비해, 이 모델에 대해 마이크로소프트의 관심과 향상이 훨씬 부족했다는 생각을 하게된다. 새 UI 컨트롤 추가부터 WinRT와 Reunion 컨트롤 내장까지, High DPI 지원부터 UI 스타일에 이르기까지, VCL 라이브러리는 지속적으로 확장되었고 경쟁 네이티브 라이브러리보다 훨씬 더 빠르게 향상되어왔다. 이런 이유로 RAD스튜디오는 오늘날 최고의 네이티브 윈도우 클라이언트 애플리케이션 개발 솔루션의 자리에 있다. 그뿐 아니라, RAD 스튜디오는 10년, 20년된 코드베이스를 놀랄만큼 쉽게 마이그레이션 한다. 다른 제품들과는 비교도 안된다. 델파이, C++빌더 개발자가 되고, 최고 대우를 받는 윈도우 애플리케이션을 개발하는 것은 멋진 일이다. 이제는, 마이크로소프트가 혹시라도 차기 윈도우 버전에서 네이티브 애플리케이션 모델을 버릴지도 모른다는 염려 조차 할 필요가 없다.
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.