🥇Windows Native Applications and Acronis Active Restore سروس

آج ہم اس کہانی کو جاری رکھتے ہیں کہ کس طرح ہم، Innopolis یونیورسٹی کے لڑکوں کے ساتھ، ایکٹو ریسٹور ٹیکنالوجی تیار کر رہے ہیں تاکہ صارف ناکامی کے بعد جلد از جلد اپنی مشین پر کام شروع کر سکے۔ ہم مقامی ونڈوز ایپلی کیشنز کے بارے میں بات کریں گے، بشمول ان کی تخلیق اور لانچ کی خصوصیات۔ کٹ کے نیچے ہمارے پروجیکٹ کے بارے میں تھوڑا سا ہے، ساتھ ہی مقامی ایپلی کیشنز کو کیسے لکھنا ہے اس کے بارے میں ایک عملی گائیڈ ہے۔

پچھلی پوسٹس میں ہم پہلے ہی بتا چکے ہیں کہ یہ کیا ہے۔ فعال بحالی، اور Innopolis کے طلباء کیسے ترقی کرتے ہیں۔ خدمت. آج میں مقامی ایپلی کیشنز پر توجہ مرکوز کرنا چاہتا ہوں، جس سطح تک ہم اپنی فعال بحالی سروس کو "دفن" کرنا چاہتے ہیں۔ اگر سب کچھ کام کرتا ہے، تو ہم اس قابل ہو جائیں گے:

سروس خود بہت پہلے شروع کریں۔
کلاؤڈ سے رابطہ کریں جہاں بیک اپ بہت پہلے واقع ہے۔
یہ سمجھنے سے بہت پہلے کہ سسٹم کس موڈ میں ہے - نارمل بوٹ یا ریکوری
پیشگی وصولی کے لیے بہت کم فائلیں۔
صارف کو مزید تیزی سے شروع کرنے کی اجازت دیں۔

ویسے بھی مقامی ایپ کیا ہے؟

اس سوال کا جواب دینے کے لیے، آئیے سسٹم کی طرف سے کی جانے والی کالوں کی ترتیب کو دیکھیں، مثال کے طور پر، اگر کوئی پروگرامر اپنی ایپلی کیشن میں فائل بنانے کی کوشش کرتا ہے۔

Pavel Yosifovich - ونڈوز کرنل پروگرامنگ (2019)

پروگرامر فنکشن کا استعمال کرتا ہے۔ فائل بنائیں، جس کا اعلان ہیڈر فائل fileapi.h میں کیا گیا ہے اور Kernel32.dll میں لاگو کیا گیا ہے۔ تاہم، یہ فنکشن خود فائل نہیں بناتا، یہ صرف ان پٹ آرگیومینٹس کو چیک کرتا ہے اور فنکشن کو کال کرتا ہے۔ NtCreateFile (سابقہ Nt صرف اس بات کی نشاندہی کرتا ہے کہ فنکشن مقامی ہے)۔ اس فنکشن کا اعلان winternl.h ہیڈر فائل میں کیا جاتا ہے اور ntdll.dll میں لاگو کیا جاتا ہے۔ یہ جوہری خلا میں چھلانگ لگانے کی تیاری کرتا ہے، جس کے بعد یہ فائل بنانے کے لیے سسٹم کال کرتا ہے۔ اس صورت میں، یہ پتہ چلتا ہے کہ Kernel32 Ntdll کے لیے صرف ایک ریپر ہے۔ ایسا کرنے کی ایک وجہ یہ ہے کہ مائیکروسافٹ اس طرح مقامی دنیا کے افعال کو تبدیل کرنے کی صلاحیت رکھتا ہے، لیکن معیاری انٹرفیس کو چھو نہیں سکتا۔ مائیکروسافٹ مقامی فنکشنز کو براہ راست کال کرنے کی سفارش نہیں کرتا ہے اور ان میں سے زیادہ تر کو دستاویز نہیں کرتا ہے۔ ویسے، غیر دستاویزی فنکشنز مل سکتے ہیں۔ یہاں.

مقامی ایپلی کیشنز کا بنیادی فائدہ یہ ہے کہ ntdll سسٹم میں kernel32 سے بہت پہلے لوڈ ہو جاتا ہے۔ یہ منطقی ہے، کیونکہ kernel32 کو کام کرنے کے لیے ntdll کی ضرورت ہے۔ نتیجتاً، مقامی فنکشنز استعمال کرنے والی ایپلیکیشنز بہت پہلے کام کرنا شروع کر سکتی ہیں۔

