پرو هوسٽر > بلاگ > انتظاميه > Windows Native Applications and Acronis Active Restore سروس

Windows Native Applications and Acronis Active Restore سروس

اڄ اسان ان ڪهاڻي کي جاري رکون ٿا ته ڪيئن اسان، Innopolis University جي ساٿين سان گڏ، Active Restore ٽيڪنالاجي کي ترقي ڪري رهيا آهيون ته جيئن صارف ناڪامي کان پوءِ جلد کان جلد پنهنجي مشين تي ڪم شروع ڪري سگهي. اسان ڏيهي ونڊوز ايپليڪيشنن جي باري ۾ ڳالهائينداسين، بشمول انهن جي تخليق ۽ لانچ جون خاصيتون. هيٺ ڏنل ڪٽ اسان جي پروجيڪٽ بابت ٿورڙو آهي، انهي سان گڏ هڪ عملي گائيڊ انهي تي آهي ته ڪيئن مقامي ايپليڪيشنون لکڻيون.

Windows Native Applications and Acronis Active Restore سروس

پوئين پوسٽن ۾ اسان اڳ ۾ ئي ڳالهايو آهي ته اهو ڇا آهي فعال بحالي، ۽ ڪيئن انوپوليس جا شاگرد ترقي ڪن ٿا خدمت. اڄ آئون مقامي ايپليڪيشنن تي ڌيان ڏيڻ چاهيان ٿو، جنهن جي سطح تي اسان چاهيون ٿا "دفن" اسان جي فعال بحالي سروس. جيڪڏهن سڀ ڪجهه ڪم ڪري ٿو، پوء اسان قابل ٿي سگهنداسين:

  • سروس پاڻ کي تمام گهڻو اڳ شروع ڪريو
  • بادل سان رابطو ڪريو جتي بيڪ اپ تمام گهڻو اڳ واقع آهي
  • گهڻو اڳ سمجھڻ لاءِ ته سسٽم ڪهڙي موڊ ۾ آهي - عام بوٽ يا بحالي
  • اڳ ۾ حاصل ڪرڻ لاء تمام گهٽ فائلون
  • استعمال ڪندڙ کي اڃا به تيز شروع ڪرڻ جي اجازت ڏيو.

ڪنهن به صورت ۾ هڪ اصلي ايپ ڇا آهي؟

هن سوال جو جواب ڏيڻ لاء، اچو ته ڪالن جي ترتيب کي ڏسو ته سسٽم ٺاهي ٿو، مثال طور، جيڪڏهن هڪ پروگرامر پنهنجي ايپليڪيشن ۾ فائل ٺاهڻ جي ڪوشش ڪري ٿو.

Windows Native Applications and Acronis Active Restore سروس
Pavel Yosifovich - ونڊوز ڪنيل پروگرامنگ (2019)

پروگرامر فنڪشن استعمال ڪري ٿو ٺاھيو فائل، جنهن کي هيڊر فائل fileapi.h ۾ اعلان ڪيو ويو آهي ۽ Kernel32.dll ۾ لاڳو ڪيو ويو آهي. بهرحال، هي فنڪشن پاڻ کي فائل نٿو ٺاهي، اهو صرف ان پٽ دليلن کي چيڪ ڪري ٿو ۽ فنڪشن کي سڏي ٿو NtCreateFile (پريفڪس Nt صرف اشارو ڪري ٿو ته فنڪشن اصلي آهي). هي فنڪشن winternl.h هيڊر فائل ۾ اعلان ڪيو ويو آهي ۽ ntdll.dll ۾ لاڳو ڪيو ويو آهي. اهو ايٽمي خلا ۾ ٽپو ڏيڻ جي تياري ڪري ٿو، جنهن کان پوء اهو هڪ فائيل ٺاهڻ لاء سسٽم ڪال ڪري ٿو. انهي حالت ۾، اهو ظاهر ٿئي ٿو ته Kernel32 صرف Ntdll لاء هڪ لفافي آهي. ان جو هڪ سبب اهو ڪيو ويو آهي ته Microsoft اهڙيءَ طرح ملڪي دنيا جي افعال کي تبديل ڪرڻ جي صلاحيت رکي ٿو، پر معياري انٽرفيس کي هٿ نه ٿو ڏئي. Microsoft سڌو سنئون فنڪشن کي ڪال ڪرڻ جي سفارش نٿو ڪري ۽ انهن مان گھڻا دستاويز نٿو ڪري. رستي جي ذريعي، غير دستاويزي افعال ملي سگھن ٿا هتي.

اصلي ايپليڪيشنن جو بنيادي فائدو اهو آهي ته ntdll kernel32 کان گهڻو اڳ سسٽم ۾ لوڊ ڪيو ويو آهي. اهو منطقي آهي، ڇاڪاڻ ته kernel32 کي ڪم ڪرڻ لاءِ ntdll جي ضرورت آهي. نتيجي طور، ايپليڪيشنون جيڪي استعمال ڪن ٿيون اصلي فنڪشن گهڻو اڳ ڪم ڪرڻ شروع ڪري سگھن ٿيون.

اهڙيءَ طرح، Windows Native Applications اهي پروگرام آهن جيڪي شروع ڪري سگهن ٿيون ونڊوز بوٽ ۾. اهي صرف ntdll کان فنڪشن استعمال ڪندا آهن. اهڙي درخواست جو هڪ مثال: خودڪار جيڪو انجام ڏئي ٿو chkdisk افاديت مکيه خدمتون شروع ڪرڻ کان اڳ غلطين لاء ڊسڪ چيڪ ڪرڻ لاء. اها بلڪل اها سطح آهي جيڪا اسان چاهيون ٿا ته اسان جي فعال بحالي ٿيڻ گهرجي.

اسان کي ڇا آهي؟

  • ڊي ڊي (ڊرائيور ڊولپمينٽ کٽ)، هاڻي WDK 7 (ونڊوز ڊرائيور کٽ) جي نالي سان پڻ مشهور آهي.
  • ورچوئل مشين (مثال طور، ونڊوز 7 x64)
  • ضروري ناهي، پر هيڊر فائلون جيڪي ڊائون لوڊ ڪري سگھجن ٿيون مدد ڪري سگھن ٿيون هتي

ڪوڊ ۾ ڇا آهي؟

اچو ته ٿورو مشق ڪريون، مثال طور، هڪ ننڍڙي ايپليڪيشن لکو ته:

  1. اسڪرين تي پيغام ڏيکاري ٿو
  2. ڪجهه ياداشت مختص ڪري ٿو
  3. ڪيبورڊ ان پٽ جي انتظار ۾
  4. استعمال ٿيل ياداشت کي آزاد ڪري ٿو

مقامي ايپليڪيشنن ۾، داخلا پوائنٽ مکيه يا winmain نه آهي، پر 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 فنڪشن ناهي (ان کي رن ٽائم سي لائبريرين جي ضرورت آهي). يقينا، توهان صرف هڪ اسٽيڪ استعمال ڪري سگهو ٿا. پر جيڪڏهن اسان کي متحرڪ طور تي ميموري مختص ڪرڻ جي ضرورت آهي، اسان کي اهو ڪرڻو پوندو ڍير تي (يعني هيپ). سو اچو ته پنهنجي لاءِ هڪ ڍير ٺاهيون ۽ جڏهن به ضرورت هجي ان مان يادگيري وٺون.

فنڪشن هن ڪم لاء مناسب آهي 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 ڍانچي جو اعلان ڪنداسين، جيڪو ڪيبورڊ ڊيٽا جي نمائندگي ڪري ٿو. اهو اسان جي ڪم کي آسان بڻائي ڇڏيندو.

اصلي ايپليڪيشن هڪ فنڪشن ڪال سان ختم ٿئي ٿي NtTerminate پروسيسڇاڪاڻ ته اسان صرف پنهنجي عمل کي ماري رهيا آهيون.

اسان جي ننڍڙي ايپليڪيشن لاء سڀ ڪوڊ:

#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);
}

پي اسان آساني سان استعمال ڪري سگھون ٿا DbgBreakPoint() فنڪشن اسان جي ڪوڊ ۾ ان کي ڊيبگر ۾ روڪڻ لاءِ. سچ، توهان کي ڪنيبل ڊيبگنگ لاءِ WinDbg کي ورچوئل مشين سان ڳنڍڻ جي ضرورت پوندي. اهو ڪيئن ڪجي تي هدايتون ملي سگهن ٿيون هتي يا صرف استعمال ڪريو ورچوئل ڪي ڊي.

تاليف ۽ اسيمبلي

هڪ مقامي ايپليڪيشن ٺاهڻ جو آسان طريقو استعمال ڪرڻ آهي ڊي ڊي (ڊرائيور ڊولپمينٽ کٽ). اسان کي قديم ستين ورزن جي ضرورت آهي، ڇاڪاڻ ته بعد ۾ ورزن ۾ ٿورو مختلف طريقو آهي ۽ ويزوئل اسٽوڊيو سان ويجهي ڪم ڪري ٿو. جيڪڏهن اسان DDK استعمال ڪريون ٿا، پوء اسان جي پروجيڪٽ کي صرف 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

توهان جو ميڪ فائل بلڪل ساڳيو هوندو، پر اچو ته ذريعن کي ٿورو وڌيڪ تفصيل سان ڏسو. هي فائل توهان جي پروگرام جا ذريعا بيان ڪري ٿي (سي فائلون)، اختيارن جي تعمير، ۽ ٻيا پيرا ميٽر.

  • TARGETNAME - قابل عمل فائل جو نالو جيڪو آخر ۾ پيدا ڪيو وڃي.
  • TARGETTYPE - executable فائل جو قسم، اهو ڊرائيور (.sys) ٿي سگهي ٿو، پوءِ فيلڊ جي قيمت DRIVER هجڻ گهرجي، جيڪڏهن لائبريري (.lib)، ته پوءِ قيمت لائبريري آهي. اسان جي حالت ۾، اسان کي هڪ قابل عمل فائل (.exe) جي ضرورت آهي، تنهنڪري اسان پروگرام کي قيمت مقرر ڪيو.
  • UMTYPE - هن فيلڊ لاءِ ممڪن قدر: ڪنسول ايپليڪيشن لاءِ ڪنسول، ونڊوز موڊ ۾ ڪم ڪرڻ لاءِ ونڊوز. پر اسان کي وضاحت ڪرڻ جي ضرورت آهي nt هڪ ڏيهي ايپليڪيشن حاصل ڪرڻ لاء.
  • BUFFER_OVERFLOW_CHECKS - بفر اوور فلو لاءِ اسٽيڪ چيڪ ڪرڻ، بدقسمتي سان اسان جو معاملو ناهي، اسان ان کي بند ڪري ڇڏيون ٿا.
  • MINWIN_SDK_LIB_PATH - هي قدر SDK_LIB_PATH متغير ڏانهن اشارو ڪري ٿو، پريشان نه ڪريو ته توهان وٽ اهڙو سسٽم متغير اعلان نه ڪيو ويو آهي، جڏهن اسان DDK مان چيڪ ٿيل بلڊ هلائيندا آهيون، اهو متغير اعلان ڪيو ويندو ۽ ضروري لائبريري ڏانهن اشارو ڪيو ويندو.
  • ذريعا - توهان جي پروگرام لاءِ ذريعن جي هڪ فهرست.
  • شامل آهن - هيڊر فائلون جيڪي اسيمبليءَ لاءِ گهربل آهن. هتي اهي عام طور تي ظاهر ڪن ٿا فائلن ڏانهن رستو جيڪي DDK سان گڏ ايندا آهن، پر توهان اضافي طور تي وضاحت ڪري سگهو ٿا ڪنهن ٻئي کي.
  • TARGETLIBS - لائبريرين جي فهرست جنهن کي ڳنڍڻ جي ضرورت آهي.
  • USE_NTDLL ھڪڙو گھربل فيلڊ آھي جيڪو 1 تي مقرر ڪيو وڃي واضح سببن لاء.
  • USER_C_FLAGS - ڪو به جھنڊو جيڪي توھان استعمال ڪري سگھو ٿا پري پروسيسر جي هدايتن ۾ جڏھن ايپليڪيشن ڪوڊ تيار ڪرڻ.

