कब और क्यों - आपको विंडोज रजिस्ट्री में डेटा स्टोर करना चाहिए?

126

एक डेवलपर के रूप में, रजिस्ट्री में कॉन्फ़िगरेशन / विकल्प स्टोर करने वाले उपकरण मेरे जीवन का प्रतिबंध हैं। मैं उन विकल्पों में परिवर्तन को आसानी से ट्रैक नहीं कर सकता, उन्हें आसानी से मशीन से मशीन में पोर्ट नहीं कर सकता, और यह सब मुझे। Ini फ़ाइलों के पुराने दिनों के लिए वास्तव में तरस रहा है ...

अपने स्वयं के एप्लिकेशन लिखते समय, क्या - यदि कुछ भी - क्या मुझे पुराने जमाने की कॉन्फ़िगरेशन फ़ाइलों के बजाय रजिस्ट्री में रखना चाहिए, और क्यों?

windows registry

— रोडी
स्रोत

मैं अभी एक विरासत ऐप के साथ काम करता हूं जो रजिस्ट्री (.NET ऐप) में जानकारी संग्रहीत करता है, और यह मुझे पागल कर देता है।

— जॉर्ज स्टॉकर

75

मूल रूप से (Win3) कॉन्फ़िगरेशन विंडोज़ निर्देशिका में WIN.INI फ़ाइल में संग्रहीत किया गया था।
समस्या: WIN.INI बहुत बड़ा हो गया।
समाधान (Win31): कार्यक्रम के रूप में एक ही निर्देशिका में व्यक्तिगत INI फ़ाइलें।
समस्या: उस कार्यक्रम को एक नेटवर्क पर स्थापित किया जा सकता है और कई लोगों द्वारा साझा किया जा सकता है।
समाधान (Win311): उपयोगकर्ता की विंडो निर्देशिका में व्यक्तिगत INI फ़ाइलें।
समस्या: कई लोग एक विंडोज़ फ़ोल्डर साझा कर सकते हैं, और इसे केवल-वैसे भी पढ़ा जाना चाहिए।
समाधान (Win95): प्रत्येक उपयोगकर्ता के लिए अलग-अलग वर्गों के साथ रजिस्ट्री।
समस्या: रजिस्ट्री बहुत बड़ी हो गई।
समाधान (WinXP): व्यक्तिगत डेटा के बड़े ब्लॉक उपयोगकर्ता के अपने एप्लिकेशन डेटा फ़ोल्डर में चले गए।
समस्या: बड़ी मात्रा में डेटा के लिए अच्छा है, बल्कि छोटी मात्रा के लिए जटिल है।
सॉल्यूशन (.NET): निश्चित मात्रा में, केवल-पढ़ने के लिए डेटा .config (Xml) फ़ाइलों को एप्लिकेशन के समान फ़ोल्डर में संग्रहीत किया जाता है, इसे पढ़ने के लिए API के साथ। (पढ़ें या लिखना या उपयोगकर्ता विशिष्ट डेटा रजिस्ट्री में रहता है)

— जेम्स क्यूरन
स्रोत

16

यूनिक्स: $ Home / .your-app में संग्रहित विन्यास, एक पुनरावृत्ति में हल।

— लियोनेल

33

यूनिक्स समाधान आदर्श से बहुत दूर है: $ HOME को डॉट-फाइलों के साथ फूला हुआ है, और आपको पता नहीं है कि उनमें से अधिकांश क्या करते हैं।

— grep

2

@Leonel XDG वास्तव $HOME/.config/your-app/में यह कहता है कि आपको अपनी कॉन्फिग फाइल्स को अंदर रखना चाहिए , इस समस्या से निपटने के लिए बनाया गया एक उपाय @grep ऑब्जेक्ट्स। और, आश्चर्य, आधुनिक लिनक्स (और * GND का उपयोग करने के लिए पर्याप्त BSD के किसी पर भी ) एक gconfसूट में एक रजिस्ट्री भी है । FOSS नस्लों के विकल्प, यह सुनिश्चित करने के लिए;)

— new123456

1

@ जीआरईपी, " कोई विचार नहीं कि उनमें से अधिकांश क्या करते हैं ", क्यों नहीं? इसके अलावा, ब्लोट विंडोज के साथ तुलना करने में मुश्किल है।

— पचेरियर

16

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

मैं विचार के स्कूल से आता हूं जो कहता है कि जहां भी स्थापित किया गया है, वहां से एक कार्यक्रम को चलाने योग्य होना चाहिए, कि स्थापना पूरी तरह से एक मशीन के भीतर या किसी अन्य मशीन के लिए भी चल सकती है और इसे चलाने को प्रभावित नहीं करना चाहिए।

