WebUSB के लिए डिवाइस बनाना

WebUSB API का पूरा फ़ायदा पाने के लिए, कोई डिवाइस बनाएं.

इस लेख में WebUSB API का पूरा फ़ायदा पाने के लिए, डिवाइस बनाने का तरीका बताया गया है. एपीआई के बारे में कम शब्दों में जानकारी पाने के लिए, वेब पर यूएसबी डिवाइस ऐक्सेस करना देखें.

बैकग्राउंड

यूनिवर्सल सीरियल बस (यूएसबी), सहायक डिवाइसों को डेस्कटॉप और मोबाइल कंप्यूटिंग डिवाइसों से जोड़ने के लिए सबसे आम इंटरफ़ेस बन गया है. किसी डिवाइस से कम्यूनिकेट करने के लिए बस की इलेक्ट्रिकल खासियत और सामान्य मॉडल तय करने के अलावा, यूएसबी की खास बातों में डिवाइस की क्लास से जुड़ी खास जानकारी भी शामिल होती है. खास तरह के डिवाइसों के लिए ये सामान्य मॉडल हैं. जैसे, स्टोरेज, ऑडियो, वीडियो, नेटवर्किंग वगैरह. इन्हें डिवाइस बनाने वाली कंपनियां लागू कर सकती हैं. इन डिवाइस क्लास स्पेसिफ़िकेशन का फ़ायदा यह है कि एक ऑपरेटिंग सिस्टम वेंडर ("क्लास ड्राइवर") के हिसाब से एक ड्राइवर को लागू कर सकता है और उस क्लास को लागू करने वाले किसी भी डिवाइस पर यह काम करेगा. यह हर उस मैन्युफ़ैक्चरर के लिए एक बहुत अच्छा सुधार था जिसे अपने डिवाइस ड्राइवर बनाने की ज़रूरत थी.

हालांकि, कुछ डिवाइस, स्टैंडर्ड डिवाइस की इन क्लास में फ़िट नहीं होते. इसके बजाय, मैन्युफ़ैक्चरर अपने डिवाइस को, वेंडर के लिए तय की गई क्लास के तौर पर लेबल कर सकता है. इस मामले में, ऑपरेटिंग सिस्टम यह चुनता है कि वेंडर के ड्राइवर पैकेज में दी गई जानकारी के आधार पर, किस डिवाइस को लोड करना है. आम तौर पर, यह वेंडर और प्रॉडक्ट आईडी का एक सेट होता है, जिन्हें किसी खास वेंडर के लिए प्रोटोकॉल लागू करने के लिए जाना जाता है.

यूएसबी की एक और सुविधा है कि वे जिस होस्ट से जुड़े हैं, डिवाइस उसे कई इंटरफ़ेस उपलब्ध करा सकते हैं. हर इंटरफ़ेस में या तो एक स्टैंडर्ड क्लास या वेंडर के हिसाब से क्लास लागू की जा सकती है. जब कोई ऑपरेटिंग सिस्टम डिवाइस को हैंडल करने के लिए सही ड्राइवर चुनता है, तब अलग-अलग ड्राइवर के ज़रिए हर इंटरफ़ेस पर दावा किया जा सकता है. उदाहरण के लिए, एक यूएसबी वेबकैम आम तौर पर दो इंटरफ़ेस देता है. पहला इंटरफ़ेस यूएसबी वीडियो क्लास (कैमरे के लिए) और दूसरा यूएसबी ऑडियो क्लास (माइक्रोफ़ोन के लिए) लागू करता है. ऑपरेटिंग सिस्टम एक "वेबकैम ड्राइवर" को लोड नहीं करता है. इसके बजाय, यह स्वतंत्र वीडियो और ऑडियो क्लास ड्राइवर लोड करता है जो डिवाइस के अलग-अलग काम करने की ज़िम्मेदारी लेते हैं. इंटरफ़ेस क्लास के इस कंपोज़िशन से ज़्यादा आसानी से काम किया जा सकता है.

एपीआई की बुनियादी बातें

