|
I was doing a job for a company and they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code. You want more there is a whole song and dance you must do. It was a complete pain and then they made the mistake of telling me I could use threads and you could request space for the thread ... so I did apply for 1 thread and got given it.
I offer perhaps the funniest use of a thread ever ... in windows the code would look like this
static BOOL ReleaseThread = FALSE;
DWORD WINAPI MyThread (LPVOID lpParam){
char buffer[4096];
*(void**)lpParam = &buffer[0];
do {} while (!ReleaseThread);
return (0);
}
If you haven't worked it out here would be the equivalent windows use of the thread.
char* buf = NULL;
HANDLE myThread = CreateThread(0, 0, MyThread, &buf, 0, NULL);
while (!buf) {};
strcpy_s(buf, 4096, "Hello there stack buffer\r\n");
printf("%s", buf);
ReleaseThread = TRUE;
But the best bit was it passed thru without anyone noticing.
In vino veritas
|
|
|
|
|
leon de boer wrote: But the best bit was it passed thru without anyone noticing.
Sounds like you are a program managers worse nightmare. 
Best Wishes,
-David Delaune
P.S.
Wasn't me that downvoted you.
modified 3-Nov-16 0:04am.
|
|
|
|
|
Haha yeah I would downvote myself 
I figured I would get everything working before dealing with the buffer recycling. It takes a fair bit of work to track what buffers in use and where. What I laughed at was with all the rigor around memory handling I could do it and no-one raised an eyebrow. I mean that is a truely horrible idea.
I will probably recycle one of my memory stream objects and donate it to them because I think the whole manual tracking of buffers is a bit naft and I think just as likely to create program errors as running out of memory.
In vino veritas
|
|
|
|
|
leon de boer wrote: they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code.
There are good reasons for that:
1. In many cases, it is better to discover that you don't have enough memory at program start than to discover it later.
2. In real-time systems, heap management time can be unpredictable. This makes achieving the time guarantees much more difficult.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Sorry that is not correct ... running out of memory can be fatal no matter if you allocated it before hand or ran out of it on the heap. In my case I abused the stack which is just as bad.
I am an embedded programmer and I live with low ram implementations in real time systems for a living, and that was the point of my joke at those who think you can frame protection in a standard or a formula. You can't, you need to frame intent and guidelines not specific implementations. You can not create a "safe" or "perfect" specification because you haven't written the code and you don't know the problems.
That whole approach is like 1960's military code specifications and nightmare movie which failed dismally and nobody really codes that way anymore we all use block based approach.
The first public discussion on the new military standards in software I know of was when Boeing allowed hackers to try and hack a "little bird" unmanned helicopter. If you don't know about this stuff that would be a good start point.
Hacker-Proof Code Confirmed[^]
As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact. There are links in the article to the research language F* (F-STAR) and the Project Everest which is Microsofts play in the area of trying to develop better hack free products.
Most new high reliability stuff will follow down those paths for obvious reasons, they can offer guarantees something every other technique can't do.
In vino veritas
modified 3-Nov-16 9:34am.
|
|
|
|
|
I stand corrected.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
You are party right any system is better than none ... I understood your intent
Our human systems are always flawed but yeah the new HDL synthesis tool stuff is scary good. Worth playing around with if you have the time and it's fun but quite different way of programming and probably not on Visual Studio until 2050 !!!!
In vino veritas
|
|
|
|
|
Hi,
I waited until the thread went beyond the first page to further engage with you.
I can tell you why your employer has this requirement. This is common on mission-critical software.
Exceptions and Stack Unwinding in C++[^]
If you allocate memory on the stack... and a recoverable exception occurs in your thread... the memory is correctly released during stack unwinding.
If you allocate memory on the heap and a recoverable exception occurs in your thread... the memory is not released and now your application potentially has a resource leak.
leon de boer wrote: As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact.
This is not correct. I have met both Bryan Parno[^] and Jeannette Wing[^] and I was present at the 2014 presentation on campus at Redmond.
Yes, small sections of logic can be statistically proven to be secure. It would not be correct to make the claim of "guaranteed to perform error-free, that isn't a claim it's a provable fact"
If I were to assign a confidence level to what they have achieved I would say "High Confidence".
Best Wishes,
-David Delaune
|
|
|
|
|
Hi,
I have been using SendMessage for interprocess communication.
The Sender Is The Parent console C program. The receiver is a MFC Windows program
All of the sudden it stopped working
I am sure that the windows handle is valid as after The MainFrame is created a (running under the VS debugger) I observe the m_hWnd of the Mainframe. it is the same value returned by the FindWindow (to reterive the windows handle)
I orignally a WM_USER + X and later tried RegisterWindowMessage
The MFC message map (ON_MESSAGE) has message either a #define WM_USER + x or UINT returned
from the RegisterWindowMessage and member handling the message is LRESULT Wparam, Lparam
|
|
|
|
|
The issue with SendMessage is that it blocks the calling process until a response is received. Therefore, if something goes wrong in the receiver, the caller tends to hang. So in your situation, my first checks would involve seeing what, if anything, the Mainframe is doing with the message that was sent. Put a breakpoint in the Mainframe's message pump where it catches your registered message, and take it from there. If, by chance, it is not catching your registered message, then there is something amiss with the registration process.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
There is no message pump
(Maybe under the covers)
As it's a message map
I can only break at the handling procedure which isn't reached
|
|
|
|
|
Then that tends to indicate an issue with the message registration. Go back (temporarily) to using a WM_USER message, and if that works, then you'll have to look deeper into the way the RegisterMessage is being called. It's been quite a few years since I've done anything with custom windows message, but I have a vague recollection that there is a "gotcha" in there that got me for a while. Can't remember what it was, though, sorry.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
Hi,
ForNow wrote: I have been using SendMessage for interprocess communication.
When you ask for help you should always mention the operating system.
Read the article section about deadlocks and make sure that you understand the dangers of using SendMessage for IPC. Also note that moving forward... all software engineers are encouraged to use the recommended/supported Microsoft Interprocess Communication mechanisms.
ForNow wrote: and later tried RegisterWindowMessage
Are you checking that the return value of RegisterWindowMessage is not zero? Why did you ask for help but did not give the results of GetLastError()?
I recommend avoiding RegisterWindowMessage. Keep in mind that you can only obtain 16,384 RegisterWindowMessage unique identifiers. After that... there are no more system resources for globally unique messages.
Let's imagine that you are writing software to control an oil refinery system.
Maybe you are writing defense department mission critical software.
Perhaps an airplane requires your Windows component for operation.
Imagine if your writing the radar system for an ship out in the sea.
Maybe in these scenarios the operating system is mission critical and should never go down. In these scenarios it is important to avoid RegisterWindowMessage on these systems. Likewise system builders of mission critical software should perform accounting on all software utilizing RegisterWindowMessage.
ForNow wrote: I orignally a WM_USER + X
Here you chose the wrong message integer range for IPC. Read this:
WM_USER = Used to define private messages for use by private window classes
Some possible solutions:
1.) Re-write your IPC and avoid the window message system.
2.) Check if your window message was filtered-out via UIPI. If so, utilize the ChangeWindowMessageFilterEx function to allow the message through.
3.) Use a hammer.
Hammer:
BOOL YourClass::AttachInput(HWND hwnd, BOOL fAttach)
{
DWORD dwThreadId = GetWindowThreadProcessId(hwnd, NULL);
DWORD dwMyThread = GetCurrentThreadId();
return AttachThreadInput(dwMyThread, dwThreadId, fAttach);
}
I don't recommend using the hammer. Your message was most likely filtered out.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks so much for your reply
I have a couple questions first in order to use the Hammer and mind you I only need to use
SendMessage in the console app ONCE for the LRESULT is the windows handle of the
the modeless dialog box which I will PostMessage from the console app to the windows app
to say data is ready
The Data is in shared storage
I would have to create a message pump via GetMessage,TranslateMessage,DispatchMessage
per yourself
How to post a thread message to a console application[^]
Second What Makes SendMessage with WM_COPYDATA message so special that it is Sanctioned
By MicroSoft
|
|
|
|
|
ForNow wrote: I would have to create a message pump via GetMessage,TranslateMessage,DispatchMessage
Hi,
Calling the PostMessage function exported from user32.dll results in a NtUserPostMessage system call. This alone should be enough to promote the thread to a gui thread via KiConvertToGuiThread. Note that things are changing as security features are being added to the Microsoft Windows platform. You would need to make sure that PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON is not defined. This security feature disables win32k system calls for a process/thread.
ForNow wrote: Second What Makes SendMessage with WM_COPYDATA message so special that it is Sanctioned
By MicroSoft
You are essentially asking:
1.) Why does User Interface Privilege Isolation exist?
2.) Why is the old message model (for inter-process communication) being deprecated ?
Basically the answer is:
For a future with better secure computing platform and secure internet connectivity.
Recent hacking attacks described in the media (i.e. democratic national convention) could have potentially been mitigated by defining PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON on browser/e-mail rendering threads. Essentially a 'system call' attack surface reduction.
Always use a modern up-to-date browser. I recommend Microsoft Edge or Google Chrome.
Chromium Win32k system call lockdown[^]
Security enhancements for Microsoft Edge[^]
Hopefully one day software companies will be required to adhere to an international standard for secure computing. We are still in the wild-west early stages of computing.
Best Wishes,
-David Delaune
|
|
|
|
|
Lets first discuss the general Windows cases. Basic rule never use SendMessage between any windows that you don't directly know the message arrangements use PostMessage instead. The other trap with SendMessage is it is easy to go circular (happens a lot when playing around with scrollbar code ). Make sure the send message handling doesn't send a messsage back to the caller which then sends off another message and around and around it goes.
I also have a scary feeling you have a different thread on the console app given the title Interprocess. If that is true you can not blindly use SendMessage, it crosses a thread boundary and it will deadlock .... Guaranteed if done raw. It is sort of covered in the Microsoft discussion of SendMessage when they talk about the data marshalling and playing around with SendMessageTimeout. The easier solution is just don't use it, PostMessage is there and has no issues. If you need a response back you post back another message so you setup a ping/pong message system using PostMessage, saves a lot of effort and heartache.
In the directory watcher code I did for you that is why I used PostMessage in the thread not SendMessage. Use SendMessage there and it will Deadlock randomly.
PostMessage(watchData->AppWindow, watchData->MsgId, watchData->CmdId, (LPARAM)msgToApp);
Randor in his post is correct if you want to tow the "Microsoft line", so I guess look at is what you are coding a critical system. Historically most have always used WM_USER and I have never seen a clash because there is really only you, Windows and your framework that post messages around inside your application and you can see it in testing and debugging on your machine. This isn't a bug that would suddenly appear in the field or such, it was always more a problem if you had two or more programmers and they both selected the same message number you got some funny things happen. Anyhow if you are going to stick to messages perhaps move up to WM_APP messages (It came in with Windows 95) because that range is designed to do exactly what you are doing and will be one more bit of safety. None of these message ranges go inside/outside your applications so it's only stuff within your application you have to worry about.
AFAIK windows itself puts no messages into the WM_USER range these days because of the data marshal requirements and I believe it has been like that since Win95. Even the classic old ones like LB_ADDSTRING got moved into the standard windows range. LB_ADDSTRING used to be WM_USER + 1 which is why us old timers used to go for WM_USER+100, it was our goto number
For what it's worth having two window elements with the same ID happens a lot more and is just as catastrophic. There is no way to stop it happening except by controlling the allocation of ID numbers to elements. An interesting programming office prank was to get hold of a resource editor and move the ID numbers around on exe which had the resources bound and watch the fun that followed (Borlands whitewater resource kit was so good at it). Some even had the menus in the resource and you could change the menu ID numbers.
In vino veritas
modified 2-Nov-16 10:36am.
|
|
|
|
|
thanks But PostMessage Windows -> console wont work because the console app doesn't have a
message queue. I know the GetMessage,TranslateMessage,DispatchMessage creates one.
Or Rather the GetMessage
I have a question about the Message Structure
Since the console app doesn't a windows the Hwnd is NULL
What about the last parameter of the message structure the Point parameter what would
its value be in the console application
|
|
|
|
|
Okay lets first deal with your misconceptions
Windows console windows do have a window handle it just has a special function to get it because it isn't present by default because you start with main not winmain and main has no position for it on it's parameters which are arguments.
GetConsoleWindow function (Windows)[^]
You can also directly pull the message handler if you want to just provide your own that looks like this
WNDPROC ConsoleWindow = NULL;
static LRESULT CALLBACK MyWndProc(HWND Wnd, UINT Msg, WPARAM wParam, LPARAM lParam) {
if (ConsoleWindow)
return CallWindowProc(ConsoleWindow, Wnd, Msg, wParam, lParam);
return(0);
}
HWND hWnd = GetConsoleWindow();
ConsoleWindow = (WNDPROC)SetWindowLong(hWnd, GWL_WNDPROC, (LONG)MyWndProc);
However since Win95 we tend not to do that anymore because there is a much easier way with a special class called Message-Only Windows. There are even a couple of articles on using them in the code project archives but it's just like any normal window just it has no visible parts.
The 3rd alternative is you make a normal windows program and create a console window from the launch using AllocConsole.
AllocConsole function (Windows)[^]
Lots of science and maths guys do this so they can dump data out onto the console window while running there graphics.
You do not have to have a graphics window however you can simply use the stdin and stdout ... here is the simplest sample. Compile it as a standard windows GUI project.
So again in this sample you have a standard message queue available and a console window.
#include <windows.h>
#include <tchar.h>
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
DWORD charsRead = 0;
TCHAR keyBuffer[100];
AllocConsole();
HANDLE myConsoleHandle = GetStdHandle(STD_OUTPUT_HANDLE);
DWORD cCharsWritten;
TCHAR* str = TEXT("Hello I am the console\r\n");
WriteConsole(myConsoleHandle, str, _tcslen(str), &cCharsWritten, NULL);
HANDLE myConsoleHandleInput = GetStdHandle(STD_INPUT_HANDLE);
ReadConsole(myConsoleHandleInput, keyBuffer, _countof(keyBuffer), &charsRead, NULL);
str = TEXT("Okay lets mix it up with messages and console .. any key to exit\r\n");
WriteConsole(myConsoleHandle, str, _tcslen(str), &cCharsWritten, NULL);
DWORD events = 0;
INPUT_RECORD input_record = { 0 };
MSG Msg = { 0 };
do {
Msg.message = 0;
input_record.EventType = 0;
BOOL peek = PeekConsoleInput(myConsoleHandleInput, &input_record, 1, &events);
if (peek == FALSE) {
if (PeekMessage(&Msg, 0, 0, 0, PM_REMOVE)) {
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
} else {
ReadConsoleInput(myConsoleHandleInput, &input_record, 1, &events);
}
} while ((Msg.message != WM_QUIT) && (input_record.EventType != KEY_EVENT));
}
In typical windows style there are multiple ways of doing the same thing
In vino veritas
modified 3-Nov-16 0:09am.
|
|
|
|
|
I have a few questions on the following cryptography functions.
1)
BOOL WINAPI CryptGenKey(
_In_ HCRYPTPROV hProv,
_In_ ALG_ID Algid,
_In_ DWORD dwFlags,
_Out_ HCRYPTKEY *phKey
); This is supposed to generate a private/public key pair, which is maintained between sessions.
Q: What is the effect of repetitive calls to this function? For example, I decide to change the key length, and generate a call with a different dwFlags value. What happens to the old key pair? Does it get overwritten? Or does each new call generate a new key pair?
2)
BOOL WINAPI CryptGetUserKey(
_In_ HCRYPTPROV hProv,
_In_ DWORD dwKeySpec,
_Out_ HCRYPTKEY *phUserKey
);
MSDN: “The CryptGetUserKey function retrieves a handle of one of a user's two public/private key pairs.”
Q: which one?
MSDN: “dwKeySpec [in]
Identifies the private key to use from the key container.”
In this example, MSDN says
if(CryptGetUserKey(
hProv,
AT_SIGNATURE,
&hKey))
{Q: So how does one retrieve the public key, and how does one get the private key?
3)
BOOL WINAPI CryptDestroyKey(
_In_ HCRYPTKEY hKey
); MSDN: “However, the underlying public/private key pair is not destroyed by this function. Only the handle is destroyed.”
Q: How can the public/private key pair be destroyed?
Thank you!
|
|
|
|
|
Hi,
SMD111 wrote: Q: What is the effect of repetitive calls to this function? For example, I decide to change the key length, and generate a call with a different dwFlags value. What happens to the old key pair? Does it get overwritten? Or does each new call generate a new key pair?
Each call generates a new key pair. Each key remains valid until you call the CryptDestroyKey function or until you reboot. If you wanted to save the key... you could export it or save it into the certificate store.
SMD111 wrote: MSDN: “The CryptGetUserKey function retrieves a handle of one of a user's two public/private key pairs.”
Q: which one?
There is no default for zero-value. You would probably get a ERROR_INVALID_PARAMETER error if you pass zero. You would need to specify either AT_KEYEXCHANGE or AT_SIGNATURE. Currently defined as integers 1 and 2.
SMD111 wrote: Q: So how does one retrieve the public key, and how does one get the private key?
See the previous response. You would need to pass AT_KEYEXCHANGE or AT_SIGNATURE. Note that AT_SIGNATURE keys can be used to sign and AT_KEYEXCHANGE keys can
be use both to sign and decrypt.
SMD111 wrote: Q: How can the public/private key pair be destroyed?
The question is either unclear or nonsensical. When you call CryptDestroyKey the handle to an internal object is securely deleted.
It is up to you to securely delete your own application memory and destroy any exported keys and/or remove keys from the certificate store or on disk.
One last thing... while working internally on an operating system service I discovered multiple failures... including a race condition within the old Crypt32 Cryptography Functions.
Our team moved to the 'Cryptography Next Generation' and all issues were resolved.
Best Wishes,
-David Delaune
|
|
|
|
|
Hello ! I just started to play around with C lately(and mainly with pointers). For practice, i created this function that is suppose to create a random string:
char *ReturnRandomString(int Range)
{
char StringsToChooseFrom[26] = {'q','w','e','r','t','y','u','i','o','p','a','s','d','f','g','h','j','k','l','z','x','c','v','b','n','m'};
char MyArray[Range + 1];
char *Ptr_str;
int i;
for(i = 0; i < Range; i++)
{
srand(time(NULL));
int RandomInt = rand() & 26;
MyArray[i] = StringsToChooseFrom[RandomInt -1];
}
MyArray[i + 1] = '\0';
Ptr_str = malloc(sizeof(MyArray));
Ptr_str = MyArray;
return(Ptr_str);
}
I am "calling" this function this way:
char *PtrCharArray = ReturnRandomString(5);
printf("\nString Array returned: %s", PtrCharArray);
The output... is nothing. I don't neither an output on the console... either an error.
It's sure that i am missing something, but i don't know what. Thanks in advance !!!
P.S No hate.
|
|
|
|
|
char MyArray[Range + 1];
Ptr_str = malloc(sizeof(MyArray)); Ptr_str = MyArray; return(Ptr_str);
That won't work:
1. You cannot allocate an array on the stack using a variable value.
2. sizeof is compile time so it cannot calculate the actual size of the array. You need to use strlen.
3. You cannot use an assignment to copy data. You need to use a copy function: memcpy or strcpy MyArray to Ptr_str.
|
|
|
|
|
1. You cannot allocate an array on the stack using a variable value.
C99 and C11 both permit this. Additionally, both gcc and clang will accept this when compiling in C89 mode, too.
If you're using a POSIX system, then rather than doing malloc() and strcpy() then perhaps use strdup() instead. MSVC has _strdup(), which does the same thing.
|
|
|
|
|
Thank you. Actually I did think that was the case, but when I tried to compile it the compiler objected, so I assumed I just mis-remembered.
|
|
|
|
|
There are some more errors besides those mentioned by Richard.
Here you would normally use the % operator so that the value is in the range 0 to 25:
int RandomInt = rand() & 26;
Anding with 26 (0x1A) will clear masked out bits so that the possible values are only 0x00, 0x02, 0x08, 0x0A, 0x12, 0x18, and 0x1A.
Here you should remove the subtraction of one because that accesses the array out of bounds when RandomInt is zero:
MyArray[i] = StringsToChooseFrom[RandomInt -1];
See the rand() description:
Quote: The rand() function returns a pseudo-random integer in the range 0 to RAND_MAX inclusive.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