किसी भी विन्यास योग्य विकल्प, या आवश्यक dlls आदि, यदि वे साझा नहीं किए जाते हैं, तो उन्हें इंस्टॉलेशन डायरेक्टरी के एक उपनिर्देशिका में रहना चाहिए, ताकि पूरी स्थापना आसानी से चले।

मैं कार्यक्रमों की तरह बहुत छोटी उपयोगिता का उपयोग करता हूं, इसलिए अगर यह एक यूएसबी स्टिक पर स्थापित नहीं किया जा सकता है और किसी अन्य मशीन में प्लग किया जाएगा और बस चलेगा, तो यह मेरे लिए नहीं है।

— Jimoc
स्रोत

4

लेकिन स्थापना अक्सर व्यवस्थापक नियंत्रण के तहत की जाती है, जबकि उपयोगकर्ता नियंत्रण के तहत अद्यतन सेटिंग्स होनी चाहिए। सेटिंग्स को अपडेट करने की कोशिश करें - उपयोगकर्ता की पहचान के तहत चलने वाला ऐप जो एक निर्देशिका को लिखना चाहता है जो केवल एडमिन-एक्सेस तक ही सीमित है। यह उन चीजों में से एक है जिन्हें रजिस्ट्री को संबोधित करने का इरादा है।

— चेसो

@ कैश, समाधान प्रत्येक उपयोगकर्ता के लिए निष्पादन योग्य की एक प्रति है। अंतरिक्ष को बचाने के लिए, एक वास्तविक प्रतिलिपि नहीं बल्कि सिर्फ एक नकली प्रतिलिपि (पॉइंटर)।

— पेसियर

12

Microsoft नीति:

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

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

— तून Krijthe
स्रोत

1

क्या आप दस्तावेज़ की मूल लिंक प्रदान कर सकते हैं जो Microsoft की इस नीति को बताती है? और जब आप नीति कहते हैं, तो क्या आपका मतलब है, यह वही है जो Microsoft करता है, या क्या आप इसका मतलब यह है कि माइक्रोसॉफ्ट विंडोज के लिए एप्लिकेशन बनाने वाले देवों की सिफारिश करता है?

— चेसो

1

ps: Microsoft के रेमंड चेन ने कहा है कि INI फाइलें रजिस्ट्री के पक्ष में पदावनत हैं, और बताती हैं कि क्यों। blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx वह यह भी बताता है कि XML फ़ाइलों में ini फ़ाइलों के समान ही कई कमियां हैं।

— चेसो

8

XML सेटिंग्स फाइलें = INI फाइलें जो पार्स करने के लिए कठिन हैं

— रॉबर्ट फ्रेजर

3

@Fraser यदि आपको लगता है कि XML को पार्स करना मुश्किल है, तो आप गलत व्यवसाय में हैं।

— स्नेकडोक

@SnakeDoc, हार्डर का मतलब अधिक कठिन नहीं है। इसका सीधा सा मतलब है कि धीमी पार्सिंग और लैग।

— पचेरियर

12

जब - आपको विरासत के एकीकरण के कारण मजबूर किया जाता है या क्योंकि आपके ग्राहक का sysadmin कहता है "ऐसा होगा" या क्योंकि आप एक पुरानी भाषा में विकसित हो रहे हैं जो XML का उपयोग करना अधिक कठिन बनाता है।

क्यों - मुख्यतः क्योंकि रजिस्ट्री फ़ाइल के बगल में बैठे एक कॉन्फिग फ़ाइल की नकल करने के रूप में पोर्टेबल नहीं है (और इसे लगभग समान कहा जाता है)।

यदि आप .Net2 का उपयोग कर रहे हैं, तो आपको App.Config और User.Config फ़ाइलें मिल गई हैं और आपको रजिस्ट्री में DLL को पंजीकृत करने की आवश्यकता नहीं है इसलिए इससे दूर रहें।

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