कई स्टैंडर्ड यूएसबी क्लास के पास वेब एपीआई होते हैं. उदाहरण के लिए, कोई पेज getUserMedia() का इस्तेमाल करके, वीडियो क्लास डिवाइस से वीडियो कैप्चर कर सकता है या किसी इंसान के इंटरफ़ेस (एचआईडी) क्लास डिवाइस से इनपुट इवेंट पा सकता है. इसके लिए, वह KeyboardEvents या PointerEvents का इस्तेमाल कर सकता है या Gamepad या WebHID एपीआई का इस्तेमाल कर सकता है. सभी डिवाइस, स्टैंडर्ड क्लास डेफ़िनिशन को लागू नहीं करते. इसी तरह, सभी डिवाइस मौजूदा वेब प्लैटफ़ॉर्म एपीआई से जुड़ी सुविधाएं लागू नहीं करते. ऐसे मामलों में WebUSB API, साइटों को वेंडर के हिसाब से इंटरफ़ेस पर दावा करने और इसके लिए सीधे उनके पेज से सहायता लागू करने का तरीका उपलब्ध कराएगा.

अलग-अलग ऑपरेटिंग सिस्टम, यूएसबी डिवाइसों को मैनेज करने के तरीके में अंतर की वजह से किसी डिवाइस को WebUSB से ऐक्सेस करने की शर्तें अलग-अलग होंगी. हालांकि, इसके लिए डिवाइस में पहले से कोई ऐसा ड्राइवर नहीं होना चाहिए जिसे पेज कंट्रोल करना है. यह काम, ओएस वेंडर की ओर से उपलब्ध कराया गया सामान्य क्लास ड्राइवर हो सकता है या वेंडर से मिला डिवाइस ड्राइवर हो सकता है. यूएसबी डिवाइस कई इंटरफ़ेस उपलब्ध करा सकते हैं और हर इंटरफ़ेस का अपना ड्राइवर हो सकता है. इसलिए, ऐसा डिवाइस बनाया जा सकता है जिसके लिए कुछ इंटरफ़ेस पर ड्राइवर का दावा होता है और कुछ पर ब्राउज़र ऐक्सेस कर पाता है.

उदाहरण के लिए, एक बेहतर यूएसबी कीबोर्ड ऐसा एचआईडी क्लास इंटरफ़ेस दे सकता है जिसका दावा ऑपरेटिंग सिस्टम के इनपुट सबसिस्टम से किया जाएगा. साथ ही, वेंडर के हिसाब से बनाया गया एक इंटरफ़ेस भी इस पर काम करेगा जो कॉन्फ़िगरेशन टूल के लिए WebUSB के लिए उपलब्ध रहेगा. यह टूल मैन्युफ़ैक्चरर की वेबसाइट पर दिखाया जा सकता है. इससे उपयोगकर्ता, प्लैटफ़ॉर्म के हिसाब से सॉफ़्टवेयर इंस्टॉल किए बिना, डिवाइस के काम करने से जुड़े पहलुओं में बदलाव कर सकता है, जैसे कि मैक्रो बटन और लाइटिंग इफ़ेक्ट. ऐसे डिवाइस का कॉन्फ़िगरेशन डिस्क्रिप्टर कुछ ऐसा दिखेगा:

कॉन्फ़िगरेशन डिस्क्रिप्टर में एक साथ जोड़े गए कई डिस्क्रिप्टर होते हैं. हर फ़ील्ड bLength और bDescriptorType फ़ील्ड से शुरू होता है, ताकि उन्हें पहचाना जा सके. पहला इंटरफ़ेस एक एचआईडी इंटरफ़ेस है, जिसमें एचआईडी डिस्क्रिप्टर और एक एंडपॉइंट होता है. इसका इस्तेमाल, ऑपरेटिंग सिस्टम को इनपुट इवेंट डिलीवर करने के लिए किया जाता है. दूसरा इंटरफ़ेस, वेंडर के लिए खास तौर पर बना इंटरफ़ेस है, जिसमें दो एंडपॉइंट होते हैं. इनका इस्तेमाल डिवाइस को निर्देश भेजने और बदले में जवाब पाने के लिए किया जा सकता है.

WebUSB डिस्क्रिप्टर

WebUSB, फ़र्मवेयर में बदलाव किए बिना भी कई डिवाइसों पर काम कर सकता है. हालांकि, कुछ अन्य फ़ंक्शन को चालू करने के लिए, डिवाइस को खास जानकारी देने वाले डिस्क्रिप्टर से मार्क किया जाता है. इससे पता चलता है कि यह सुविधा WebUSB के साथ काम कर सकता है. उदाहरण के लिए, आपके पास उस लैंडिंग पेज का यूआरएल तय करने का विकल्प होता है जिस पर ब्राउज़र, उपयोगकर्ता को डिवाइस के प्लग इन होने पर ले जा सके.