اس طرح، ونڈوز مقامی ایپلی کیشنز ایسے پروگرام ہیں جو ونڈوز بوٹ کے شروع میں شروع ہو سکتے ہیں۔ وہ صرف ntdll سے فنکشن استعمال کرتے ہیں۔ اس طرح کی درخواست کی ایک مثال: autochk جو انجام دیتا ہے chkdisk کی افادیت اہم خدمات شروع کرنے سے پہلے ڈسک کی غلطیوں کی جانچ کریں۔ یہ بالکل وہی سطح ہے جو ہم چاہتے ہیں کہ ہماری فعال بحالی ہو۔

ہمیں کیا ضرورت ہے؟

ڈی ڈی کے (ڈرائیور ڈویلپمنٹ کٹ)، جسے اب WDK 7 (Windows Driver Kit) کے نام سے بھی جانا جاتا ہے۔
ورچوئل مشین (مثال کے طور پر، ونڈوز 7 x64)
ضروری نہیں، لیکن ہیڈر فائلیں جو ڈاؤن لوڈ کی جا سکتی ہیں مدد کر سکتی ہیں۔ یہاں

کوڈ میں کیا ہے؟

آئیے تھوڑی سی مشق کریں اور مثال کے طور پر ایک چھوٹی سی درخواست لکھیں جو:

اسکرین پر ایک پیغام دکھاتا ہے۔
کچھ میموری مختص کرتا ہے۔
کی بورڈ ان پٹ کا انتظار ہے۔
استعمال شدہ میموری کو آزاد کرتا ہے۔

مقامی ایپلی کیشنز میں، انٹری پوائنٹ مین یا ون مین نہیں ہوتا ہے، بلکہ NtProcessStartup فنکشن ہوتا ہے، کیونکہ ہم دراصل سسٹم میں نئے عمل کو براہ راست شروع کرتے ہیں۔

آئیے اسکرین پر ایک پیغام دکھا کر شروع کریں۔ اس کے لیے ہمارے پاس ایک مقامی فنکشن ہے۔ NtDisplayString، جو ایک دلیل کے طور پر UNICODE_STRING ساختی آبجیکٹ کی طرف اشارہ کرتا ہے۔ RtlInitUnicodeString اسے شروع کرنے میں ہماری مدد کرے گی۔ نتیجتاً، سکرین پر متن کو ظاہر کرنے کے لیے ہم اس چھوٹے فنکشن کو لکھ سکتے ہیں:

//usage: WriteLn(L"Here is my textn");
void WriteLn(LPWSTR Message)
{
    UNICODE_STRING string;
    RtlInitUnicodeString(&string, Message);
    NtDisplayString(&string);
}

چونکہ ہمارے لیے صرف ntdll کے فنکشنز دستیاب ہیں، اور ابھی تک میموری میں کوئی دوسری لائبریری موجود نہیں ہے، اس لیے ہمیں یقینی طور پر میموری کو مختص کرنے کے بارے میں مسائل کا سامنا کرنا پڑے گا۔ نیا آپریٹر ابھی تک موجود نہیں ہے (کیونکہ یہ C++ کی انتہائی اعلیٰ سطح کی دنیا سے آتا ہے)، اور کوئی malloc فنکشن نہیں ہے (اس کے لیے رن ٹائم C لائبریریوں کی ضرورت ہوتی ہے)۔ یقینا، آپ صرف ایک اسٹیک استعمال کرسکتے ہیں۔ لیکن اگر ہمیں میموری کو متحرک طور پر مختص کرنے کی ضرورت ہے، تو ہمیں اسے ہیپ (یعنی ہیپ) پر کرنا پڑے گا۔ تو آئیے اپنے لیے ایک ڈھیر بنائیں اور جب بھی ضرورت ہو اس سے یاد رکھیں۔

فنکشن اس کام کے لیے موزوں ہے۔ RtlCreateHeap. اس کے بعد، RtlAllocateHeap اور RtlFreeHeap کا استعمال کرتے ہوئے، جب ہمیں ضرورت ہو تو ہم میموری پر قبضہ کریں گے اور اسے آزاد کریں گے۔

PVOID memory = NULL;
PVOID buffer = NULL;
ULONG bufferSize = 42;

// create heap in order to allocate memory later
memory = RtlCreateHeap(
  HEAP_GROWABLE, 
  NULL, 
  1000, 
  0, NULL, NULL
);

