देशी विंडोज एप्लिकेशन में HTML इंजन एकीकरण - पसंद और वास्तुकला

हमने 1 सी में HTML के साथ काम का अनुवाद कैसे किया: इंटरनेट एक्सप्लोरर से वेबकिट तक एंटरप्राइज

एचटीएमएल को 1 सी रूपों में प्रदर्शित करने की क्षमता 1 सी: एंटरप्राइज प्लेटफॉर्म 2003 में, संस्करण 8.0 में दिखाई दी। HTML के साथ काम करने के लिए, मंच ने ब्राउज़र इंजन इंटरनेट एक्सप्लोरर (1C: एंटरप्राइज़ उस समय केवल विंडोज के तहत काम किया) का उपयोग किया। ब्राउज़र इंजन का उपयोग उपयोगितावादी उद्देश्यों के लिए मंच द्वारा किया गया था। उदाहरण के लिए, स्क्रैच से पाठ को संपादित करने के लिए एक पूर्ण तत्व को लिखने के लिए एक ला वर्ड - विभिन्न रंग और फ़ॉन्ट समाधान की संभावना के साथ, चित्र सम्मिलित करें, आदि। - बहुत मुश्किल काम है। और अगर आप इन उद्देश्यों के लिए HTML का उपयोग करते हैं और इंटरनेट ब्राउज़र इंजन का उपयोग प्रदर्शन उपकरण के रूप में करते हैं, तो कार्य बहुत सरल हो जाता है। इसके अलावा, इंजन की सहायता से, कई अन्य तंत्र (उदाहरण के लिए, मदद की जानकारी प्रदर्शित करना) और तत्वों (उदाहरण के लिए, शेड्यूलर ) को लागू किया गया था।

खैर, एप्लिकेशन डेवलपर्स के लिए लेखांकन प्रणालियों की दुनिया के मानकों द्वारा HTML कस्टम डिज़ाइन का उपयोग करके प्रदर्शित करने की क्षमता कभी-कभी व्यावसायिक अनुप्रयोगों के इंटरफ़ेस में विभिन्न प्रकार के सुखद हाइलाइट लाने के लिए संभव बनाती है।

जैसे-जैसे समय बीतता गया, प्लेटफ़ॉर्म ने पहले लिनक्स और फिर मैकओएस का समर्थन करना शुरू किया। स्पष्ट कारणों से इन ओएस में HTML के साथ काम करने के लिए इंटरनेट एक्सप्लोरर उपयुक्त नहीं था; लिनक्स पर, हमने WebKitGTK + , और macOs, एक कोको आधारित पुस्तकालय का उपयोग किया। इस प्रकार, विभिन्न ऑपरेटिंग सिस्टम के लिए कोड आधार की एकता (जिसे हम क्लाइंट कोड 95% के स्तर पर बनाए रखने की कोशिश करते हैं) का इस क्षेत्र में उल्लंघन किया गया था। खैर, इस समय तक IE इंजन कई समस्याओं का स्रोत बन गया है।


समस्याएं:

• IE इंजन बंद स्रोत कोड है - इसका मतलब है:
  
  • प्लेटफॉर्म की जरूरतों के लिए इंजन का लचीला समायोजन संभव नहीं है
  • डिबगिंग और प्रक्रियाओं की समझ अंदर
  • इंजन संस्करण को अपडेट करके बग और त्रुटियों को ठीक नहीं कर सकता
• इंजन आधुनिक वेब प्रोग्रामिंग कार्यों के कार्यान्वयन के लिए उपयुक्त नहीं है
• कमजोर मशीनों पर प्रदर्शन के मुद्दे

इसलिए, संस्करण 1 सी में एचटीएमएल के साथ काम करने का अनुवाद: आईई इंजन से विंडोज के लिए एंटरप्राइज कुछ और था। क्या चुनना है?

शुरू करने के लिए, हमने इंजन के लिए आवश्यकताओं को तैयार किया:

• आधुनिक वेब प्रोग्रामिंग प्रौद्योगिकियों के लिए समर्थन
• इंजन के लचीले अनुकूलन और इसके तर्क की समझ के लिए खुला स्रोत
• धीमी गति से कंप्यूटर पर उच्च प्रदर्शन
• यह वांछनीय है कि इंजन को काम करने के लिए थोड़ी संख्या में तीसरे पक्ष के पुस्तकालयों की आवश्यकता होती है

इंजन चयन

इससे क्या चुनना है? हमने निश्चित रूप से, WebKit के साथ शुरुआत की, जिसके साथ हमने पहले ही लिनक्स और macOS के लिए प्लेटफॉर्म के संस्करणों में काम किया।

WebKit को 2000 में प्रारंभिक स्रोत KHTML और KJS के आधार पर Apple में विकसित किया गया था। WebKit के आधार पर, Safari ब्राउज़र बनाया गया था, बाद में - Chrome (यहां तक ​​कि बाद में Chrome ने WebKit से Blink में बदल दिया, जो फिर से WebKit से WebCore कोड पर आधारित है)।

WebKit के लिए स्रोत कोड खुला स्रोत है और LGPL के तहत लाइसेंस प्राप्त है । WebKit को macOS के लिए लिखा गया है, विंडोज के लिए कई पोर्ट हैं:

WebKit AppleWin

यह वह पोर्ट है जिसे WebKit Developers डिफ़ॉल्ट रूप से विंडोज के तहत बनाने का सुझाव देते हैं। यह 2000 के दशक के मध्य में Apple कर्मचारियों द्वारा बनाया गया था। यह कोरग्राफिक्स ग्राफिक्स लाइब्रेरी का उपयोग करता है, जो मैकओएस के लिए लाइब्रेरी का सरलीकृत संस्करण है, जिसे विंडोज में पोर्ट किया गया है। जावास्क्रिप्ट को निष्पादित करने के लिए, पोर्ट उसी एपीआई के साथ जावास्क्रिप्टकोर लाइब्रेरी का उपयोग करता है जिसका उपयोग लिनक्स के लिए मंच के कार्यान्वयन में किया जाता है। यह इसे उपयोग के लिए एक प्रमुख उम्मीदवार बनाता है।

WebKit WinCairo

यह पोर्ट ग्राफिक्स के लिए काहिरा पुस्तकालय का उपयोग करता है। कुछ समय के लिए, Apple इस पोर्ट को मुख्य AppleWin पोर्ट के एनालॉग के रूप में सक्रिय रूप से विकसित कर रहा है। इस बंदरगाह का लाभ यह है कि यह MacOS- विशिष्ट पुस्तकालयों पर कम निर्भर है जिन्हें CoreGraphics की आवश्यकता होती है। इसके अलावा, पोर्ट वेबकेइटजीटीके + इंजन के रूप में ग्राफिक्स ( काहिरा ) के लिए उसी लाइब्रेरी का उपयोग करता है, जिसका उपयोग हम प्लेटफॉर्म के लिनक्स कार्यान्वयन में करते हैं, जो हमारे कोड के व्यवहार को मानकीकृत करने के लिए अच्छा है।

QtWebKit

विंडोज के लिए वेबकीट इंजन का एक और कार्यान्वयन, अब इंजन के डेवलपर्स से स्वतंत्र है। Qt अपने खुद के QtGui ग्राफिक्स लाइब्रेरी के साथ एक लोकप्रिय क्रॉस-प्लेटफॉर्म लाइब्रेरी है। यह पोर्ट जावास्क्रिप्ट को संभालने के लिए JavaScriptCore लाइब्रेरी का भी उपयोग करता है, हालाँकि इसके नुकसान हैं:

• क्यूटी के मुख्य घटकों पर मजबूत निर्भरता, जो अगर तीसरे पक्ष के सॉफ़्टवेयर में उपयोग की जाती है, तो इसके साथ वितरित करने की आवश्यकता होगी
• WebKitGTK की तुलना में HTML प्रतिपादन के लिए घटकों के साथ काम करने के लिए इंटरफेस का एक अलग सेट और उनके साथ काम करने के लिए अपने स्वयं के तर्क।

विंडोज के लिए WebKitGtk +

हमने प्लेटफ़ॉर्म के लिनक्स संस्करण में पहले से ही WebKitGtk + का उपयोग किया है। लेकिन विंडोज में इसका उपयोग करने के विकल्प को विधानसभा की जटिलता, इस प्रक्रिया के खराब दस्तावेज और WebKitGTK + के डेवलपर्स से इस विकास क्षेत्र के लिए निरंतर समर्थन की कमी के कारण से इनकार किया गया था।