बाइनरी डिवाइस ऑब्जेक्ट स्टोर (बीओएस), यूएसबी 3.0 में शुरू किया गया एक कॉन्सेप्ट है. हालांकि, इसे वर्शन 2.1 के हिस्से के तौर पर यूएसबी 2.0 डिवाइसों पर भी बैकपोर्ट किया गया है. WebUSB के लिए सहायता का एलान करने की प्रक्रिया, BOS डिस्क्रिप्टर में नीचे दी गई प्लैटफ़ॉर्म की क्षमता के ब्यौरे को शामिल करने से शुरू होती है:

प्लैटफ़ॉर्म क्षमता यूयूआईडी, इसकी पहचान WebUSB Platform की क्षमता का ब्यौरा देने वाले के तौर पर करती है, जिससे डिवाइस के बारे में बुनियादी जानकारी मिलती है. ब्राउज़र, डिवाइस के बारे में ज़्यादा जानकारी फ़ेच कर सके, इसके लिए यह bVendorCode वैल्यू का इस्तेमाल करता है. इससे डिवाइस को और अनुरोध भेजने में मदद मिलती है. फ़िलहाल, सिर्फ़ GET_URL अनुरोध के बारे में बताया गया है, जो यूआरएल डिस्क्रिप्टर दिखाता है. ये, स्ट्रिंग डिस्क्रिप्टर की तरह होते हैं. हालांकि, इन्हें कम से कम बाइट में यूआरएल को कोड में बदलने के लिए डिज़ाइन किया गया है. "https://google.com" का यूआरएल डिस्क्रिप्टर कुछ ऐसा दिखेगा:

जब आपके डिवाइस को ब्राउज़र में पहली बार प्लग किया जाता है, तो इस स्टैंडर्ड GET_DESCRIPTOR कंट्रोल ट्रांसफ़र को जारी करके, BOS डिस्क्रिप्टर को पढ़ा जाता है:

आम तौर पर यह अनुरोध दो बार किया जाता है. पहली बार, जब पहली बार काफ़ी बड़े wLength का इस्तेमाल किया जाता है, ताकि होस्ट को बहुत ज़्यादा डेटा ट्रांसफ़र किए बिना, wTotalLength फ़ील्ड की वैल्यू का पता चल सके. इसके बाद, तब अनुरोध किया जाता है, जब डेटा की पूरी जानकारी पता चल जाती है.

अगर WebUSB Platform की क्षमता की जानकारी देने वाले डिस्क्रिप्टर ने iLandingPage फ़ील्ड को ज़ीरो वैल्यू पर सेट किया है, तो ब्राउज़र WebUSB के लिए खास GET_URL अनुरोध करेगा. इसके लिए, वह कंट्रोल ट्रांसफ़र जारी करेगा, जिसमें bRequest को प्लैटफ़ॉर्म क्षमता डिस्क्रिप्टर से bVendorCode वैल्यू पर और iLandingPage वैल्यू पर सेट किया गया wValue होगा. GET_URL (0x02) के लिए अनुरोध कोड wIndex में चलेगा:

फिर से, डिस्क्रिप्टर की लंबाई की पहली जांच करने के लिए, यह अनुरोध दो बार जारी किया जा सकता है.

प्लैटफ़ॉर्म के हिसाब से ध्यान देने वाली बातें

WebUSB API, यूएसबी डिवाइस को ऐक्सेस करने के लिए एक जैसा इंटरफ़ेस उपलब्ध कराने की कोशिश करता है. हालांकि, इसके डेवलपर को ऐप्लिकेशन के लिए लागू होने वाली ज़रूरी शर्तों की जानकारी होनी चाहिए. जैसे, डिवाइस ऐक्सेस करने के लिए वेब ब्राउज़र की ज़रूरी शर्तें.

macOS

macOS के लिए, कुछ भी खास करने की ज़रूरत नहीं होती है. WebUSB का इस्तेमाल करने वाली वेबसाइट, डिवाइस से कनेक्ट हो सकती है. साथ ही, ऐसे इंटरफ़ेस पर दावा कर सकती है जिस पर किसी कर्नेल ड्राइवर या दूसरे ऐप्लिकेशन ने दावा नहीं किया है.