समस्या: एप्लिकेशन को विन्यास योग्य सेटिंग्स की आवश्यकता होती है।
समाधान: Windows फ़ोल्डर में एक फ़ाइल (WIN.INI) में सेटिंग्स को स्टोर करें - समूह डेटा (Win3.0) के लिए अनुभाग शीर्षकों का उपयोग करें।
समस्या: WIN.INI फ़ाइल बहुत बड़ी हो गई (और गड़बड़ हो गई)।
समाधान: INI फ़ाइलों में एप्लिकेशन (Win3.1) के समान फ़ोल्डर में स्टोर सेटिंग्स।
समस्या: उपयोगकर्ता-विशिष्ट सेटिंग्स की आवश्यकता है।
समाधान: उपयोगकर्ता-विशिष्ट INI फ़ाइलों में उपयोगकर्ता की विंडो-डायरेक्टरी (Win3.11) या अनुप्रयोग-विशेष फ़ाइल में उपयोगकर्ता-विशिष्ट अनुभागों में उपयोगकर्ता-सेटिंग्स संग्रहीत करें।
समस्या: सुरक्षा - कुछ एप्लिकेशन सेटिंग्स को केवल पढ़ने के लिए आवश्यक है।
समाधान: सुरक्षा के साथ-साथ उपयोगकर्ता-विशिष्ट और मशीन-वाइड सेक्शन (Win95) के साथ रजिस्ट्री।
समस्या: रजिस्ट्री बहुत बड़ी हो गई।
समाधान: उपयोगकर्ता-विशिष्ट रजिस्ट्री उपयोगकर्ता के स्वयं के "एप्लिकेशन डेटा" फ़ोल्डर में user.dat में चली गई और केवल लॉगिन (WinNT) पर लोड की गई।
समस्या: बड़े कॉर्पोरेट वातावरण में आप कई मशीनों पर लॉग इन करते हैं और हर एक को सेट करना होता है।
समाधान: स्थानीय (स्थानीय सेटिंग्स) और रोमिंग (एप्लिकेशन डेटा) प्रोफाइल (WinXP) के बीच अंतर करें।
समस्या: xcopy को लागू नहीं किया जा सकता है या बाकी अनुप्रयोगों की तरह ही स्थानांतरित कर सकते हैं। नेट।
समाधान: APP.CONFIG XML फ़ाइल एक ही फ़ोल्डर में अनुप्रयोग के रूप में -, पढ़ने में आसान, सरल, आसानी से चलना, स्थानांतरित करना आसान है अगर बदल सकता है (.Net1)।
समस्या: अभी भी उपयोगकर्ता-विशिष्ट डेटा को समान (यानी xcopy परिनियोजित) तरीके से संग्रहीत करने की आवश्यकता है।
समाधान: उपयोगकर्ता के स्थानीय या रोमिंग फ़ोल्डर में USER.CONFIG XML फ़ाइल और दृढ़ता से टाइप किया गया (.Net2)।
समस्या: CONFIG फाइलें केस-सेंसिटिव (मनुष्य के लिए सहज नहीं) हैं, इसके लिए बहुत विशिष्ट ओपन / क्लोज "टैग्स" की आवश्यकता होती है, कनेक्शन स्ट्रिंग्स को रन-टाइम पर सेट नहीं किया जा सकता है, सेटअप प्रोजेक्ट सेटिंग्स (जितनी आसानी से रजिस्ट्री) लिख सकते हैं, आसानी से निर्धारित नहीं कर सकते हैं। user.config फ़ाइल और उपयोगकर्ता सेटिंग्स को स्थापित किए गए प्रत्येक नए संशोधन के साथ उड़ाया जाता है।
समाधान: रनटाइम पर कनेक्शन स्ट्रिंग्स सेट करने के लिए ITEM सदस्य का उपयोग करें, इंस्टॉल करने के दौरान App.Config को बदलने के लिए इंस्टालर वर्ग में कोड लिखें और उपयोगकर्ता सेटिंग नहीं मिलने पर डिफॉल्ट के रूप में एप्लिकेशन सेटिंग्स का उपयोग करें।

— AndrewD
स्रोत

यह स्वीकृत की तुलना में कहीं अधिक पूर्ण उत्तर है। साभार @AndrewD

— रोटमैन

8

क्या दुनिया खत्म होने जा रही है यदि आप कुछ विंडो पोजिशन और हाल ही में उपयोग की गई वस्तुओं की सूची को विंडोज रजिस्ट्री में स्टोर करते हैं? यह अब तक मेरे लिए ठीक है।

HKEY-CURRENT-USER छोटी मात्रा में तुच्छ उपयोगकर्ता डेटा को संग्रहीत करने के लिए एक शानदार जगह है। बस यही बात है। यह मूर्खतापूर्ण लगता है कि अपने इच्छित उद्देश्य के लिए उपयोग न करें क्योंकि दूसरों ने इसका दुरुपयोग किया है।

— एंगस ग्लेशियर
स्रोत

