WinAPI calling code at specific timestamp

Using functions available in the WinAPI, is it possible to ensure that a specific function is called according to a milisecond precise timestamp? And if so what would be the correct implementation?

I'm trying to write tool assisted speedrun software. This type of software sends user input commands at very exact moments after the script is launched to perform humanly impossible inputs that allow faster completion of videogames. A typical sequence looks something like this:

At 0 miliseconds send right key down event

At 5450 miliseconds send right key up, and up key down event

At 5460 miliseconds send left key down event

etc..

What I've tried so far is listed below. As I'm not experienced in the low level nuances of high precision timers I have some results, but no understanding of why they are this way:

Using Sleep in combination with timeBeginPeriod set to 1 between inputs gave the worst results. Out of 20 executions 0 have met the timing requirement. I believe this is well explained in the documentation for sleep Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. My understanding is that Sleep isn't up for this task.

Using a busy wait loop checking GetTickCount64 with timeBeginPeriod set to 1 produced slightly better results. Out of 20 executions 2 have met the timing requirement, but apparently that was just a fortunate circumstance. I've looked up some info on this timing function and my suspicion is that it doesn't update often enough to allow 1 milisecond accuracy.

Replacing the GetTickCount64 with the QueryPerformanceCounter improved the situation slightly. Out of 20 executions 8 succeded. I wrote a logger that would store the QPC timestamps right before each input is sent and dump the values in a file after the sequence is finished. I even went as far as to preallocate space for all variables in my code to make sure that time isn't wasted on needless explicit memory allocations. The log values diverge from the timestamps I supply the program by anything from 1 to 40 miliseconds. General purpose programming can live with that, but in my case a single frame of the game is 16.7 ms, so in the worst possible case with delays like these I can be 3 frames late, which defeats the purpose of the whole experiment.

Setting the process priority to high didn't make any difference.

At this point I'm not sure where to look next. My two guesses are that maybe the time that it takes to iterate the busy loop and check the time using (QPCNow - QPCStart) / QPF is itself somehow long enough to introduce the mentioned delay, or that the process is interrupted by the OS scheduler somwhere along the execution of the loop and control returns too late.

The game is 100% deterministic and locked at 60 fps. I am convinced that if I manage to make the input be timed accurately the result will always be 20 out of 20, but at this point I'm begining to suspect that this may not be possible.