Linux

Linux, macOS की तरह है. हालांकि, ज़्यादातर डिस्ट्रिब्यूशन, डिफ़ॉल्ट रूप से यूएसबी डिवाइसों को खोलने की अनुमति वाले उपयोगकर्ता खाते सेट अप नहीं करते. udev नाम के सिस्टम डीमन की ज़िम्मेदारी होती है कि वह उपयोगकर्ता और ग्रुप को डिवाइस ऐक्सेस करने की अनुमति दे. इसी तरह, वेंडर और प्रॉडक्ट आईडी से मेल खाने वाले डिवाइस का मालिकाना हक, plugdev ग्रुप को असाइन किया जाएगा. यह ग्रुप, सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) का ऐक्सेस रखने वाले उपयोगकर्ताओं का ही है:

SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX", ATTR{idProduct}=="XXXX", GROUP="plugdev"

XXXX को अपने डिवाइस के हेक्साडेसिमल वेंडर और प्रॉडक्ट आईडी से बदलें उदाहरण के लिए, ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e11" किसी Nexus One फ़ोन से मेल खाएगा. इन्हें सामान्य "0x" प्रीफ़िक्स के बिना लिखा जाना चाहिए और सभी छोटे अक्षरों की सही पहचान की जानी चाहिए. अपने डिवाइस के आईडी ढूंढने के लिए, कमांड लाइन टूल lsusb चलाएं.

यह नियम /etc/udev/rules.d डायरेक्ट्री की किसी फ़ाइल में रखा जाना चाहिए. जैसे ही डिवाइस प्लग इन किया जाएगा, यह नियम लागू हो जाएगा. आपको Udev को रीस्टार्ट करने की ज़रूरत नहीं है.

Android

Android प्लैटफ़ॉर्म, Linux पर आधारित है, लेकिन इसके लिए सिस्टम कॉन्फ़िगरेशन में किसी बदलाव की ज़रूरत नहीं होती. डिफ़ॉल्ट रूप से, जिस डिवाइस में ऑपरेटिंग सिस्टम में ड्राइवर नहीं होता वह ब्राउज़र में काम कर सकता है. डेवलपर को जानकारी होनी चाहिए हालांकि, डिवाइस से कनेक्ट करते समय उपयोगकर्ताओं को एक और चरण पूरा करना चाहिए. जब कोई उपयोगकर्ता requestDevice() को कॉल करने के जवाब में डिवाइस चुनता है, तो Android एक प्रॉम्प्ट दिखेगा. इसमें पूछा जाएगा कि Chrome को इसे ऐक्सेस करने की अनुमति देनी है या नहीं. अगर उपयोगकर्ता किसी ऐसी वेबसाइट पर वापस लौटता है जिसे पहले से ही किसी डिवाइस से कनेक्ट करने की अनुमति है और वेबसाइट open() कॉल करती है, तब भी यह प्रॉम्प्ट फिर से दिखता है.

इसके अलावा, डेस्कटॉप Linux के मुकाबले Android पर ज़्यादा डिवाइसों को ऐक्सेस किया जा सकेगा क्योंकि डिफ़ॉल्ट रूप से, कम ड्राइवर शामिल किए जाते हैं. उदाहरण के लिए, एक बड़ी गलती, यूएसबी सीडीसी-एसीएम क्लास है, जिसे आम तौर पर यूएसबी-टू-सीरियल अडैप्टर से लागू किया जाता है. ऐसा इसलिए होता है, क्योंकि Android SDK में सीरियल डिवाइस से कम्यूनिकेट करने के लिए कोई एपीआई नहीं होता.

ChromeOS

ChromeOS भी Linux पर आधारित होता है. इसके लिए, सिस्टम के कॉन्फ़िगरेशन में कोई बदलाव करने की ज़रूरत नहीं होती. अनुमति देने वाली सेवा, यूएसबी डिवाइसों के ऐक्सेस को कंट्रोल करती है और ब्राउज़र को उन्हें तब तक ऐक्सेस करने देती है, जब तक कम से कम एक ऐसा इंटरफ़ेस हो जिस पर दावा नहीं किया गया है.

Windows

