공통 델파이 개발자 관점에서 본 윈도우 개발
2020.03.13 16:37
Jon Lennart Aasenden 블로그 글을 번역한 것입니다.
델파이 개발자 관점에서 본 윈도우 개발
업계에서 30 년이 넘는 소프트웨어 개발자로서 Microsoft Windows 환경에서 25년 동안 개발하면서 가장 중요한 것은 개발 도구를 선택하는 것이었습니다.우리 개발자에게는 올바른 도구가 경력을 쌓거나 깨뜨릴 수 있습니다. 올바른 도구의 선택이 중요한 주제입니다.
"25 년 동안 수많은 개발자들이 틀릴 수는 없습니다.
델파이가 개발 플랫폼으로 긍정적으로 나아가지 않았다면
우리 중 누구도 오늘 여기에 없을 것입니다"
수십 년에 걸쳐 사용해온 언어와 프레임 워크 전부를 검토하는 것은 이 글의 범위에서 벗어납니다.다양한 영역에서 임베디드 기본 Basic 컴파일러부터 C, Java, Pearl 및 C# 등 적어도 10 가지의 다른 개발 도구를 사용해 본 적이 있습니다. 머리속에 TMT, HiSoft, Turbo Pascal, Freepascal, Oxygene Pascal, Delphi등 6 가지 Pascal 컴파일러(내가 가장 좋아하는 언어)의 이름을 떠올릴 수 있습니다.
2010 년에는 델파이 커뮤니티 멤버들과 함께 자체 개발 플랫폼을 만들었습니다.따라서 프로그래밍 언어와 컴파일러 이 주제에 대해
오랫동안 연구해 왔습니다.
다른 대안들을 고려 할 수 있으나, 신뢰할 수 있는 소프트웨어를 적당한 때, 그리고 예산에 맞춰 배포한다는 관점에서 보면,델파이를 능가하는 것은 없습니다.
위 : WinAPI와의 긴밀한 통합의 장점 중 하나는 초고속 경량 비주얼 컨트롤입니다.
스핀이나 마케팅으로 치부할 수도 있지만, 여러분들이 제 블로그를 팔로우하셧거나 페이스북 사용자 그룹 중 한 곳을 자주 방문했다면, 델파이에 대한 저의 노력은 의심의 여지가 없기를 바랍니다. 저는 여러 해 동안 많은 프로그래밍 언어와 기술들과 함께 사용해 왔지만, 델파이는 항상 개발자로서의 내 삶에서 변함없는 존재로 남아 있습니다.
이 글에서는 델파이가 윈도우즈 개발에 왜 멋진 지 간략하게 설명하고자합니다. 델파이 개발자의 관점에서 Windows개발이란 무엇인가? 어떤것과 관련이 있으며 기준이 무엇인지에 대해 다루겠습니다.
개발 기술(방법) 찾기
저는 오늘날 네이티브 소프트웨어 개발에 뛰어 드는 젊은이들이 반드시 부럽다고는 생각할 수 없습니다. 70 년대와 80 년대의 어린 시절 저는 곡선보다 1 인치 앞선 삶의 사치를 누렸습니다. 어떤 기준이나 기법이 표준이 되었든, 그 중심에 있었습니다. 언제나 작업이 끝나면 다음 논리적인 단계의 일을 진행했기때문에 과거의 기술을 따라잡거나 몰입할 필요가 없었습니다.
"[Delphi]는 선형적이고 연속적인 상속을 통해 이를 수행합니다.
우아하고 이해하기 쉽습니다 "
2020년에 고성능 네이티브 애플리케이션을 작성하고자 하는 젊은 개발자들은 어마 어마한 수준의 표준과 프레임 워크에 직면해 있습니다. WinAPI, UWP 및 WinRT의 차이점을 이해하는 것이 쉽지 않다고 생각할 수 있습니다. 그리고 과거에 이름이 여러 번 변경된 기술(몇 가지 예를 들자면) ActiveX, COM, COM +, DirectX, GDI, GDI+ 등을 사용합니다.
이번에는 이 주제를 다룰 생각은 없지만 다음 기회에 고려해 보도록 하겠습니다. 오늘날 ActiveX로 알고 있는것을 처음에는 COM(처음에는 표시되는 개체와 보이지 않는 개체 사이에 명확한 구분이 없었습니다)이라고 했습니다. 전에는 정확히 동일한 시스템이 Microsoft OLE로 판매되었습니다 (비고:COM은 컴포넌트 오브젝트 모델 및 구현 표준이므로 기술적으로 ActiveX는 COM입니다).
제가 말하는 요점을 이해하셨으니라 봅니다. 만약 당신이 OLE를 많이 사용하셨다면 COM으로의 전환과 시각적 개체에 대한 ActiveX의 구별은 당연합니다.
고맙게도, 우리는 이 모든 것을 매우 단순화하는 개발 시스템을 가지고 있습니다.그리고 이것이 델파이 옵션중 눈에띄는 특별한 부분입니다.
네이티브 프로그래밍을 선택해야하는 이유
위에서 언급 한 이런 혼란은 모두가 겪어야 할 일입니다. 프로그래밍의 멋진 측면 중 하나는 계속해서 학습해야 한다는 것입니다. 아무도 "더 이상 배울 것이 없다"라고 말할 수 없습니다. 항상 새로운 기술, 새로운 아이디어, 문제를 해결하는 새로운 방법, 그리고 아마도 그런 것들이 제공되는 새로운 언어가 나올 것입니다.
그러나 기본 소프트웨어 개발은 최초의 가정용 컴퓨터가 나온 이후로 실제로 변하지 않은 토대(기초)를 기반으로 합니다. 그리고 이것은 제가 가르치려고 하는 가장 중요한 것 중 하나입니다. 왜냐하면 그 이유를 이해하게 되면, 더 나은 선택을 할 수 있기 때문입니다.탄탄한 기초와 일시적인 인기(언어와 기술에 관한 한)의 차이점을 발견 할 것입니다.
위 : Delphi 및 C ++ Builder는 여러 플랫폼에서 기본 소프트웨어 개발에 이상적이지만 윈도우에서 델파이를 능가하는 것은 없습니다.
컴퓨터는 100% 물리학에 좌우됩니다.컴퓨터는 전기적으로 구동되고 논리적으로 결합된 기계입니다. 그리고 물리 법칙은 프로세서와 메모리가 작동하는 방식에 영향을 미치며,결과적으로 명령 (기계 코드)의 표현 방식에 영향을줍니다.
언어는 생겼다 없어졌다하지만 기본 컴퓨팅 법칙 (네이티브 프로그래밍 언어)을 따르는 언어는 결코 사라지지 않을 것입니다. 그 언어들이 다른 모든 것을 책임지기 때문에 존재합니다.
즉, Object Pascal 또는 C/C ++를 배우면 이러한 언어로 축적 한 지식과 기술이 보편적이고,시대를 초월하며,소프트웨어 개발의 다른 모든 측면으로 직접 변환되기 때문에 이점이 있습니다.
윈도우 : 기술 계층
그렇다면 윈도우 개발자의 기준은 정확히 무엇입니까? 윈도우는 수천 개는 아니더라도 수백 가지 기술을 포괄하는 대형 시스템입니다. 훌륭한 윈도우즈 소프트웨어를 작성하기 위해 숙지해야 할 대상과 실체는 무엇입니까?
간단히 말해서 다음과 같습니다.
- 데스크탑 애플리케이션
- 시스템 서비스
- 시스템 라이브러리
- COM 및 Active X 모듈
Microsoft Windows에는 각기 다른 기능을 제공하는 여러 계층이 있으므로 한 단계 씩 살펴보도록 하겠습니다.
커널 레벨 드라이버
윈도우즈 생태계의 맨 아래에는 커널 레벨 드라이버와 같은 미션 크리티컬 기술이 있습니다. 개인적으로 C ++ Builder가 해당 유형의 코딩을 처리하는 데 더 적합하다고 생각합니다.Object Pascal을 사용할 수 없기 때문이 아니라 대부분의 드라이버가 C/C ++로 작성 되었기 때문에 사용 가능한 소스 자료들은 대부분 C 소스 코드 형식입니다.
델파이는 주로 시스템 소프트웨어용으로 설계되었으며,커널 레벨 드라이버는 아무리 생각해도 그 범주에 속하지 않습니다.여기서는 윈도우즈 아키텍처의 기본 수준을 다루기 때문에 문맥 상 단순하게 언급만 하겠습니다.
따라서 커널과 직접 통합되는 사용자 지정 파일 시스템과 같이 이러한 드라이버를 요구하는 프로젝트가 있었지만 이러한 작업은 아주 드문 예외적 경우입니다.저의 경우 C ++ Builder로 드라이버를 작성하고 델파이에서 사용했습니다.
공유 라이브러리
다음 계층은 델파이가 작동하는 곳, 즉 라이브러리 (dll 파일)입니다. 전형적인 네이티브 개발 시스템인 델파이는 빠르고 안정적인 코드를 생성합니다. 공유 라이브러리 (dll 파일)를 빌드하는 데 최적입니다. 델파이는 또한 자체 개체 모델 (VCL의 일부인 델파이 런타임 라이브러리)을 가지고 있습니다. 즉, 수천 개의 비 시각적 컴포넌트를 최대한 활용할 수 있습니다. 따라서 라이브러리는 궁극적으로 저수준 엔터티이지만 라이브러리의 컴포넌트를 사용하여 응용프로그램에 복잡하고 정교한 기능을 제공하는 방법은 없습니다.
라이브러리는 일반적으로 응용 프로그램에서 사용할 수있는 일반적인 동작 또는 고유 한 동작을 분리하는 데 사용됩니다. 라이브러리에서 작업을 분리하면 시간을 절약 할 수 있으며 규칙에 맞게 사용하면 유지 관리가 더 쉬운 소프트웨어를 작성할 수 있습니다.
서비스 스택
라이브러리 바로 위에는 서비스 계층이 있습니다(서비스는 수직 방식으로 서로 의존하기 때문에 "스택"이라고도 함). 윈도우 서비스 어플리케이션은 시각적 출력이 없는 특수 프로그램입니다. 관련된 폼, 버튼 또는 사용자 인터페이스 요소가 없습니다. 이러한 유형의 프로그램은 백그라운드에서 자동으로 실행되며 일반적으로 데스크톱 응용 프로그램 또는 기타 서비스에 특별한 기능을 제공합니다.
델파이는 의심 할 여지없이 서비스 작성을위한 최고의 솔루션 중 하나입니다. 델파이의 런타임 라이브러리는 윈도우와 매우 밀접하게 통합되어 있지만 유연하고 성숙한 컴포넌트 모델을 제공하므로 작성할 수있는 서비스 유형에는 제한이 없습니다.
데스크탑 환경
이러한 모든 기술 계층 위에는 실제 사용자 경험, 즉 데스크톱 환경이 있습니다. 그리고 이것이 델파이가 진정으로 타의 추종을 불허하는 곳입니다.델파이는 빠르고 현대적이며 멋진 데스크탑 응용 프로그램을 쉽게 만들 수 있습니다. 물론 다른 시스템들도 있지만 델파이의 RAD (rapid application development) 공식, 즉 WinAPI (중앙 윈도우 API)와 직접 인터페이스하는 방식은 생산 후 수십 년이 지나도록 세련되고 정교 해져서 필적할 만한 다른 것을 아직 찾지 못했습니다.
그 이유를 이해하기 위해 델파이를 VCL이라는 가명으로 만드는데 도움을 준 프레임워크을 살펴보겠습니다.
VCL
제가 델파이에 대해 좋아하는 것 중 하나는 VCL(시각적 컴포넌트 라이브러리)이라고하는 자체의 개별 컴포넌트 모델로 작동한다는 것입니다. VCL은 훌륭하게 설계되고 사용하기 쉬운 강력한 개체 지향 프레임 워크로 어셈블리 언어 에서부터 폼에 드래그&드롭 할 수 있는 시각적 컴포넌트까지 확장됩니다. 궁극적으로 매우 강력합니다. 다른 언어에도 일부 컴포넌트 기능이 있을 수 있지만 모든 기능을 수행하는 기본 메커니즘과 코드는 일반적으로 보호되거나 숨겨져 있습니다.
위 : VCL의 장점 중 하나는 테마 지원입니다. VCL을 사용하면 델파이의 플랫폼 독립적인 프레임워크인 FireMonkey와 마찬가지로 동작이나 통합의 손실없이 윈도우 어플리케이션에 독특한 모양을 부여 할 수 있습니다.
델파이를 배우고 옵션을 탐색하는 동안 점차 이해력이 높아짐에 따라 기술을 점차적으로 개선 할 수 있습니다.
VCL은 단일 프레임 워크에서 라이브러리에서 서비스, 서비스에서 데스크톱까지등 윈도우의 전체 범위를 포괄하기 때문에 훌륭합니다. 그리고 우아하고 이해하기 쉬운 선형적이고 연속적인 상속을 통해 이 작업을 수행합니다. 말 그대로 각 하위 개체에 점점 더 복잡한 기능들을 구축합니다.
VCL은 가장 기본적이고 필수적인 비 시각적 클래스와 컴포넌트로 시작하여 시각적인 범위(스펙트럼)로 진행됩니다. 대부분의 시각적 컴포넌트들은 TCustomControl에서 파생됩니다.
WinAPI를 수동으로 호출하는 것과 VCL을 사용하는 것의 차이점(또는 장점)은 VCL이 여러분이 처리하고자 하는 모든 것을 처리한다는 것입니다.폰트, 컬러 인코딩,스케일링 옵션, 디바이스 독립적 인 그래픽, 구성 및 레이아웃을 다루는 작업들이 시간이 많이 걸리다는 점이 핵심입니다.그러나 가장 멋진 기능은 VCL은 사용자가 강제로 지정하지 안해도 됩니다. 동작을 변경해야하는 경우 기능을 재정의하고 자신에게 맞게 작성할 수 있습니다. VCL은 델파이의 일부로 소스 형태로 제공되므로 변경해야하는 방법을 신속하게 찾을 수 있습니다. 소스 코드를 사용할 수 있으면 문서를 지속적으로 검색 할 필요가 없으므로 학습에 좋습니다. VCL은 간단하고 쉽게 기본 윈도우 프로그래밍을 깔끔하게 만듭니다.
VCL 방법론 또는 레시피는 25 년 동안 적극적으로 사용되어 왔습니다.
그리고 오랜 기간 동안 Windows와 나란히 발전하면서 세련되고 개선되고 조정되었습니다. VCL로 작성 되어 있는 제품의 수는 수백만 개에 달합니다. 가장 크고 가장 성공적인 애플리케이션 중 일부는 델파이로 만들어졌습니다. 그 사실을 광고하지 않을 수도 있지만,델파이와 C++빌더가 윈도우 플랫폼에 얼마나 중요한 역할을 했는지에 놀라실 것입니다.
Microsoft가 WinAPI에 새롭고 흥미로운 기능을 추가 할 때마다 엠바카데로는 이러한 기능을 VCL에 흡수하여 쉽게 사용할 수 있게 합니다 (클래스 또는 사용하기 쉬운 함수안에 래핑하거나 델피이와 함께 제공되는 많은 컴포넌트중 하나에 기능 채택). RAD (rapid application development)는 시간이 지남에 따라 수백만 명의 개발자가 사용하는 고유 한 방법입니다.
VCL이 오랜 기간 동안 지속 된 윈도우 생태계를 위해 특별히 작성된 것이지만-25 년 전과 마찬가지로 오늘날에도 효과적입니다-단순히 윈도우 전용 프레임 워크라고는 생각할 수 없습니다. 그 이유는 다른 언어 및 프레임 워크와 마찬가지로 변경 사항의 영향을 받지 않기 때문입니다. Windows와 직접 대화하기 때문입니다. 이 글의 시작 부분에서 언급 한 것과 같은 원리,즉 시각적 표면 아래에서 컴퓨팅은 20 년 전과 거의 동일하게 유지됩니다.
그 것은 그 자체로 놀라운 성과입니다.
다른 기술과의 통합
지금까지 저의 선택권의 제한을 둔적이 없습니다. 많은 개발자들이 단 하나의 언어, 하나의 플랫폼, 및 마지막 언어라고 맹세하지만,모든 개발자들이 잘 비축된 도구상자를 가지고 있어야 한다고 생각합니다.일부 비즈니스 부문에서는 스크립팅이 큰 역할을 하며, 다른 부문에서는 바이트 코드가 더 중요할 수 있습니다. 제가 중요하게 생각하는 것은 이웃들과 잘 어울리고, 기반 인프라와 상호 작용하며, 모두에게 분명한 혜택을 제공할 수 있는 언어를 선택하는 것입니다.
마무리
델파이는 깊이가 깊은(어러 계층을 다룰수있음)제품입니다. 다양한 기술, 테크닉, 무료 패키지 및 추가 기능을 사용했을 수도 있지만 델파이는 궁극적으로 자체 장점을 가지고 있습니다. C/C++와 마찬가지로 Object Pascal은 전형적인 언어로,컴퓨터가 작동함에 따라 (예 : C에서와 똑같이 메모리 및 포인터 및 주소로 작업) 컴퓨터와 상호 작용하도록 설계되었습니다. 전형적인 언어의 수는 적지만 다른 모든 것을 담당하는 컴퓨팅의 기본 측면을 나타냅니다. 제품으로서의 델파이는 넓은 범위와 깊이를 제공하지만 어디에서나 시작할 수 있도록합니다 레이어로부터 보호되지는 않지만 원하는 속도로 레이어에 접근 할 수 있습니다.
델파이와 윈도우 개발에 대해 전반적으로 공유하고 싶은 것이 너무나 많으며, 다룰수 있는 자료가 많기때문에 계속해서 이 주제로 되돌아 가겠습니다.
25 년 동안 수백만 명의 개발자가 틀릴 수는 없습니다. 델파이가 개발 플랫폼으로 긍정적으로 나아가지 않았다면 오늘날 아무도 여기에 없을 것입니다.