और यह खुद को भ्रष्ट करने में बहुत अच्छा है ... यह एक प्लस है। उपयोगकर्ता के लिए कम काम ...

— स्नेकडोक

4

सेटिंग्स जो आप उपयोगकर्ता के रोमिंग प्रोफ़ाइल में उपलब्ध होना चाहते हैं, उन्हें शायद रजिस्ट्री में जाना चाहिए, जब तक कि आप वास्तव में उपयोगकर्ता के एप्लिकेशन डेटा फ़ोल्डर को हाथ से देखने के प्रयास में नहीं जाना चाहते। :-)

— क्रिस जस्टर-यंग
स्रोत

4

रजिस्ट्री पढ़ती है और लिखती है थ्रेडसेफ़ लेकिन फाइलें नहीं हैं। तो यह इस बात पर निर्भर करता है कि आपका प्रोग्राम सिंगल थ्रेडेड है या नहीं।

— मार्टिन
स्रोत

2

आप एक नए एप्लिकेशन विकसित कर रहे हैं और आप पोर्टेबिलिटी के बारे में परवाह है, तो आप चाहिए कभी नहीं की दुकान खिड़कियों में डेटा रजिस्ट्री के बाद से अन्य ओएस एक (विंडोज़) रजिस्ट्री की जरूरत नहीं है (ओह टिप्पणी - यह स्पष्ट हो सकता है लेकिन अक्सर अनदेखी हो जाता है)।

यदि आप केवल विन प्लेटफार्मों के लिए विकसित कर रहे हैं ... जितना संभव हो उतना इसे टालने का प्रयास करें। विन्यास फाइल (संभवतः एन्क्रिप्टेड) एक बेहतर उपाय है। रजिस्ट्री में डेटा संग्रहीत करने में कोई लाभ नहीं है - (यदि आप .NET का उपयोग कर रहे हैं, तो अलग-थलग किया गया स्टोरेज उदाहरण के लिए एक बेहतर समाधान है)।

— JohnIdol
स्रोत

यह आंशिक रूप से सच है। मोनो ने रजिस्ट्रियों के लिए Microsoft.win32 नामस्थान को लागू किया है - सिवाय इसके कि इसे एक फ़ाइल में ~ .mono / रजिस्ट्री में एक xml फ़ाइल में संग्रहीत किया जाए, और इसे पारदर्शी रूप से संभाला जाए। अब अगर आप किसी भी ऐप के लिए प्लेटफ़ॉर्म की परवाह किए बिना xml हैंडलिंग चालू कर सकते हैं ...

— रॉबर्ट पी

नोट: यदि आप .NET / मोनो ऐप लिख रहे हैं तो केवल आप ही उपलब्ध हैं।

— रॉबर्ट पी

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

— जेम्स

2

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

http://doc.trolltech.com/4.4/qsettings.html#details

— rlerallut
स्रोत

ऐसा प्रतीत होता है कि url अब काम नहीं कर रहा है। एक अद्यतन संदर्भ qt-project.org/doc/qt-5/QSettings.html#details

— Eineki

0

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

यदि मैं अपने दस्तावेज़ और सेटिंग फ़ोल्डर को देखता हूं, तो मुझे फ़ोल्डर्स सेट करने के लिए यूनिक्स डॉट नोटेशन का उपयोग करते हुए बहुत सारे सॉफ्टवेयर्स दिखाई देते हैं: .p4qt .sqlworkbench .squirrel-sql। .jindent .jogl_ext (आदि)

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

— PhiLho
स्रोत

यूनिक्स डॉट नोटेशन जो आप देख रहे हैं वह शायद इसलिए है क्योंकि वे सभी उदाहरण पोर्टेड ओपन-सोर्स प्रोजेक्ट्स के हैं, इसलिए नहीं कि यह विंडोज के विकास के लिए सबसे अच्छा अभ्यास है।

— जेम्स

वास्तव में, मैंने नहीं कहा कि यह "सर्वश्रेष्ठ अभ्यास" था, लेकिन सामान्य अभ्यास ... :) एप्लिकेशन डेटा में फ़ोल्डर / हैं / सर्वोत्तम अभ्यास, विशेष रूप से बड़े डेटा के लिए, लेकिन यह भी क्योंकि वे बैकअप लेना आसान हैं।

— फीलो

0

व्यक्तिगत रूप से मैं रजिस्ट्री का उपयोग करने के लिए (संयुक्त राष्ट्र) स्थापित स्क्रिप्ट द्वारा उपयोग के लिए पथ स्थापित करने के लिए इस्तेमाल किया है। मुझे यकीन नहीं है कि यह एकमात्र संभव विकल्प है, लेकिन एक समझदार समाधान की तरह लग रहा था। यह एक ऐसे ऐप के लिए था जो पूरी तरह से विंडोज पर उपयोग में था।