क्रोमियम (ब्लिंक)

पहला और एकमात्र गैर-वेब-किट जैसा इंजन, जिसे समस्या को हल करने के लिए एक उम्मीदवार के रूप में माना जाता था। यह WebKitGTK + की तुलना में HTML के प्रतिपादन के लिए घटकों के तर्क में बड़े अंतर और जावास्क्रिप्ट ( V8 ) के साथ काम करने के लिए एक अन्य पुस्तकालय के कारण खारिज कर दिया गया था।

क्या चुनना है?

रिसर्च के बाद AppleWin और WinCairo फाइनल में पहुंचे।
अंतिम विकल्प बनाने के लिए, हमने अध्ययन किया कि WebKit कैसे काम करता है।

WebKit इंजन संरचना

आमतौर पर, अलग-अलग WebKit पोर्ट दो तरह से भिन्न होते हैं। पहला सीधे ओएस-विशिष्ट घटकों का उपयोग करके किसी विशेष ओएस के लिए कार्यान्वयन है। दूसरा एक ग्राफिक्स लाइब्रेरी है। नीचे दिया गया आंकड़ा वेबकिट पोर्ट के बीच इस अर्थ में अंतर का वर्णन करता है। विंडोज के लिए, WebKit डेवलपर्स ने अनुकूलित CoreGraphics और Cairo लाइब्रेरी पर पोर्ट लिखे।



इंजन का एक सरलीकृत मॉडल: एक वेब पेज को प्रारूपित करने के लिए तीन पारंपरिक तंत्र - HTML, जावास्क्रिप्ट और सीएसएस - इंजन को खिलाए जाते हैं, और यह उनसे पेज बनाता और प्रदर्शित करता है:



इंजन में ही कई घटक होते हैं:

• डब्ल्यूटीएफ (वेब ​​टेम्प्लेट फ्रेमवर्क, जो आपने सोचा नहीं हो सकता है): यहां आपको इंजन की कार्यप्रणाली के लिए डेटा संरचनाओं के अपने कार्यान्वयन के साथ-साथ धाराओं के साथ काम करना है।
• JavaScriptCore: एक घटक, जैसा कि नाम से पता चलता है, जावास्क्रिप्ट भाषा के साथ काम करने के लिए
• WebCore: DOM, स्टाइल, HTML और XML पार्सिंग के साथ सभी काम यहाँ लिखे गए हैं। इंजन का सभी मुख्य "जादू" यहाँ किया जाता है।
• प्लेटफ़ॉर्म: नेटवर्क के साथ बातचीत करने, डेटाबेस में डेटा रखने, छवियों को डिकोड करने, मीडिया के साथ काम करने के लिए तकनीकी क्रियाएं करता है
• WebKit और WebKit2 API - सभी घटकों को लिंक करना और उन तक पहुंच प्रदान करना

WebKit घटकों और OS- विशिष्ट सुविधाओं के बीच का संबंध नीचे दिए गए चित्र में दिखाया गया है। जैसा कि आप देख सकते हैं, काफी कुछ विशिष्ट बिंदु हैं जिन्हें प्रत्येक ओएस के लिए अलग से लागू करने की आवश्यकता है। यद्यपि JavaScriptCore आपको अलग-अलग कार्यान्वयन के बिना प्रत्येक पोर्ट में खुद का उपयोग करने की अनुमति देता है।

वेब पेज कैसे बनता है

नेटवर्क से, सर्वर से डेटा डाउनलोड करने के लिए रिक्वेस्ट के लिए रिस्पांस आता है। लोडर पार्सर को डेटा पास करता है, जो जावास्क्रिप्ट के लिए घटक के साथ बातचीत करते हुए, DOM और स्टाइल शीट बनाता है। अगला, उत्पन्न डेटा रेंडरिंग ट्री में स्थानांतरित किया जाता है और एक ग्राफिकल संदर्भ में प्रदर्शित होता है।