EDIT: As per request here is a stripped down testing version. Breakpoint after the second call to ExecuteAtTime and view the TimeBeforeInput variables. For me it reads 1029 and 6017(I've omitted the decimals) meaning that the code executed 29 and 17 miliseconds after it should have.
Disclaimer: the code is not written to demonstrate good programming practices.

#include "stdafx.h"

#include <windows.h>



__int64 g_TimeStart = 0;

double g_Frequency = 0.0;



double g_TimeBeforeFirstInput = 0.0;

double g_TimeBeforeSecondInput = 0.0;



double GetMSSinceStart(double& debugOutput)

{

    LARGE_INTEGER now;

    QueryPerformanceCounter(&now);

    debugOutput = double(now.QuadPart - g_TimeStart) / g_Frequency;

    return debugOutput;

}



void ExecuteAtTime(double ms, INPUT* keys, double& debugOutput)

{

    while(GetMSSinceStart(debugOutput) < ms)

    {



    }

    SendInput(2, keys, sizeof(INPUT));

}



INPUT* InitKeys()

{

    INPUT* result = new INPUT[2];

    ZeroMemory(result, 2*sizeof(INPUT));



    INPUT winKey;

    winKey.type = INPUT_KEYBOARD;

    winKey.ki.wScan = 0;

    winKey.ki.time = 0;

    winKey.ki.dwExtraInfo = 0;

    winKey.ki.wVk = VK_LWIN;

    winKey.ki.dwFlags = 0;

    result[0] = winKey;



    winKey.ki.dwFlags = KEYEVENTF_KEYUP;

    result[1] = winKey;



    return result;

}



int _tmain(int argc, _TCHAR* argv)

{

    INPUT* keys = InitKeys();



    LARGE_INTEGER qpf;

    QueryPerformanceFrequency(&qpf);

    g_Frequency = double(qpf.QuadPart) / 1000.0;



    LARGE_INTEGER qpcStart;

    QueryPerformanceCounter(&qpcStart);

    g_TimeStart = qpcStart.QuadPart;



    //Opens windows start panel one second after launch

    ExecuteAtTime(1000.0, keys, g_TimeBeforeFirstInput);



    //Closes windows start panel 5 seconds later

    ExecuteAtTime(6000.0, keys, g_TimeBeforeSecondInput);

    delete keys;



    Sleep(1000);

    return 0;

}

edited Nov 20 '18 at 10:29

asked Nov 20 '18 at 8:11

BMC

235

QPC is as precise as time measurement can get on Windows platform and certainly precise enough for your use case. My guess is that you are using SendInput incorrectly (e. g. multiple calls instead of single call for "right key up, and up key down"). A Minimal, Complete, and Verifiable example would go a long way. Anyway, I don't think you will get to 100% success, because Windows is not a realtime OS.

– zett42
Nov 20 '18 at 9:03

Maybe CreateWaitableTImer() ?

– Jonathan Potter
Nov 20 '18 at 9:24

2

Only ring 0 code (device drivers) can have the service guarantee you are demanding. That is not a problem you should ever solve yourself, for a game that kind of timing is already built into the api. The standard technique is to use page flipping at the monitor's vsync signal. In other words, not hard-code the frame rate. Introductory reading could start here.

– Hans Passant
Nov 20 '18 at 10:34

@HansPassant how can I hook into the vsync event of another process(the game that is being speedrun)?

– BMC
Nov 20 '18 at 10:43

1

As soon as you "hook" you'll lose the benefit of this being done in ring 0 code that can run at interrupt priority. It is not clear why you'd want to hook. Look at timeSetEvent() next, but beware that its callback runs on an arbitrary threadpool thread.

– Hans Passant
Nov 20 '18 at 10:47

|
show 1 more comment

Using functions available in the WinAPI, is it possible to ensure that a specific function is called according to a milisecond precise timestamp? And if so what would be the correct implementation?

At 0 miliseconds send right key down event

At 5450 miliseconds send right key up, and up key down event

At 5460 miliseconds send left key down event

etc..

What I've tried so far is listed below. As I'm not experienced in the low level nuances of high precision timers I have some results, but no understanding of why they are this way:

Using Sleep in combination with timeBeginPeriod set to 1 between inputs gave the worst results. Out of 20 executions 0 have met the timing requirement. I believe this is well explained in the documentation for sleep Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. My understanding is that Sleep isn't up for this task.

Using a busy wait loop checking GetTickCount64 with timeBeginPeriod set to 1 produced slightly better results. Out of 20 executions 2 have met the timing requirement, but apparently that was just a fortunate circumstance. I've looked up some info on this timing function and my suspicion is that it doesn't update often enough to allow 1 milisecond accuracy.

Replacing the GetTickCount64 with the QueryPerformanceCounter improved the situation slightly. Out of 20 executions 8 succeded. I wrote a logger that would store the QPC timestamps right before each input is sent and dump the values in a file after the sequence is finished. I even went as far as to preallocate space for all variables in my code to make sure that time isn't wasted on needless explicit memory allocations. The log values diverge from the timestamps I supply the program by anything from 1 to 40 miliseconds. General purpose programming can live with that, but in my case a single frame of the game is 16.7 ms, so in the worst possible case with delays like these I can be 3 frames late, which defeats the purpose of the whole experiment.

Setting the process priority to high didn't make any difference.

#include "stdafx.h"

#include <windows.h>



__int64 g_TimeStart = 0;

double g_Frequency = 0.0;



double g_TimeBeforeFirstInput = 0.0;

double g_TimeBeforeSecondInput = 0.0;



double GetMSSinceStart(double& debugOutput)

{

    LARGE_INTEGER now;

    QueryPerformanceCounter(&now);

    debugOutput = double(now.QuadPart - g_TimeStart) / g_Frequency;

    return debugOutput;

}



void ExecuteAtTime(double ms, INPUT* keys, double& debugOutput)

{

    while(GetMSSinceStart(debugOutput) < ms)

    {



    }

    SendInput(2, keys, sizeof(INPUT));

}



INPUT* InitKeys()

{

    INPUT* result = new INPUT[2];

    ZeroMemory(result, 2*sizeof(INPUT));



    INPUT winKey;

    winKey.type = INPUT_KEYBOARD;

    winKey.ki.wScan = 0;

    winKey.ki.time = 0;

    winKey.ki.dwExtraInfo = 0;

    winKey.ki.wVk = VK_LWIN;

    winKey.ki.dwFlags = 0;

    result[0] = winKey;



    winKey.ki.dwFlags = KEYEVENTF_KEYUP;

    result[1] = winKey;



    return result;

}



int _tmain(int argc, _TCHAR* argv)

{

    INPUT* keys = InitKeys();



    LARGE_INTEGER qpf;

    QueryPerformanceFrequency(&qpf);

    g_Frequency = double(qpf.QuadPart) / 1000.0;



    LARGE_INTEGER qpcStart;

    QueryPerformanceCounter(&qpcStart);

    g_TimeStart = qpcStart.QuadPart;



    //Opens windows start panel one second after launch

    ExecuteAtTime(1000.0, keys, g_TimeBeforeFirstInput);



    //Closes windows start panel 5 seconds later

    ExecuteAtTime(6000.0, keys, g_TimeBeforeSecondInput);

    delete keys;



    Sleep(1000);

    return 0;

}

edited Nov 20 '18 at 10:29

asked Nov 20 '18 at 8:11

BMC

235

QPC is as precise as time measurement can get on Windows platform and certainly precise enough for your use case. My guess is that you are using SendInput incorrectly (e. g. multiple calls instead of single call for "right key up, and up key down"). A Minimal, Complete, and Verifiable example would go a long way. Anyway, I don't think you will get to 100% success, because Windows is not a realtime OS.

– zett42
Nov 20 '18 at 9:03

Maybe CreateWaitableTImer() ?

– Jonathan Potter
Nov 20 '18 at 9:24

2

Only ring 0 code (device drivers) can have the service guarantee you are demanding. That is not a problem you should ever solve yourself, for a game that kind of timing is already built into the api. The standard technique is to use page flipping at the monitor's vsync signal. In other words, not hard-code the frame rate. Introductory reading could start here.

– Hans Passant
Nov 20 '18 at 10:34

@HansPassant how can I hook into the vsync event of another process(the game that is being speedrun)?

– BMC
Nov 20 '18 at 10:43

1

As soon as you "hook" you'll lose the benefit of this being done in ring 0 code that can run at interrupt priority. It is not clear why you'd want to hook. Look at timeSetEvent() next, but beware that its callback runs on an arbitrary threadpool thread.

– Hans Passant
Nov 20 '18 at 10:47

|
show 1 more comment

Using functions available in the WinAPI, is it possible to ensure that a specific function is called according to a milisecond precise timestamp? And if so what would be the correct implementation?

At 0 miliseconds send right key down event

At 5450 miliseconds send right key up, and up key down event

At 5460 miliseconds send left key down event

etc..

What I've tried so far is listed below. As I'm not experienced in the low level nuances of high precision timers I have some results, but no understanding of why they are this way:

Using Sleep in combination with timeBeginPeriod set to 1 between inputs gave the worst results. Out of 20 executions 0 have met the timing requirement. I believe this is well explained in the documentation for sleep Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. My understanding is that Sleep isn't up for this task.

Using a busy wait loop checking GetTickCount64 with timeBeginPeriod set to 1 produced slightly better results. Out of 20 executions 2 have met the timing requirement, but apparently that was just a fortunate circumstance. I've looked up some info on this timing function and my suspicion is that it doesn't update often enough to allow 1 milisecond accuracy.

Replacing the GetTickCount64 with the QueryPerformanceCounter improved the situation slightly. Out of 20 executions 8 succeded. I wrote a logger that would store the QPC timestamps right before each input is sent and dump the values in a file after the sequence is finished. I even went as far as to preallocate space for all variables in my code to make sure that time isn't wasted on needless explicit memory allocations. The log values diverge from the timestamps I supply the program by anything from 1 to 40 miliseconds. General purpose programming can live with that, but in my case a single frame of the game is 16.7 ms, so in the worst possible case with delays like these I can be 3 frames late, which defeats the purpose of the whole experiment.

Setting the process priority to high didn't make any difference.

#include "stdafx.h"

#include <windows.h>



__int64 g_TimeStart = 0;

double g_Frequency = 0.0;



double g_TimeBeforeFirstInput = 0.0;

double g_TimeBeforeSecondInput = 0.0;



double GetMSSinceStart(double& debugOutput)

{

    LARGE_INTEGER now;

    QueryPerformanceCounter(&now);

    debugOutput = double(now.QuadPart - g_TimeStart) / g_Frequency;

    return debugOutput;

}



void ExecuteAtTime(double ms, INPUT* keys, double& debugOutput)

{

    while(GetMSSinceStart(debugOutput) < ms)

    {



    }

    SendInput(2, keys, sizeof(INPUT));

}



INPUT* InitKeys()

{

    INPUT* result = new INPUT[2];

    ZeroMemory(result, 2*sizeof(INPUT));



    INPUT winKey;

    winKey.type = INPUT_KEYBOARD;

    winKey.ki.wScan = 0;

    winKey.ki.time = 0;

    winKey.ki.dwExtraInfo = 0;

    winKey.ki.wVk = VK_LWIN;

    winKey.ki.dwFlags = 0;

    result[0] = winKey;



    winKey.ki.dwFlags = KEYEVENTF_KEYUP;

    result[1] = winKey;



    return result;

}



int _tmain(int argc, _TCHAR* argv)

{

    INPUT* keys = InitKeys();



    LARGE_INTEGER qpf;

    QueryPerformanceFrequency(&qpf);

    g_Frequency = double(qpf.QuadPart) / 1000.0;



    LARGE_INTEGER qpcStart;

    QueryPerformanceCounter(&qpcStart);

    g_TimeStart = qpcStart.QuadPart;



    //Opens windows start panel one second after launch

    ExecuteAtTime(1000.0, keys, g_TimeBeforeFirstInput);



    //Closes windows start panel 5 seconds later

    ExecuteAtTime(6000.0, keys, g_TimeBeforeSecondInput);

    delete keys;



    Sleep(1000);

    return 0;

}

edited Nov 20 '18 at 10:29

asked Nov 20 '18 at 8:11

BMC

235

Using functions available in the WinAPI, is it possible to ensure that a specific function is called according to a milisecond precise timestamp? And if so what would be the correct implementation?

At 0 miliseconds send right key down event

At 5450 miliseconds send right key up, and up key down event

At 5460 miliseconds send left key down event

etc..

What I've tried so far is listed below. As I'm not experienced in the low level nuances of high precision timers I have some results, but no understanding of why they are this way:

Using Sleep in combination with timeBeginPeriod set to 1 between inputs gave the worst results. Out of 20 executions 0 have met the timing requirement. I believe this is well explained in the documentation for sleep Note that a ready thread is not guaranteed to run immediately. Consequently, the thread may not run until some time after the sleep interval elapses. My understanding is that Sleep isn't up for this task.

Using a busy wait loop checking GetTickCount64 with timeBeginPeriod set to 1 produced slightly better results. Out of 20 executions 2 have met the timing requirement, but apparently that was just a fortunate circumstance. I've looked up some info on this timing function and my suspicion is that it doesn't update often enough to allow 1 milisecond accuracy.

Replacing the GetTickCount64 with the QueryPerformanceCounter improved the situation slightly. Out of 20 executions 8 succeded. I wrote a logger that would store the QPC timestamps right before each input is sent and dump the values in a file after the sequence is finished. I even went as far as to preallocate space for all variables in my code to make sure that time isn't wasted on needless explicit memory allocations. The log values diverge from the timestamps I supply the program by anything from 1 to 40 miliseconds. General purpose programming can live with that, but in my case a single frame of the game is 16.7 ms, so in the worst possible case with delays like these I can be 3 frames late, which defeats the purpose of the whole experiment.

Setting the process priority to high didn't make any difference.

#include "stdafx.h"

#include <windows.h>



__int64 g_TimeStart = 0;

double g_Frequency = 0.0;



double g_TimeBeforeFirstInput = 0.0;

double g_TimeBeforeSecondInput = 0.0;



double GetMSSinceStart(double& debugOutput)

{

    LARGE_INTEGER now;

    QueryPerformanceCounter(&now);

    debugOutput = double(now.QuadPart - g_TimeStart) / g_Frequency;

    return debugOutput;

}



void ExecuteAtTime(double ms, INPUT* keys, double& debugOutput)

{

    while(GetMSSinceStart(debugOutput) < ms)

    {



    }

    SendInput(2, keys, sizeof(INPUT));

}



INPUT* InitKeys()

{

    INPUT* result = new INPUT[2];

    ZeroMemory(result, 2*sizeof(INPUT));



    INPUT winKey;

    winKey.type = INPUT_KEYBOARD;

    winKey.ki.wScan = 0;

    winKey.ki.time = 0;

    winKey.ki.dwExtraInfo = 0;

    winKey.ki.wVk = VK_LWIN;

    winKey.ki.dwFlags = 0;

    result[0] = winKey;



    winKey.ki.dwFlags = KEYEVENTF_KEYUP;

    result[1] = winKey;



    return result;

}



int _tmain(int argc, _TCHAR* argv)

{

    INPUT* keys = InitKeys();



    LARGE_INTEGER qpf;

    QueryPerformanceFrequency(&qpf);

    g_Frequency = double(qpf.QuadPart) / 1000.0;



    LARGE_INTEGER qpcStart;

    QueryPerformanceCounter(&qpcStart);

    g_TimeStart = qpcStart.QuadPart;



    //Opens windows start panel one second after launch

    ExecuteAtTime(1000.0, keys, g_TimeBeforeFirstInput);



    //Closes windows start panel 5 seconds later

    ExecuteAtTime(6000.0, keys, g_TimeBeforeSecondInput);

    delete keys;



    Sleep(1000);

    return 0;

}

c++ windows winapi

edited Nov 20 '18 at 10:29

asked Nov 20 '18 at 8:11

BMC

235

edited Nov 20 '18 at 10:29

asked Nov 20 '18 at 8:11

BMC

235

edited Nov 20 '18 at 10:29

asked Nov 20 '18 at 8:11

BMC

235

asked Nov 20 '18 at 8:11

BMC

235

asked Nov 20 '18 at 8:11

BMC

235

QPC is as precise as time measurement can get on Windows platform and certainly precise enough for your use case. My guess is that you are using SendInput incorrectly (e. g. multiple calls instead of single call for "right key up, and up key down"). A Minimal, Complete, and Verifiable example would go a long way. Anyway, I don't think you will get to 100% success, because Windows is not a realtime OS.

– zett42
Nov 20 '18 at 9:03

Maybe CreateWaitableTImer() ?

– Jonathan Potter
Nov 20 '18 at 9:24

2

Only ring 0 code (device drivers) can have the service guarantee you are demanding. That is not a problem you should ever solve yourself, for a game that kind of timing is already built into the api. The standard technique is to use page flipping at the monitor's vsync signal. In other words, not hard-code the frame rate. Introductory reading could start here.

– Hans Passant
Nov 20 '18 at 10:34

@HansPassant how can I hook into the vsync event of another process(the game that is being speedrun)?

– BMC
Nov 20 '18 at 10:43

1

As soon as you "hook" you'll lose the benefit of this being done in ring 0 code that can run at interrupt priority. It is not clear why you'd want to hook. Look at timeSetEvent() next, but beware that its callback runs on an arbitrary threadpool thread.

– Hans Passant
Nov 20 '18 at 10:47

|
show 1 more comment

QPC is as precise as time measurement can get on Windows platform and certainly precise enough for your use case. My guess is that you are using SendInput incorrectly (e. g. multiple calls instead of single call for "right key up, and up key down"). A Minimal, Complete, and Verifiable example would go a long way. Anyway, I don't think you will get to 100% success, because Windows is not a realtime OS.

– zett42
Nov 20 '18 at 9:03

Maybe CreateWaitableTImer() ?

– Jonathan Potter
Nov 20 '18 at 9:24

2

Only ring 0 code (device drivers) can have the service guarantee you are demanding. That is not a problem you should ever solve yourself, for a game that kind of timing is already built into the api. The standard technique is to use page flipping at the monitor's vsync signal. In other words, not hard-code the frame rate. Introductory reading could start here.

– Hans Passant
Nov 20 '18 at 10:34

@HansPassant how can I hook into the vsync event of another process(the game that is being speedrun)?

– BMC
Nov 20 '18 at 10:43

1

As soon as you "hook" you'll lose the benefit of this being done in ring 0 code that can run at interrupt priority. It is not clear why you'd want to hook. Look at timeSetEvent() next, but beware that its callback runs on an arbitrary threadpool thread.

– Hans Passant
Nov 20 '18 at 10:47

QPC is as precise as time measurement can get on Windows platform and certainly precise enough for your use case. My guess is that you are using SendInput incorrectly (e. g. multiple calls instead of single call for "right key up, and up key down"). A Minimal, Complete, and Verifiable example would go a long way. Anyway, I don't think you will get to 100% success, because Windows is not a realtime OS.

– zett42
Nov 20 '18 at 9:03

Maybe CreateWaitableTImer() ?

– Jonathan Potter
Nov 20 '18 at 9:24

Only ring 0 code (device drivers) can have the service guarantee you are demanding. That is not a problem you should ever solve yourself, for a game that kind of timing is already built into the api. The standard technique is to use page flipping at the monitor's vsync signal. In other words, not hard-code the frame rate. Introductory reading could start here.

– Hans Passant
Nov 20 '18 at 10:34

@HansPassant how can I hook into the vsync event of another process(the game that is being speedrun)?

– BMC
Nov 20 '18 at 10:43

As soon as you "hook" you'll lose the benefit of this being done in ring 0 code that can run at interrupt priority. It is not clear why you'd want to hook. Look at timeSetEvent() next, but beware that its callback runs on an arbitrary threadpool thread.

– Hans Passant
Nov 20 '18 at 10:47

|
show 1 more comment

0

active

oldest

votes

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53388697%2fwinapi-calling-code-at-specific-timestamp%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

0

active

oldest

votes

0

active

oldest

votes

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu