"सिस्टम प्रोग्रामिंग" से क्या अभिप्राय है?


33

मैं एक विश्व प्रसिद्ध खेल विकास कंपनी में गेम प्रोग्रामर के रूप में इंटर्नशिप की तैयारी कर रहा हूं। जब मैंने आवश्यक पूर्वापेक्षाओं के लिए उनकी वेबसाइट खोजी, तो उसने मुझे यह दिखाया:

एडेड एडवांटेज

  • DirectX / OpenGL का ज्ञान।
  • 3 डी मैथ्स और फिजिक्स पर मजबूत कमांड।
  • C ++ विकास के लिए विजुअल स्टूडियो आईडीई।
  • सिस्टम प्रोग्रामिंग और ओएस अवधारणाएं।

सिस्टम प्रोग्रामिंग और OS अवधारणाओं द्वारा वास्तव में उनका क्या मतलब है?

क्या मुझे विंडोज प्रोग्रामिंग का अध्ययन करना चाहिए? या मुझे लिनक्स प्रोग्रामिंग के साथ जाना चाहिए (मतलब वे चाहते हैं कि मैं महत्वपूर्ण अवधारणाओं को जानना चाहता हूं)। या यह कुछ पूरी तरह से अलग है?


टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
जोश

"क्या मुझे विंडोज प्रोग्रामिंग का अध्ययन करना चाहिए? या क्या मुझे लिनक्स प्रोग्रामिंग के साथ जाना चाहिए" दोनों जहां संभव हो। कम से कम उनके एपीआई के बारे में पढ़ा है, हो सकता है कि संबंधित ओएस एपीआई के साथ एक सरल 'विंडो खोलें' करने की कोशिश करें ताकि आप सीख सकें कि वे कितने अलग हैं और यह एक प्रयास क्या हो सकता है।
फराप

@Pharap तकनीकी रूप से, कोई Linux "OS API" नहीं है जो एक खिड़की खोल सकता है, और यह glut, glfw, या एक खिड़की खोलने के समान उपयोग करना बेहतर है, इसलिए यह X और Wayland (और Windows और macOS) दोनों के साथ काम करेगा।
Majora320

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

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

जवाबों:


54

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

इसका मतलब ग्राफिक्स, रिसोर्स लोडिंग और स्ट्रीमिंग, ऑडियो, मेमोरी मैनेजमेंट, फाइल IO, प्लेटफॉर्म एब्स्ट्रक्शन APIs, et cetera हो सकता है। विवरण काफी भिन्न हैं, और क्योंकि खेल उद्योग में नौकरी के खिताब के लिए कोई मानक नहीं हैं, इसलिए प्रोग्रामिंग डोमेन के नामों के लिए कोई मानक नहीं हैं। एक स्टूडियो में, आप पा सकते हैं कि "सिस्टम प्रोग्रामिंग" का मतलब है जो मैंने ऊपर सूचीबद्ध किया है। दूसरे पर, आप पा सकते हैं कि वे "ग्राफिक्स प्रोग्रामिंग" को एक अलग डोमेन के रूप में अलग करते हैं और हर दूसरे गैर-गेमप्ले-प्रोग्रामिंग कार्य "प्रोग्रामिंग" को कॉल करते हैं। अभी तक किसी अन्य में, वे इस शब्द का उपयोग नहीं कर सकते हैं और इसे "इंजन प्रोग्रामिंग" कह सकते हैं।

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


2
संक्षेप में, मैं कहूंगा कि गैर-सिस्टम प्रोग्रामिंग (वास्तविक गेम) ज्यादातर प्लेटफ़ॉर्म स्वतंत्र होगा (वास्तव में परवाह नहीं है अगर यह मैक / पीसी / एक्सबॉक्स है), जबकि सिस्टम प्रोग्रामिंग बहुत अधिक प्लेटफ़ॉर्म-विशिष्ट (क्रम में) होगा गैर-सिस्टम प्रोग्रामर के लिए प्लेटफ़ॉर्म-स्वतंत्र परत प्रदान करना)।
ट्रिप्पहाउंड

22

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

हमारे सिस्टम टीम में बहुत सारे सामान हैं:

  • मठ पुस्तकालय
  • एसटीडी रिप्लेसमेंट लाइब्रेरी
  • कोर गेम फ्रेमवर्क
  • कोर एप्लीकेशन फ्रेमवर्क
  • इनपुट
  • इवेंट मैसेजिंग
  • घटक-इकाई प्रणाली
  • स्क्रिप्ट बाइंडिंग
  • (और अधिक)

यहां बहुत सारे विंडोज और लिनक्स डोमेन ज्ञान के साथ-साथ भौतिकी, कोर गेम लॉजिक और निम्न स्तर के स्मृति प्रबंधन का भी बहुत कुछ है। सिस्टम टीमें आमतौर पर प्रत्येक समर्थित ओएस में कम से कम कुछ भाग में शामिल होंगी क्योंकि उनकी अधिकांश परियोजनाएं प्रत्येक ओएस पर बहुत कम स्तर पर बैठती हैं।