// allocate buffer of size bufferSize
buffer = RtlAllocateHeap(
  memory, 
  HEAP_ZERO_MEMORY, 
  bufferSize
);

// free buffer (actually not needed because we destroy heap in next step)
RtlFreeHeap(memory, 0, buffer);

RtlDestroyHeap(memory);

آئیے کی بورڈ ان پٹ کے انتظار میں آگے بڑھتے ہیں۔

// https://docs.microsoft.com/en-us/windows/win32/api/ntddkbd/ns-ntddkbd-keyboard_input_data
typedef struct _KEYBOARD_INPUT_DATA {
  USHORT UnitId;
  USHORT MakeCode;
  USHORT Flags;
  USHORT Reserved;
  ULONG  ExtraInformation;
} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA;

//...

HANDLE hKeyBoard, hEvent;
UNICODE_STRING skull, keyboard;
OBJECT_ATTRIBUTES ObjectAttributes;
IO_STATUS_BLOCK Iosb;
LARGE_INTEGER ByteOffset;
KEYBOARD_INPUT_DATA kbData;

// inialize variables
RtlInitUnicodeString(&keyboard, L"DeviceKeyboardClass0");
InitializeObjectAttributes(&ObjectAttributes, &keyboard, OBJ_CASE_INSENSITIVE, NULL, NULL);

// open keyboard device
NtCreateFile(&hKeyBoard,
			SYNCHRONIZE | GENERIC_READ | FILE_READ_ATTRIBUTES,
			&ObjectAttributes,
			&Iosb,
			NULL,
			FILE_ATTRIBUTE_NORMAL,
			0,
			FILE_OPEN,FILE_DIRECTORY_FILE,
			NULL, 0);

// create event to wait on
InitializeObjectAttributes(&ObjectAttributes, NULL, 0, NULL, NULL);
NtCreateEvent(&hEvent, EVENT_ALL_ACCESS, &ObjectAttributes, 1, 0);

while (TRUE)
{
	NtReadFile(hKeyBoard, hEvent, NULL, NULL, &Iosb, &kbData, sizeof(KEYBOARD_INPUT_DATA), &ByteOffset, NULL);
	NtWaitForSingleObject(hEvent, TRUE, NULL);

	if (kbData.MakeCode == 0x01)    // if ESC pressed
	{
			break;
	}
}

ہمیں صرف استعمال کرنے کی ضرورت ہے۔ NtReadFile کھلے آلے پر، اور انتظار کریں جب تک کہ کی بورڈ ہمیں کوئی پریس واپس نہ کرے۔ اگر ESC کلید کو دبایا جائے تو ہم کام جاری رکھیں گے۔ ڈیوائس کو کھولنے کے لیے، ہمیں NtCreateFile فنکشن کو کال کرنے کی ضرورت ہوگی (ہمیں DeviceKeyboardClass0 کھولنے کی ضرورت ہوگی)۔ ہم بھی بلا لیں گے۔ NtCreateEventانتظار آبجیکٹ کو شروع کرنے کے لیے۔ ہم خود KEYBOARD_INPUT_DATA ڈھانچہ کا اعلان کریں گے، جو کی بورڈ ڈیٹا کی نمائندگی کرتا ہے۔ اس سے ہمارا کام آسان ہو جائے گا۔

مقامی ایپلیکیشن فنکشن کال کے ساتھ ختم ہوتی ہے۔ NtTerminateProcessکیونکہ ہم صرف اپنے عمل کو مار رہے ہیں۔

ہماری چھوٹی درخواست کے تمام کوڈ:

#include "ntifs.h" // WinDDK7600.16385.1incddk
#include "ntdef.h"

//------------------------------------
// Following function definitions can be found in native development kit
// but I am too lazy to include `em so I declare it here
//------------------------------------

NTSYSAPI
NTSTATUS
NTAPI
NtTerminateProcess(
  IN HANDLE               ProcessHandle OPTIONAL,
  IN NTSTATUS             ExitStatus
);

NTSYSAPI 
NTSTATUS
NTAPI
NtDisplayString(
	IN PUNICODE_STRING String
);

NTSTATUS 
NtWaitForSingleObject(
  IN HANDLE         Handle,
  IN BOOLEAN        Alertable,
  IN PLARGE_INTEGER Timeout
);

NTSYSAPI 
NTSTATUS
NTAPI
NtCreateEvent(
    OUT PHANDLE             EventHandle,
    IN ACCESS_MASK          DesiredAccess,
    IN POBJECT_ATTRIBUTES   ObjectAttributes OPTIONAL,
    IN EVENT_TYPE           EventType,
    IN BOOLEAN              InitialState
);



// https://docs.microsoft.com/en-us/windows/win32/api/ntddkbd/ns-ntddkbd-keyboard_input_data
typedef struct _KEYBOARD_INPUT_DATA {
  USHORT UnitId;
  USHORT MakeCode;
  USHORT Flags;
  USHORT Reserved;
  ULONG  ExtraInformation;
} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA;

//----------------------------------------------------------
// Our code goes here
//----------------------------------------------------------

// usage: WriteLn(L"Hello Native World!n");
void WriteLn(LPWSTR Message)
{
    UNICODE_STRING string;
    RtlInitUnicodeString(&string, Message);
    NtDisplayString(&string);
}

void NtProcessStartup(void* StartupArgument)
{
	// it is important to declare all variables at the beginning
	HANDLE hKeyBoard, hEvent;
	UNICODE_STRING skull, keyboard;
	OBJECT_ATTRIBUTES ObjectAttributes;
	IO_STATUS_BLOCK Iosb;
	LARGE_INTEGER ByteOffset;
	KEYBOARD_INPUT_DATA kbData;
	
	PVOID memory = NULL;
	PVOID buffer = NULL;
	ULONG bufferSize = 42;

	//use it if debugger connected to break
	//DbgBreakPoint();

	WriteLn(L"Hello Native World!n");

	// inialize variables
	RtlInitUnicodeString(&keyboard, L"DeviceKeyboardClass0");
	InitializeObjectAttributes(&ObjectAttributes, &keyboard, OBJ_CASE_INSENSITIVE, NULL, NULL);

	// open keyboard device
	NtCreateFile(&hKeyBoard,
				SYNCHRONIZE | GENERIC_READ | FILE_READ_ATTRIBUTES,
				&ObjectAttributes,
				&Iosb,
				NULL,
				FILE_ATTRIBUTE_NORMAL,
				0,
				FILE_OPEN,FILE_DIRECTORY_FILE,
				NULL, 0);

	// create event to wait on
	InitializeObjectAttributes(&ObjectAttributes, NULL, 0, NULL, NULL);
	NtCreateEvent(&hEvent, EVENT_ALL_ACCESS, &ObjectAttributes, 1, 0);
	
	WriteLn(L"Keyboard readyn");
	
	// create heap in order to allocate memory later
	memory = RtlCreateHeap(
	  HEAP_GROWABLE, 
	  NULL, 
	  1000, 
	  0, NULL, NULL
	);
	
	WriteLn(L"Heap readyn");

	// allocate buffer of size bufferSize
	buffer = RtlAllocateHeap(
	  memory, 
	  HEAP_ZERO_MEMORY, 
	  bufferSize
	);
	
	WriteLn(L"Buffer allocatedn");

	// free buffer (actually not needed because we destroy heap in next step)
	RtlFreeHeap(memory, 0, buffer);

	RtlDestroyHeap(memory);
	
	WriteLn(L"Heap destroyedn");
	
	WriteLn(L"Press ESC to continue...n");

	while (TRUE)
	{
		NtReadFile(hKeyBoard, hEvent, NULL, NULL, &Iosb, &kbData, sizeof(KEYBOARD_INPUT_DATA), &ByteOffset, NULL);
		NtWaitForSingleObject(hEvent, TRUE, NULL);

		if (kbData.MakeCode == 0x01)    // if ESC pressed
		{
				break;
		}
	}

	NtTerminateProcess(NtCurrentProcess(), 0);
}

PS: ہم آسانی سے اپنے کوڈ میں DbgBreakPoint() فنکشن کو ڈیبگر میں روکنے کے لیے استعمال کر سکتے ہیں۔ سچ ہے، آپ کو کرنل ڈیبگنگ کے لیے WinDbg کو ورچوئل مشین سے جوڑنے کی ضرورت ہوگی۔ ایسا کرنے کے طریقے کے بارے میں ہدایات مل سکتی ہیں۔ یہاں یا صرف استعمال کریں ورچوئل کے ڈی.

تالیف اور اسمبلی

مقامی ایپلیکیشن بنانے کا سب سے آسان طریقہ استعمال کرنا ہے۔ ڈی ڈی کے (ڈرائیور ڈویلپمنٹ کٹ)۔ ہمیں قدیم ساتویں ورژن کی ضرورت ہے، کیونکہ بعد کے ورژن کا نقطہ نظر قدرے مختلف ہے اور وہ بصری اسٹوڈیو کے ساتھ مل کر کام کرتے ہیں۔ اگر ہم DDK استعمال کرتے ہیں، تو ہمارے پروجیکٹ کو صرف Makefile اور ذرائع کی ضرورت ہے۔

Makefile

!INCLUDE $(NTMAKEENV)makefile.def

ذرائع:

TARGETNAME			= MyNative
TARGETTYPE			= PROGRAM
UMTYPE				= nt
BUFFER_OVERFLOW_CHECKS 		= 0
MINWIN_SDK_LIB_PATH		= $(SDK_LIB_PATH)
SOURCES 			= source.c

INCLUDES 			= $(DDK_INC_PATH); 
				  C:WinDDK7600.16385.1ndk;

TARGETLIBS 			= $(DDK_LIB_PATH)ntdll.lib	
				  $(DDK_LIB_PATH)nt.lib

USE_NTDLL			= 1

آپ کا میک فائل بالکل ویسا ہی ہوگا، لیکن ذرا مزید تفصیل سے ذرائع کو دیکھتے ہیں۔ یہ فائل آپ کے پروگرام کے ذرائع (.c فائلز)، اختیارات کی تعمیر، اور دیگر پیرامیٹرز کی وضاحت کرتی ہے۔

TARGETNAME – قابل عمل فائل کا نام جسے آخر میں تیار کیا جانا چاہئے۔
TARGETTYPE - ایگزیکیوٹیبل فائل کی قسم، یہ ڈرائیور (.sys) ہو سکتی ہے، پھر فیلڈ ویلیو DRIVER ہونی چاہیے، اگر لائبریری (.lib)، تو ویلیو LIBRARY ہے۔ ہمارے معاملے میں، ہمیں ایک قابل عمل فائل (.exe) کی ضرورت ہے، لہذا ہم نے PROGRAM کی قدر مقرر کی ہے۔
UMTYPE – اس فیلڈ کے لیے ممکنہ قدریں: کنسول ایپلیکیشن کے لیے کنسول، ونڈو موڈ میں کام کرنے کے لیے ونڈوز۔ لیکن ہمیں مقامی درخواست حاصل کرنے کے لیے nt کی وضاحت کرنے کی ضرورت ہے۔
BUFFER_OVERFLOW_CHECKS - بفر اوور فلو کے لیے اسٹیک کو چیک کرنا، بدقسمتی سے ہمارا معاملہ نہیں ہے، ہم اسے بند کر دیتے ہیں۔
MINWIN_SDK_LIB_PATH – اس قدر سے مراد SDK_LIB_PATH متغیر ہے، فکر نہ کریں کہ آپ کے پاس ایسا سسٹم ویری ایبل ڈیکلیئر نہیں ہے، جب ہم DDK سے چیک شدہ بلڈ چلاتے ہیں تو یہ ویری ایبل ڈکلیئر ہو جائے گا اور ضروری لائبریریوں کی طرف اشارہ کرے گا۔
ذرائع – آپ کے پروگرام کے ذرائع کی فہرست۔
شامل ہیں - ہیڈر فائلیں جو اسمبلی کے لیے درکار ہیں۔ یہاں وہ عام طور پر DDK کے ساتھ آنے والی فائلوں کے راستے کی نشاندہی کرتے ہیں، لیکن آپ اس کے علاوہ کسی اور کی بھی وضاحت کر سکتے ہیں۔
TARGETLIBS - لائبریریوں کی فہرست جنہیں لنک کرنے کی ضرورت ہے۔
USE_NTDLL ایک مطلوبہ فیلڈ ہے جسے واضح وجوہات کی بنا پر 1 پر سیٹ کیا جانا چاہیے۔
USER_C_FLAGS - کوئی بھی جھنڈا جسے آپ ایپلیکیشن کوڈ تیار کرتے وقت پری پروسیسر کی ہدایات میں استعمال کر سکتے ہیں۔

لہذا تعمیر کرنے کے لیے، ہمیں x86 (یا x64) چیکڈ بلڈ کو چلانے کی ضرورت ہے، ورکنگ ڈائرکٹری کو پروجیکٹ فولڈر میں تبدیل کرنا اور بلڈ کمانڈ کو چلانے کی ضرورت ہے۔ اسکرین شاٹ کا نتیجہ ظاہر کرتا ہے کہ ہمارے پاس ایک قابل عمل فائل ہے۔