Windows ड्राइवर के मॉडल में एक अतिरिक्त शर्त शामिल की गई है. उपयोगकर्ता ऐप्लिकेशन से यूएसबी डिवाइस खोलने की सुविधा, डिफ़ॉल्ट रूप से काम नहीं करती. भले ही, कोई ड्राइवर लोड न हो. इसके बजाय, एक खास ड्राइव, WinUSB होता है, जिसे लोड करने की ज़रूरत होती है, ताकि डिवाइस ऐक्सेस करने के लिए इस्तेमाल किए जाने वाले इंटरफ़ेस ऐप्लिकेशन को उपलब्ध कराया जा सके. ऐसा, सिस्टम पर इंस्टॉल की गई कस्टम ड्राइवर जानकारी फ़ाइल (आईएनएफ़) की मदद से किया जा सकता है. इसके अलावा, गिनती के दौरान Microsoft OS कंपैटिबिलिटी डिस्क्रिप्टर देने के लिए, डिवाइस फ़र्मवेयर में बदलाव करके भी ऐसा किया जा सकता है.

ड्राइवर की जानकारी देने वाली फ़ाइल (आईएनएफ़)

ड्राइवर की जानकारी वाली फ़ाइल, Windows को यह बताती है कि किसी डिवाइस का पहली बार सामना करने पर क्या करना चाहिए. उपयोगकर्ता के सिस्टम में पहले से ही WinUSB ड्राइवर शामिल होता है, जो आईएनएफ़ फ़ाइल को इंस्टॉल करने के इस नए नियम के साथ आपके वेंडर और प्रॉडक्ट आईडी से जोड़ने के लिए ज़रूरी है. नीचे दी गई फ़ाइल में इसका एक सामान्य उदाहरण दिया गया है. इसे .inf एक्सटेंशन वाली फ़ाइल में सेव करें, "X" से मार्क किए गए सेक्शन को बदलें, फिर इस पर राइट क्लिक करें और संदर्भ मेन्यू से "इंस्टॉल करें" चुनें.

[Version]
Signature   = "$Windows NT$"
Class       = USBDevice
ClassGUID   = {88BAE032-5A81-49f0-BC3D-A4FF138216D6}
Provider    = %ManufacturerName%
CatalogFile = WinUSBInstallation.cat
DriverVer   = 09/04/2012,13.54.20.543

; ========== Manufacturer/Models sections ===========

[Manufacturer]
%ManufacturerName% = Standard,NTx86,NTia64,NTamd64

[Standard.NTx86]
%USB\MyCustomDevice.DeviceDesc% = USB_Install,USB\VID_XXXX&PID_XXXX

[Standard.NTia64]
%USB\MyCustomDevice.DeviceDesc% = USB_Install,USB\VID_XXXX&PID_XXXX

[Standard.NTamd64]
%USB\MyCustomDevice.DeviceDesc% = USB_Install,USB\VID_XXXX&PID_XXXX

; ========== Class definition ===========

[ClassInstall32]
AddReg = ClassInstall_AddReg

[ClassInstall_AddReg]
HKR,,,,%ClassName%
HKR,,NoInstallClass,,1
HKR,,IconPath,%REG_MULTI_SZ%,"%systemroot%\system32\setupapi.dll,-20"
HKR,,LowerLogoVersion,,5.2

; =================== Installation ===================

[USB_Install]
Include = winusb.inf
Needs   = WINUSB.NT

[USB_Install.Services]
Include = winusb.inf
Needs   = WINUSB.NT.Services

[USB_Install.HW]
AddReg = Dev_AddReg