تنهنڪري تعمير ڪرڻ لاء، اسان کي هلائڻ جي ضرورت آهي x86 (يا x64) چيڪ ٿيل تعمير، ڪم ڪندڙ ڊاريڪٽري کي پروجيڪٽ فولڊر ۾ تبديل ڪريو ۽ بلڊ ڪمانڊ کي هلائڻو پوندو. اسڪرين شاٽ ۾ نتيجو ڏيکاري ٿو ته اسان وٽ ھڪڙو قابل عمل فائل آھي.

Windows Native Applications and Acronis Active Restore سروس

هي فائل ايتري آساني سان لانچ نه ٿي ڪري سگھجي، سسٽم لعنت ڪري ٿو ۽ اسان کي موڪلي ٿو ان جي رويي بابت هيٺين غلطي سان سوچڻ لاءِ:

Windows Native Applications and Acronis Active Restore سروس

هڪ مقامي ايپليڪيشن ڪيئن شروع ڪجي؟

جڏهن آٽوچڪ شروع ٿئي ٿي، پروگرامن جي شروعاتي ترتيب کي رجسٽري ڪيچ جي قيمت سان طئي ڪيو ويندو آهي: 

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

عنوان کي تبديل ڪرڻ لاء، توهان هڪ آن لائن خدمت استعمال ڪري سگهو ٿا، مثال طور، هي.

Windows Native Applications and Acronis Active Restore سروس
اهو ظاهر ٿئي ٿو ته هڪ مقامي ايپليڪيشن شروع ڪرڻ لاء، اسان کي ضرورت آهي:

  1. سسٽم 32 فولڊر ۾ قابل عمل فائل کي نقل ڪريو
  2. رجسٽري ۾ ڪيچ شامل ڪريو
  3. مشين کي ريبوٽ ڪريو

سھولت لاءِ، ھتي آھي ھڪ تيار ٿيل اسڪرپٽ ھڪ اصلي ايپليڪيشن کي انسٽال ڪرڻ لاءِ:

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

انسٽاليشن ۽ ريبوٽ کان پوء، جيتوڻيڪ صارف جي چونڊ اسڪرين کي ظاهر ٿيڻ کان اڳ، اسان کي هيٺ ڏنل تصوير ملندي:

Windows Native Applications and Acronis Active Restore سروس

نتيجو

اهڙي ننڍڙي ايپليڪيشن جي مثال کي استعمال ڪندي، اسان کي يقين ڏياريو ويو ته ونڊوز جي مقامي سطح تي ايپليڪيشن کي هلائڻ بلڪل ممڪن آهي. اڳيون، انوپوليس يونيورسٽي جا ماڻهو ۽ مان هڪ خدمت ٺاهيندا رهنداسين جيڪا اسان جي منصوبي جي پوئين ورزن جي ڀيٽ ۾ ڊرائيور سان رابطي جي عمل کي شروع ڪندي. ۽ Win32 شيل جي اچڻ سان، اهو منطقي هوندو ته ڪنٽرول کي هڪ مڪمل خدمت تي منتقل ڪرڻ لاء جيڪو اڳ ۾ ئي ترقي ڪئي وئي آهي (وڌيڪ هن تي هتي).

ايندڙ آرٽيڪل ۾ اسان هڪ ٻئي جزو تي رابطو ڪنداسين فعال بحالي سروس، يعني UEFI ڊرائيور. اسان جي بلاگ تي رڪنيت حاصل ڪريو ته جيئن توهان ايندڙ پوسٽ کي نه وڃايو.

جو ذريعو: www.habr.com

تبصرو شامل ڪريو