पृष्ठ में भी व्यक्तिगत घटक होते हैं। वेबकोर घटक पृष्ठ कक्षा को लागू करता है, जो पूरे पृष्ठ तक पहुंच की अनुमति देता है। पेज का एक मुख्य फ्रेम है - मेनफ्रेम, एक फ्रेम में हमेशा एक दस्तावेज होता है। मुख्य फ़्रेम में किसी भी संख्या में अन्य फ़्रेम हो सकते हैं, साथ ही अंदर दस्तावेज़ भी। प्रत्येक फ्रेम के लिए, कुछ ईवेंट अलग-अलग बनते हैं, साथ ही विशिष्ट ग्राफिक और जावास्क्रिप्ट संदर्भ भी।



सरलीकृत HTML पार्सर इस तरह से काम करता है। सर्वर से प्राप्त बाइट्स के सेट से, डिकोडर पार्सिंग के लिए वर्णों का एक सेट उत्पन्न करता है। प्रतीकों को टोकन या टोकन में बदल दिया जाता है, जो आमतौर पर मेटा-जानकारी के साथ कोड के प्राथमिक टुकड़े होते हैं कि यह किस प्रकार का पाठ है, चाहे वह भाषा वाक्य रचना या सामग्री का हिस्सा हो। फिर डोम ट्री बनाने के लिए टोकन से नोड्स बनाए जाते हैं। नोड्स के सेट से एक ट्री बिल्डर एक वेब पेज दस्तावेज़ के लिए एक पूर्ण ऑब्जेक्ट मॉडल बनाता है।

अंतिम विकल्प

• AppleWin
  • पेशेवरों:
    • MacOS पर चलने वाले ग्राफ़िक्स लाइब्रेरी पर कार्यान्वित - WebKit डेवलपर्स के लिए मुख्य लक्ष्य मंच
  • विपक्ष:
    • मुद्रण तंत्र के कार्यान्वयन में कमी
    • बड़ी संख्या में निर्भरताएं
• WinCairo
  • पेशेवरों:
    • उसी ग्राफिक्स लाइब्रेरी (काहिरा), जैसा कि 1 सी प्लेटफॉर्म के लिनक्स पोर्ट में इस्तेमाल किया जाता है
  • विपक्ष:
    • हमारे कार्यों के लिए आवश्यक नहीं मिला

विनकाइरो को हराया। विकास के लिए, उस समय उपलब्ध WebKit का नवीनतम संस्करण - 605.1.11 लिया गया।

कार्यान्वयन

हालांकि इंजन यूनिट परीक्षणों (इंजन के सभी घटकों के लिए लगभग 30,000, इंजन के लेखकों द्वारा लिखे गए) द्वारा बहुत अच्छी तरह से कवर किया गया है, "गैर-कोर" ओएस के लिए कार्यान्वयन में त्रुटियां और कमियां हैं (जो कि सब कुछ जो मैकओएस नहीं है)। इन कार्यान्वयन अंतराल को धीरे-धीरे खोजा गया क्योंकि इंजन को 1 सी: एंटरप्राइज प्लेटफॉर्म के भाग के रूप में विकसित और परीक्षण किया गया था।

HTML को ड्रैग एंड ड्रॉप के माध्यम से डाउनलोड करें

पाठ को खिड़की में खींचते समय, यह पाया गया कि यदि पाठ को खींचा जा रहा है, जिसमें गैर-एएससीआईआई अक्षर हैं, तो चित्रलिपि को अंतिम दस्तावेज़ में डाला जाता है। त्रुटि केवल इंजन के विंडोज कार्यान्वयन में दिखाई दी, क्योंकि इसमें तत्वों को खींचने और छोड़ने के लिए एक ओएस-विशिष्ट तंत्र के साथ काम किया गया था। यह पता चला है कि पाठ को UNICODE से UTF-16 तक डालने से पहले नहीं डाला गया था, जो ईवेंट हैंडलर को पास किया गया था।

Shift + Enter कीबोर्ड व्यवहार बदलें

अधिकांश पाठ संपादकों (Microsoft Word सहित) में, यह संयोजन एक पंक्ति विराम सम्मिलित करता है। WebKit का मानक व्यवहार एक नया पैराग्राफ सम्मिलित करना है (जैसे कि केवल Enter दबाकर)। हमने इंजन को बदल दिया, जिससे उपयोगकर्ताओं के साथ व्यवहार अधिक परिचित हो गया।

पूर्ववत और फिर से तंत्र का संगठन।

WebKit उपयोगकर्ता कार्यों को रद्द करने और दोहराने के लिए अपने स्वयं के तंत्र को लागू करने के लिए एक एपीआई प्रदान करता है। इसकी योजना इस प्रकार है: जब उपयोगकर्ता इंजन के दृष्टिकोण से एक निश्चित कार्रवाई असतत करता है (उदाहरण के लिए, एक नया पैराग्राफ पर स्विच करना, इटैलिक में स्वरूपण, चिपकाना), तो WebKit डेवलपर को एपीआई का उपयोग करके इस बारे में सूचित करता है ताकि वह इस क्रिया को पंजीकृत कर सके।

कार्यान्वित तंत्र के परीक्षण की प्रक्रिया में, एक अप्रिय बात पता चली: इंजन तालिकाओं की संरचना में परिवर्तन की रिपोर्ट नहीं करता है। कोशिकाओं को जोड़ने और हटाने के लिए कमांड और कोलस्पैन विशेषता को जोड़ा गया, जो समग्र क्रियाओं का हिस्सा बन गया, जैसे कि, उदाहरण के लिए, एक तालिका में एक स्तंभ या एक पंक्ति को जोड़ना / निकालना। इस तरह के मिश्रित कमांड एक ही पूर्ववत और फिर से स्टैक में पंजीकृत हैं, और इंजन से कमांड के साथ मिलकर तंत्र का सही संचालन सुनिश्चित करते हैं।

एक्सेल से पेस्ट करें

जिन लोगों ने विंडोज और एक्सेल क्लिपबोर्ड के साथ काम किया है, उन्हें पता हो सकता है कि सबसे पहले, एक्सेल से एचटीएमएल में कॉपी करते समय, कॉपी किए गए टुकड़े में क्लिपबोर्ड प्रारूप में केवल सेल और पंक्तियों के टैग शामिल होते हैं, लेकिन तालिका का टैग ही नहीं, और दूसरी बात, एक एक्सेल दस्तावेज़ से शैलियों को कोशिकाओं में स्थानांतरित नहीं किया जाता है। इस वजह से, उदाहरण के लिए, क्रोम में एक संपादन योग्य तत्व में एक रंग तालिका इस तरह दिखती है:

मूल:



क्रोम में:



इन दोनों कारकों को वेबकीट के डेवलपर्स ने ध्यान में नहीं रखा। इंजन कोड के खुलेपन ने हमें सम्मिलन तंत्र को परिष्कृत करने की अनुमति दी, और अब दस्तावेज़ के HTML फ़ील्ड में डाली गई तालिका का टुकड़ा मूल के करीब है:

इटैलिक फ़ॉन्ट पीढ़ी

यदि विंडोज में एक गैर-मानक फ़ॉन्ट का इटैलिक संस्करण नहीं है, तो अधिकांश पाठ संपादक अपने नियमित संस्करण का उपयोग करके ऐसा फ़ॉन्ट उत्पन्न कर सकते हैं। हालाँकि, WebKit ऐसा करने में सक्षम नहीं था और डेवलपर्स को कई बार गुमराह करता है: यह कैसे होता है कि दस्तावेज़ के HTML कोड में हमने टेक्स्ट को <i> टैग में डाल दिया, लेकिन इसके बावजूद यह पाठ सीधा बना रहा। कारण यह है कि WebKit इंजन WinCairo पोर्ट में वांछित फ़ॉन्ट का चयन करता है - यदि कोई इटैलिक संस्करण नहीं है, तो इंजन नियमित संस्करण का उपयोग करता है। इस व्यवहार को कैरो ग्राफिक्स लाइब्रेरी द्वारा उत्पन्न इटैलिक फ़ॉन्ट के उपयोग से बदल दिया गया है।

छवियों और एनिमेशन को डिकोड करने में त्रुटियां

ग्राफिक तत्वों के साथ काम करते समय इंजन के व्यवहार में त्रुटियां पाई गईं। पीएनजी प्रारूप में कुछ छवियों को लोड करते समय, छवि विरूपण देखा गया था, और कभी-कभी इसकी अनुपस्थिति बिल्कुल। इस व्यवहार के कारण का पता लगाना संभव नहीं था, क्योंकि एक त्रुटि तब होती है जब libpng पुस्तकालय के आंत्र में छवियों को डिकोड कर रहा है।