[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"

; =================== Strings ===================

[Strings]
ManufacturerName              = "Your Company Name Here"
ClassName                     = "Your Company Devices"
USB\MyCustomDevice.DeviceDesc = "Your Device Name Here"

[Dev_AddReg] सेक्शन, डिवाइस के लिए DeviceInterfaceGUID के सेट को कॉन्फ़िगर करता है. हर डिवाइस इंटरफ़ेस में GUID होना ज़रूरी है, ताकि कोई ऐप्लिकेशन उसे Windows API के ज़रिए ढूंढ सके और उससे कनेक्ट कर सके. रैंडम जीयूआईडी जनरेट करने के लिए, New-Guid PowerShell cmdlet या किसी ऑनलाइन टूल का इस्तेमाल करें.

गेम को डेवलप करने के लिए, Zadig टूल एक आसान इंटरफ़ेस उपलब्ध कराता है. इसकी मदद से, यूएसबी इंटरफ़ेस के लिए लोड किए गए ड्राइवर को WinUSB ड्राइवर से बदला जा सकता है.

Microsoft OS के साथ काम करने वाले डिस्क्रिप्टर

ऊपर दी गई INF फ़ाइल प्रोसेस मुश्किल है, क्योंकि इसके लिए हर उपयोगकर्ता की मशीन को समय से पहले कॉन्फ़िगर करना ज़रूरी होता है. Windows 8.1 और उसके बाद के वर्शन में, कस्टम यूएसबी डिस्क्रिप्टर इस्तेमाल करके, इसके विकल्प मिलते हैं. जब डिवाइस को पहली बार प्लग-इन किया जाता है, तब Windows ऑपरेटिंग सिस्टम को ये जानकारी मिलती है, जिसे आम तौर पर INF फ़ाइल में शामिल किया जाता है.

WebUSB डिस्क्रिप्टर को सेट अप करने के बाद, Microsoft के ओएस के साथ काम करने वाले डिस्क्रिप्टर को जोड़ना आसान होता है. पहले इस अतिरिक्त प्लैटफ़ॉर्म क्षमता डिस्क्रिप्टर की मदद से BOS डिस्क्रिप्टर को बढ़ाएं. इसे असाइन करने के लिए, wTotalLength और bNumDeviceCaps को अपडेट करना न भूलें.

WebUSB डिस्क्रिप्टर की तरह ही, आपको एक bRequest वैल्यू चुननी होगी, ताकि इन डिस्क्रिप्टर से जुड़े कंट्रोल ट्रांसफ़र में उसका इस्तेमाल किया जा सके. इस उदाहरण में, मैंने 0x02 को चुना है. wIndex में रखा गया 0x07, डिवाइस से Microsoft OS 2.0 डिस्क्रिप्टर सेट को वापस लाने का निर्देश है.

किसी यूएसबी डिवाइस में कई फ़ंक्शन हो सकते हैं. इसलिए, डिस्क्रिप्टर सेट का पहला हिस्सा यह बताता है कि इसके बाद आने वाली प्रॉपर्टी किस फ़ंक्शन से जुड़ी हैं. नीचे दिया गया उदाहरण, कंपोज़िट डिवाइस के इंटरफ़ेस 1 को कॉन्फ़िगर करता है. डिस्क्रिप्टर, ओएस को इस इंटरफ़ेस के बारे में दो अहम जानकारी देता है. साथ काम करने वाले आईडी डिस्क्रिप्टर से, Windows को पता चलता है कि यह डिवाइस WinUSBdriver के साथ काम करता है. रजिस्ट्री प्रॉपर्टी डिस्क्रिप्टर, ऊपर दिए गए INF के उदाहरण के [Dev_AddReg] सेक्शन की तरह ही काम करता है. इसमें, इस फ़ंक्शन को डिवाइस इंटरफ़ेस GUID असाइन करने के लिए, रजिस्ट्री प्रॉपर्टी सेट की गई है.

Windows इस जानकारी के लिए डिवाइस से सिर्फ़ एक बार क्वेरी करेगा. अगर डिवाइस सही जानकारी देने के साथ जवाब नहीं देता है, तो अगली बार डिवाइस कनेक्ट होने पर फिर से नहीं पूछा जाएगा. Microsoft ने यूएसबी डिवाइस रजिस्ट्री की एक सूची दी है. इसमें उन रजिस्ट्री एंट्री के बारे में बताया गया है जो किसी डिवाइस की जानकारी को कैलकुलेट करते समय बनाई गई थीं. जांच करते समय, किसी डिवाइस के लिए बनाई गई एंट्री मिटाएं. इससे Windows को डिस्क्रिप्टर को फिर से पढ़ने की कोशिश करनी होगी.

इन डिस्क्रिप्टर को इस्तेमाल करने के तरीके के बारे में ज़्यादा जानकारी के लिए, Microsoft की ब्लॉग पोस्ट देखें.

उदाहरण

इन प्रोजेक्ट में ऐसे कोड का उदाहरण दिया गया है जिसे लागू करने के लिए, WebUSB जानकारी वाले डिवाइसों का इस्तेमाल किया जाता है. इनमें WebUSB की जानकारी देने वाले और Microsoft OS डिस्क्रिप्टर, दोनों शामिल होते हैं:

• WebLight
• WebUSB Aduino लाइब्रेरी