नेटिव ऐप के भीतर के वेब पेज

बहुत-से Windows ऐप्लिकेशन बाहर से नेटिव और भीतर से वेब पेज होते हैं। एक सेटिंग स्क्रीन, एक डैशबोर्ड, एक रिपोर्ट व्यू, एक लाइसेंस पैनल - एक बार HTML में बनाए गए और दो बार लिखे जाने की जगह WebView2 या Qt WebEngine में होस्ट किए गए।

इंजन उन पेजों को अपनी प्रोसेस में चलाता है, और वह प्रोसेस सैंडबॉक्स्ड होती है। ऐप्लिकेशन में इंजेक्ट की गई लाइब्रेरी उसमें नहीं पहुँचती। ऐप्लिकेशन जो कुछ Windows से पूछता है वह सत्र की तारीख़ पर चला जाता है, और पेज जो कुछ JavaScript से पूछता है वह नहीं जाता:

• टाइटल बार, लॉग और फ़ाइलें 2038 कहती हैं।
• उसी विंडो के भीतर का पैनल आज कहता है।
• कोई त्रुटि नहीं, कोई चेतावनी नहीं, और दोनों हिस्से बराबर आत्मविश्वास से भरे दिखते हैं।

यह इस बग का महँगा संस्करण है, क्योंकि परीक्षण चला हुआ लगता है। पुराना व्यवहार ऐसे सत्र को साफ़ पास बताता था, जो ऐसा दावा था जिसे टूल साबित नहीं कर सकता था।

सत्र दोनों तंत्र एक साथ चलाता है। नेटिव हुक हमेशा की तरह ऐप्लिकेशन में जाता है, और पेजों तक वैसे ही पहुँचा जाता है जैसे किसी भी सैंडबॉक्स्ड रेंडरर तक पहुँचा जाता है: इंजन से ही पूछकर।

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

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

यह डिफ़ॉल्ट रूप से चालू है और एक स्विच से बंद हो जाता है, जो कोई पोर्ट नहीं खोलता और पेजों को असली घड़ी पर छोड़ देता है।

# कुछ कॉन्फ़िगर करना नहीं - इंजन अगर है तो मिल जाता है
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60

# या पेजों को अकेला छोड़ें, और कोई पोर्ट न खोलें
chrono run "C:\Program Files\YourApp\YourApp.exe" --at 2038-01-01T00:00:00 --no-embedded

पेज ऐप्लिकेशन के अपने आँकड़ों में नहीं घोले जाते। उन्हें अपनी अलग इकाइयों के रूप में गिना जाता है, क्योंकि प्रोसेस और पेज अलग चीज़ें हैं और उन्हें जोड़ने से ऐसी संख्या गढ़ जाती जिसका कोई मतलब नहीं:

• हेडलाइन दोनों गिनती है - processes: 4, contexts: 1।
• हर पेज को अपनी पंक्तियाँ मिलती हैं, जैसे कमांड लाइन पर context 1: page Date.now (12 calls) और विंडो की ऑडिट तालिका में page Date.now - fake clock।
• जिस इंजन तक पहुँचा गया उसका नाम पोर्ट के साथ दिया जाता है, ताकि आप अपना DevTools ठीक उन्हीं पेजों की ओर कर सकें जिन्हें सत्र चला रहा है।

ड्राई रन कुछ भी शुरू करने से पहले बता देता है कि पेजों तक पहुँचा जाएगा या नहीं। निर्णयों का मतलब →

दो छोटी सीमाएँ, साफ़-साफ़। पेज सत्र के टाइम ज़ोन को एक स्थिर ऑफ़सेट के रूप में पढ़ते हैं, इसलिए Intl उसे शहर नहीं, GMT+02:00 जैसे ऑफ़सेट से बताता है। और जो टाइमर सत्र के पेज तक पहुँचने से पहले निर्धारित हो चुका था, वह अपनी पुरानी दर रखता है, जैसा कि शुद्ध Chromium सत्र में होता है - सत्र चेतावनी देता है, बजाय इसके कि आप यह नतीजा निकालें कि कुछ हुआ ही नहीं।

अगर इंजन रजिस्ट्री में ब्राउज़र-आर्ग्युमेंट नीति से कॉन्फ़िगर किया गया है, तो सत्र का वेरिएबल उसकी अवधि भर प्राथमिकता लेता है, और रिपोर्ट यह कहती है - क्योंकि वहाँ आपका सेट किया डीबगिंग पोर्ट लागू नहीं होता।

प्रयोगात्मक, यहाँ अन्यत्र जैसे ही तय अर्थ के साथ: यह उन टारगेट पर चलता है जिनके विरुद्ध बना था, इसे व्यापक रूप से परखा नहीं गया है, और इस पेज की जगह बिल्ट-इन ऑडिट आपका सच का स्रोत है। इसे 64-बिट Windows पर एक WebView2 होस्ट और एक Qt WebEngine होस्ट के विरुद्ध हाथ से मापा गया, स्वचालित सूट से नहीं। उन रनों में पेजों ने सत्र का साल सत्र की दर से पढ़ा और एक छलाँग का अनुसरण किया।

32-बिट Windows पर एक पेंच है जिसे खोजने की जगह पहले से जान लेना बेहतर है: WebView2 रनटाइम 64-बिट होता है, भले ही उसे होस्ट करने वाला ऐप्लिकेशन 32-बिट हो, इसलिए 32-बिट सत्र इंजन की प्रोसेस या उनकी भूमिकाओं के नाम नहीं बता सकता। पेजों तक का चैनल फिर भी काम करता है। रिपोर्ट बस उसके बारे में कम सटीक होती है जिसे वह पहचान नहीं सकी, और बताती है कि दोनों में से कौन-सी बात है।