व्यावहारिक रूप से, यह पाया गया कि जब एक स्थिर एक के बजाय गतिशील तरीके से libpng लाइब्रेरी को लिंक किया जाता है, तो समस्या ठीक हो जाती है। वैसे, इंजन के वर्तमान संस्करण में, इस तरह से लिंकिंग किया जाता है। ऐसा ही करने का निर्णय लिया गया।

GIF प्रारूप में एनिमेशन लोड करते समय एक और समस्या इंजन की थी। इस तरह के एनिमेशन वाले पेज को लोड करते समय त्रुटि समय-समय पर पुन: उत्पन्न की गई और कार्यक्रम के दुर्घटनाग्रस्त होने का कारण बना। त्रुटि बफर के साथ काम करते समय सिंक्रनाइज़ेशन की कमी के कारण हुई थी जिसमें एनीमेशन का अगला फ्रेम रखा गया है। आंतरिक WebKit सिंक्रनाइज़ेशन टूल का उपयोग करके समस्या का समाधान किया गया था।

वर्तनी समर्थन

इंटरनेट एक्सप्लोरर के साथ विधानसभा में, विंडोज संस्करण 8 और बाद में, HTML संपादन योग्य क्षेत्र के लिए वर्तनी जांच सक्षम की जा सकती है। ऐसा करने के लिए, "स्पेलचेक" को "सच" के बराबर विशेषता देना पर्याप्त था। वेबकिट के विभिन्न बंदरगाहों के लिए अलग-अलग समाधान थे: लिनक्स पर यह एनचांट लाइब्रेरी है, मैकओएस पर इसका अपना तंत्र है, जो Apple उत्पादों के सभी उपयोगकर्ताओं से परिचित है। लेकिन विंडोज के लिए कोई कार्यान्वयन नहीं है, लेकिन अपने स्वयं के समाधान के लिए एक एपीआई प्रदान किया जाता है। हमने विंडोज स्पेल चेकिंग एपीआई का उपयोग किया, जो कि विंडोज 8 के साथ शुरू होता है, और इंटरनेट एक्सप्लोरर के साथ निर्माण के समान एक तंत्र लागू किया है। वैसे, अब मूल 1C में एक स्वरूपित दस्तावेज़ में: एंटरप्राइज़ क्लाइंट यह कार्यक्षमता भी काम करता है। संस्करण 8.3.14 से पहले, यह इंटरनेट एक्सप्लोरर के खराब प्रदर्शन के कारण अक्षम हो गया था।

Windows XP समर्थन

हमारे कुछ ग्राहक अभी भी विंडोज़ एक्सपी पर काम करते हैं, और निकट भविष्य में ओएस को अपग्रेड नहीं करने जा रहे हैं। डेवलपर्स के रूप में हमारे लिए दुख की बात है, लेकिन सच है। इसलिए - हमें उनका समर्थन करने की आवश्यकता है। और यहां हमें एक अप्रिय आश्चर्य हुआ: लगभग एक साल तक WebKit Developers ने WinXP में इंजन का समर्थन नहीं किया। WinXP के लिए बिल्ड टूल्स के सेट के साथ इंजन का एक संस्करण बनाने का एक प्रयास असफल रहा - वेबिट डेवलपर्स उन पुस्तकालयों का उपयोग करते हैं जो केवल विंडोज विस्टा और बाद में उपलब्ध हैं।

क्या करें? विकल्प इस प्रकार थे:

1. इंटरनेट एक्सप्लोरर इंजन के साथ WinXP कार्यान्वयन को छोड़ दें, और Windows के पुराने संस्करणों में WebKit का उपयोग करें
2. विकास के लिए WebKit इंजन के पुराने संस्करण को लें, जो WinXP में काम करता है, और सभी OS में इस संस्करण का उपयोग करें
3. WinXP में WebKit के उपयुक्त संस्करण का उपयोग करें, और Windows के पुराने संस्करणों में नवीनतम इंजन का उपयोग करें
4. इंजन के वर्तमान संस्करण को खुद WinXP पर पोर्ट करें और हर जगह इसका उपयोग करें

सवाल आसान नहीं था। पहले विकल्प ने आपको WebKit इंजन के नवीनतम संस्करण का उपयोग करने की अनुमति दी थी, लेकिन आपको इंटरनेट एक्सप्लोरर के साथ पुराने कार्यान्वयन को वापस करने के लिए मजबूर करेगा। इस तरह के एक समाधान में, कार्यक्रम के त्रुटि-मुक्त संचालन को सुनिश्चित करना मुश्किल होगा, और कोड स्वयं बहुत जटिल होगा। दूसरा विकल्प सभी विंडोज ओएस पर समान व्यवहार प्रदान करता है, हालांकि, यह हमें विकास के लिए अवसर नहीं देगा - त्रुटियों को ठीक करने और बाद के संस्करणों में इंजन के डेवलपर्स से नई सुविधाओं को प्राप्त करने के लिए इंजन को अपडेट करना। तीसरे विकल्प ने आपको विंडोज के पुराने संस्करणों में इंजन के वर्तमान संस्करण का उपयोग करने की अनुमति दी, लेकिन स्थापना तर्क को बहुत जटिल कर दिया और सभी ओएस में समान संस्करण व्यवहार सुनिश्चित किया। चौथा विकल्प अन्य सभी के लिए बेहतर लग रहा था, लेकिन जटिलता और सामान्य रूप से इस तरह के समाधान की संभावना का अनुमान लगाना असंभव था।

फिर भी, हमने एक मौका लेने और चौथे विकल्प को लागू करने का फैसला किया, जो कि वास्तुकला के दृष्टिकोण से सबसे सही है (विंडोज के सभी संस्करणों पर एकल इंजन स्रोत कोड का उपयोग करके)। WebKit का पोर्ट किया गया संस्करण WinXP और Windows के नए संस्करणों में अलग तरह से काम करता है:

• मुझे नए DirectX (d3d11) के उपकरणों को पुराने DirectX9 (d3d9) के पक्ष में छोड़ना पड़ा और इसकी हेडर फ़ाइलों को SDK के छोटे संस्करण में बदलना पड़ा।
• नए एसडीके से कार्य, जब विंडोज के नए संस्करणों पर निष्पादित किया जाता है, तो पते पर कॉल किया जाता है ( गेटप्रोकैड्रेस के माध्यम से प्राप्त)।
• इंजन में धाराओं के बीच डेटा स्थानांतरित करने के लिए, WinXP नए संस्करणों में - थ्रेड स्थानीय भंडारण, थ्रेड स्थानीय भंडारण का उपयोग करता है।

परिणाम

तो, अब हमारे 1C में: एंटरप्राइज़ प्लेटफ़ॉर्म 8.3.14 (रिलीज़ - 2018 के अंत) से शुरू होकर HTML को उच्चतम स्तर - HTML5, OpenGL, आदि में सपोर्ट किया जाएगा। किशमिश की मात्रा और गुणवत्ता दोनों को हमारे मंच पर निर्णय में लाया जा सकता है जो केवल डेवलपर की कल्पना द्वारा सीमित हैं। और फिर भी, ज़ाहिर है, क्लाइंट के ऑपरेटिंग सिस्टम - WinXP पर, स्पष्ट कारणों से कई स्वादिष्ट एचटीएमएल 5 बन्स काम नहीं करेंगे।

अब 1C पर विंडोज एप्लिकेशन पर: एंटरप्राइज प्लेटफॉर्म यह दिखाने में सक्षम होगा:



लेकिन, एप्लिकेशन समाधान में HTML के "उपहार" का उपयोग करते हुए, सामान्य ज्ञान को मत भूलना। HTML का उपयोग करना विशेष कार्यों के लिए उचित और अनुशंसित है (मदद, तकनीक, उत्पाद विवरण, ... प्रदर्शित करना), लेकिन व्यवसाय तर्क कार्यों (संरचित जानकारी के इनपुट / आउटपुट) को लागू करने के लिए नहीं। ऐसा करने के लिए, आपको मानक 1 सी का उपयोग करने की आवश्यकता है: एंटरप्राइज़ इंटरफ़ेस तंत्र जो एक्सेस अधिकार, कार्यक्षमता प्रबंधन, डिवाइस फॉर्म फैक्टर के लिए अनुकूलन, उपयोगकर्ता सेटिंग्स के लिए समर्थन और कई अन्य तंत्रों के काम के लिए स्वचालित समर्थन प्रदान करता है, जिसके बिना किसी व्यावसायिक अनुप्रयोग का पूर्ण संचालन लगभग असंभव हो जाता है।