— chillysapien
स्रोत

0

.NET में वास्तव में कभी कोई जरूरत नहीं होती है।

यहां 2 उदाहरण दिए गए हैं जो यह बताते हैं कि ऐसा करने के लिए प्रोजेक्ट प्रॉर्टीज़ का उपयोग कैसे करें।

ये उदाहरण Windows उपयोगकर्ता प्रोजेक्ट गुण द्वारा ऐसा करते हैं, लेकिन अनुप्रयोग द्वारा भी ऐसा ही किया जा सकता है।

यहां अधिक:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

— TheUberOverLord
स्रोत

0

(चर्चा में देर से लेकिन) लघु उत्तर: समूह नीति।

यदि आपके ग्राहक का आईटी विभाग विंडोज से संबंधित सेटिंग्स या घटक (ओं) को लागू करना चाहता है, तो आप इसे लिंक गति या कस्टम त्रुटि संदेश, या डेटाबेस सर्वर से कनेक्ट करने के लिए लिख रहे हैं या बंडल कर रहे हैं, तो यह अभी भी आम तौर पर है समूह नीति के माध्यम से किया जाता है, जो रजिस्ट्री में संग्रहीत सेटिंग्स के रूप में अपनी अंतिम अभिव्यक्ति बनाता है। विंडोज के शुरू होने या उपयोगकर्ता के लॉग इन करने के समय से ऐसी नीतियां लागू होती हैं।

कस्टम ADMX टेम्प्लेट बनाने के लिए उपकरण हैं जो आपके घटकों की सेटिंग्स को रजिस्ट्री स्थानों पर मैप कर सकते हैं, और नीतियों को लागू करने के लिए व्यवस्थापक को एक सामान्य इंटरफ़ेस दे सकते हैं (s) उन्हें केवल उन सेटिंग्स को दिखाने के लिए लागू करने की आवश्यकता है जो इस तरह से लागू करने के लिए सार्थक हैं।

— विग
स्रोत

-1

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

आपके आवेदन की स्थापना रद्द होने के बाद आपके आवेदन का एक निशान छोड़ना (जैसे कि आवेदन फिर से स्थापित होने की स्थिति में उपयोगकर्ता की प्राथमिकताएं याद रखें)
विभिन्न अनुप्रयोगों - घटकों के बीच कॉन्फ़िगरेशन सेटिंग्स साझा करें

— kgiannakakis
स्रोत

5

मैं आपके पहले बिंदु के बारे में आपसे असहमत हूं, "[l] आपके आवेदन की स्थापना रद्द होने के बाद आपके आवेदन का एक निशान पता लगाना"। मुझे लगता है कि अगर मैं कहता हूं कि "अपने आप को मेरे सिस्टम से हटा दें" तो आपका ऐप पूरी तरह से अनुपालन करेगा। मुझे लगता है कि यह अलग होता अगर आप उपयोगकर्ता से पूछ रहे थे कि क्या किसी चीज को पीछे छोड़ना ठीक है, लेकिन फिर भी मैं शायद यह चाहता हूं कि यह एक सहेजे गए कॉन्फ़िगर फ़ाइल हो। लाइसेंसिंग, आदि के बावजूद, यदि आप अपना कंप्यूटर बेच रहे हैं और एक नया खरीद रहे हैं, तो क्या आपके पास एक ऐसी सेटिंग फ़ाइल नहीं होगी जिसे आप अपने द्वारा बेची जाने वाली कंप्यूटर से जुड़ी चीज़ों के बजाय नए इंस्टाल पर लोड कर सकें?

— AgentConundrum

2

कई एप्लिकेशन ऐसा करते हैं और आपको यह कहना सही है कि यह बहुत अच्छी बात नहीं है, खासकर यदि वे उपयोगकर्ता की अनुमति के बिना ऐसा करते हैं। हालाँकि, यह अक्सर कार्यक्षमता उपयोगकर्ताओं को एक आवेदन से उम्मीद है (उपयोगकर्ता के अधिकांश को पता नहीं है कि रजिस्ट्री क्या है)। उपयोगकर्ताओं को बस अपनी सेटिंग्स ऑटो-जादुई रूप से वापस खोजने की उम्मीद है, जब वे फिर से स्थापना और फिर से स्थापित करते हैं।

— किंजनाककिस

2

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

— स्नेकडोक