कुछ चीजें जो "सिस्टम" टीम के अंतर्गत आती हैं, जिन्हें हम अलग-अलग टीमों में तोड़ते हैं (लेकिन हमारी सिस्टम टीम अभी भी बहुत जोर से बातचीत करती है):

  • भौतिक विज्ञान
  • लिनक्स (समर्पित सर्वर)
  • अन्य OSes (iOS / Mac / कंसोल / आदि) के लिए प्रत्यक्ष समर्थन
  • सिस्टम बनाएँ
  • ऑडियो

0

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


मुझे नहीं लगता कि ग्राफिक्स प्रोग्रामर (ओपन विशेषज्ञों) एक प्रणाली प्रोग्रामर काम पर लागू होगा ...
Vaillancourt

ग्राफिक्स प्रोग्रामिंग और ओपनजीएल प्रोग्रामिंग दो अलग-अलग चीजें हैं। एक कंप्यूटर ग्राफिक्स एल्गोरिदम से संबंधित है, दूसरा एपीआई के विवरणों के साथ संबंधित है।
केम कल्याणको

0

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


-6

चूंकि वे विज़ुअल स्टूडियो का संदर्भ देते हैं, सिस्टम प्रोग्रामिंग विशेष रूप से विंडोज़ ऑपरेटिंग सिस्टम के लिए प्रोग्राम लिखने को संदर्भित करता है, जिसका अर्थ है: विंडोज़ syscalls (उदाहरण के लिए कोई कांटा-निष्पादन श्रृंखला नहीं है), उपयोगकर्ता खाते, जहां आपके उपयोगकर्ता विशिष्ट डेटा, डेटा साझा करने के मॉडल में डालते हैं विंडोज़ ऊपर देखें, उदाहरण के लिए आप दृश्य c ++ में वर्तमान उपयोगकर्ता की जांच कैसे कर सकते हैं या एक नई प्रक्रिया कैसे शुरू कर सकते हैं

ओएस कॉन्सेप्ट, शेड्यूलिंग का संदर्भ, एब्सट्रैक्शन, थ्रेड्स, यूजरस्पेस आदि ओएस देव विकि और मंचों को एक अच्छा पढ़ा जा सकता है

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

एमएसडीएन सभी चीजों के लिए ज्ञान का आधार है, विंडोज़ प्रोग्रामिंग एपिस, लाइब्रेरी आदि। https://msdn.microsoft.com/

यदि आप अटके हुए हैं तो वास्तविक कोडिंग के लिए स्टैकओवरफ़्लो।


विंडोज एक एकल उपयोगकर्ता ओएस नहीं है।
मैक्सिमस मिनिमस

और सिस्टम प्रोग्रामिंग का अर्थ विशेष रूप से दिए गए ओएस के लिए प्रोग्राम लिखना नहीं है। उदाहरण के लिए ड्राइवर आसानी से क्रॉस-प्लेटफॉर्म हो सकते हैं। चूंकि वास्तविक विंडोज syscalls रिलीज से रिलीज तक भिन्न होता है, इसलिए इसे सीधे कर्नेल से बात करने के बजाय कर्नेल 32.dll और user32.dll के माध्यम से नियंत्रित किया जाता है।
मैकीज पाइचोटका

@MaciejPiechotka Systemsprogramming हार्डवेयर // ऑपरेटिंग सिस्टम के पास एक स्तर पर प्रोग्रामिंग कर रहा है। एक ड्राइवर का हिस्सा जो क्रॉस प्लेटफॉर्म है, वह एपी है, न कि सीस्कॉल रैपर। लिनक्स में, syscalls लाइब्रेरियों में लिपटे हुए हैं, अन्यथा आप कार्यान्वयन को बदल सकते हैं। उदाहरण के लिए, रजिस्टरों के माध्यम से सीपीयू अस्थायी हो जाना oses के बीच बहुत अलग है।
Git

@ LeComteduMerde-fou यदि आप केवल यह देखते हैं कि उपयोगकर्ताओं को कैसे संभाला जाता है, तो यह है। -> सुरक्षा कुंजी (ctrl + alt + delete), GUI, आदि यूनिक्स // BSD उपयोगकर्ताओं को पूरी तरह से अलग
Git

@ जिस्मो मैं जीने के लिए ड्राइवरों को लिखता हूं - ड्राइवर के लिए बहुत कुछ है जो ओएस-विशिष्ट हिस्सा नहीं है तब एपीआई;) syscalls के बारे में मेरी बात अलग थी फिर ड्राइवरों के बारे में। निश्चित रूप से लिनक्स में आपके पास पुस्तकालय हैं लेकिन मेरा कहना है कि लिनक्स में syscalls के लिए एक ABI है - यानी syscalls, कम से कम सिद्धांत में, स्थिर और प्रलेखित हैं (और POSIX के बाद करीब से मॉडलिंग की गई)। विंडोज के लिए यूजरस्पेस <-> कर्नेल इंटरफ़ेस को रिलीज के दौरान स्थिर नहीं माना जाता है।
Maciej Piechotka
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.