اس فائل کو اتنی آسانی سے لانچ نہیں کیا جا سکتا، سسٹم لعنت بھیجتا ہے اور ہمیں مندرجہ ذیل خرابی کے ساتھ اس کے رویے کے بارے میں سوچنے کے لیے بھیجتا ہے:

مقامی ایپلیکیشن کیسے شروع کی جائے؟

جب آٹوچک شروع ہوتا ہے، پروگراموں کے آغاز کی ترتیب کا تعین رجسٹری کلید کی قدر سے ہوتا ہے:

HKLMSystemCurrentControlSetControlSession ManagerBootExecute

سیشن مینیجر اس فہرست سے ایک ایک کرکے پروگرام چلاتا ہے۔ سیشن مینیجر خود سسٹم 32 ڈائرکٹری میں قابل عمل فائلوں کو تلاش کرتا ہے۔ رجسٹری کلیدی قدر کی شکل مندرجہ ذیل ہے:

autocheck autochk *MyNative

قدر ہیکسا ڈیسیمل فارمیٹ میں ہونی چاہیے، عام ASCII کی نہیں، لہذا اوپر دکھائی گئی کلید فارمیٹ میں ہوگی:

61,75,74,6f,63,68,65,63,6b,20,61,75,74,6f,63,68,6b,20,2a,00,4d,79,4e,61,74,69,76,65,00,00

عنوان کو تبدیل کرنے کے لیے، آپ آن لائن سروس استعمال کر سکتے ہیں، مثال کے طور پر، یہ.

یہ پتہ چلتا ہے کہ ایک مقامی ایپلی کیشن شروع کرنے کے لئے، ہمیں ضرورت ہے:

قابل عمل فائل کو سسٹم 32 فولڈر میں کاپی کریں۔
رجسٹری میں ایک کلید شامل کریں۔
مشین کو دوبارہ شروع کریں۔

سہولت کے لیے، مقامی ایپلیکیشن کو انسٹال کرنے کے لیے یہاں ایک ریڈی میڈ اسکرپٹ ہے:

install.bat

@echo off
copy MyNative.exe %systemroot%system32.
regedit /s add.reg
echo Native Example Installed
pause

add.reg

REGEDIT4

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager]
"BootExecute"=hex(7):61,75,74,6f,63,68,65,63,6b,20,61,75,74,6f,63,68,6b,20,2a,00,4d,79,4e,61,74,69,76,65,00,00

انسٹالیشن اور ریبوٹ کے بعد، صارف کے انتخاب کی اسکرین کے ظاہر ہونے سے پہلے، ہمیں درج ذیل تصویر ملے گی۔

کل

اتنی چھوٹی ایپلی کیشن کی مثال استعمال کرتے ہوئے، ہمیں یقین ہو گیا کہ ونڈوز کی مقامی سطح پر ایپلی کیشن کو چلانا کافی ممکن ہے۔ اس کے بعد، Innopolis یونیورسٹی کے لوگ اور میں ایک ایسی سروس بنانا جاری رکھیں گے جو ڈرائیور کے ساتھ بات چیت کا عمل ہمارے پروجیکٹ کے پچھلے ورژن کی نسبت بہت پہلے شروع کرے گی۔ اور win32 شیل کی آمد کے ساتھ، کنٹرول کو ایک مکمل سروس میں منتقل کرنا منطقی ہو گا جو پہلے ہی تیار ہو چکی ہے (اس پر مزید یہاں).

اگلے مضمون میں ہم ایکٹو ریسٹور سروس کے ایک اور جزو یعنی UEFI ڈرائیور پر بات کریں گے۔ ہمارے بلاگ کو سبسکرائب کریں تاکہ آپ اگلی پوسٹ سے محروم نہ ہوں۔

ماخذ: www.habr.com

ونڈوز مقامی ایپلی کیشنز اور ایکرونس ایکٹو ریسٹور سروس

ویسے بھی مقامی ایپ کیا ہے؟

ہمیں کیا ضرورت ہے؟

کوڈ میں کیا ہے؟

تالیف اور اسمبلی

مقامی ایپلیکیشن کیسے شروع کی جائے؟

کل

نیا تبصرہ شامل کریں جواب منسوخ کریں