|
ATL[^] is only provided with the purchased versions of Visual Studio, not the Express Editions.
|
|
|
|
|
|
|
VC++ 2010 is not giving any option to add web service/web reference.
how can it achive??
|
|
|
|
|
|
VC++ 2010 wizard do not show Add WEB Reference/Service option when i select MFC project. this option was avaiable in previous version of IDE.
attached link is not useful info for my problem..
|
|
|
|
|
|
Recently,
I'm using the Ribbon XML to build a button in Word 2007.but i need to custom the image of button.
so,I find something form the url: http://msdn.microsoft.com/en-us/library/office/dd548011(v=office.12).aspx[^]
keywords:OnLoadImage
question: It's only use VBA to solve the problem,I'm realy don't know how to use c++ to solve this.
Please help me and give me some suggestions!
best wash!
|
|
|
|
|
Hi,
Has anyone used unit testing for ATL project?
I am currently exploring ALM in VS 2010 ,Is it really worth the efforts?
jigar
|
|
|
|
|
Windows 7, Visual Studio, C++, MFC and non console type applications that have no windows
Given:
WCHAR destination[ 60 ]
WCHAR source[ 60 ]
Presume: destination has 20 characters to be retained.
What is the best method of copying all the characters that will fit from source into destination?
Easy enough for ASCII, but difficult for this WCHAR novice.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
Just use the wcscpy[^] function. There are wide versions of all the character manipulation functions.
Veni, vidi, abiit domum
|
|
|
|
|
Refer back to the OP. The strings have the same maximum length. String destination already has 20 characters so 60 more will not fit.
Function wcscpy() has only two arguments, destination and source. We can write the destination in the format: destination[20] to start there, but there is no way to specify that only 39 of the source characters are to be copied.
However, having seen that, I then found wcscpy_s() with three arguments. We can specify destination[ 20 ], then specify the second argument would be 40.
We can generalize this with a calculated length. But I am unsure about the right functions to use with WCHAR to get the max length and to get the current length. I will try to find that and post again.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
|
Yes, you are so right. Found the page, got the function, using it.
Thank you for taking the time to reply.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
Not sure what you mean by 20 characters needing to be retained. No need to walk the string one-by-one...
wcsncpy_s(destination, 60, source, 20);
Will take the first 20 characters of source and copy them to destination. But if you must walk it one-by-one are several ways...
for(i=0; i < 60; i++)
{
WCHAR *current = &source + (sizeof(WCHAR) * i);
destination[i] = *current;
WCHAR current = source[i];
destination[i] = current;
}
I'd never declare a variable in a loop like that, so it's just for illustration. Anyway, you can do whatever logic you want to skip the first 20 chars in destination at that point.
Jeremy Falcon
|
|
|
|
|
Windows 7, Visual Studio 2008,C++, TCP/IP
Please describe what “overlapped” means in terms of Windows sockets I/O. I found some pages but they describe how to use it rather than what it really is.
Full Motivation
My application will perform high data rate TCP/IP output, and it will be rather bursty. It will call the send function several times in rapid function.
Will the use of the overlapped mode provide an advantage?
My presumption is that the app can initiate TCP/IP output on multiple buffers and each becomes an almost completely separate I/O function.
More Info
The app will send out what I call messages. Each message can have its own unique buffer containing all the packet overhead and data. Message A (of A through Z) will very seldom be sent twice in a single burst. I can arrange for an array or structure of messages A through Z keeping them completely separate from each other. Using that, I am thinking that the overlapped option will be useful.
From this Microsoft web page:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740087(v=vs.85).aspx
My reading of the last four or so paragraphs, indicates that overlapped will facilitate the fast and bursty I/O needed.
Further reading leads me to tentatively conclude that the app can call WSAGetOverlappedResult passing in the address of each specific buffer (along with other goodies) and the return value will indicate if the I/O has completed to the point that the app can re-write that buffer without fear of any data being lost.
Bonus Question
In the web page for WSAGetOverlappedResult, the minimum supported client is Windows 2000 Professional [desktop apps only]. Does that include Windows XP Pro and Windows 7?
I see there is more to this and am studying the help page on WSAGetOverlappedResult and WSAOVERLAPPED structure. (Hmmm, event handle. That looks helpful, as in WaitForMultipleObjects())
Conclusion
I don’t ask for all the details, just a basic explanation and comment as to if I am going down a viable and/or a good path.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
bkelly13 wrote: Please describe what “overlapped” means in terms of Windows sockets I/O.
It means that the operations will run asynchronously, leaving your application free to do other work. You then need to go back at some other point to check whether the operation has completed, and if so, was it successful.
bkelly13 wrote: Does that include Windows XP Pro and Windows 7?
Yes, see http://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions[^].
bkelly13 wrote: if I am going down a viable and/or a good path.
Always a difficult one to answer since it depends on so many factors. It would appear to be a sensible choice, but you would need to run some tests for yourself to be sure.
Veni, vidi, abiit domum
|
|
|
|
|
Hello Richard,
In at least one MSDN help page about socket functions, they write that overlapped is not the same as sync and async. They work together but are not the same. As I interpret the pages:
Overlapped means having multiple buffers submitted for I/O at one time. The app can, for example post four sends with four separate addresses (addresses of buffers to send). After the four posts it can be the case that none of them have been signaled as complete. The operating system will then signal each of the four I/Os as being complete some time later. The application must not disturb those buffers until each one has been signaled as complete.
As each one is signaled complete, the application can re-use that buffer, but not until then.
In the WSASend function argument six is structure WSAOVERLAPPED. We can use WSASend and other TCP/IO functions with async but without overlapped. Or with overlapped.
Is my interpretation correct, as far as it goes?
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
modified 20-Jan-14 12:17pm.
|
|
|
|
|
bkelly13 wrote: Is my interpretation correct, as far as it goes?
That is my understanding of it. Maybe this whitepaper[^] will help to clarify it.
Veni, vidi, abiit domum
|
|
|
|
|
Hello Richard,
In that article, the second paragraph in the section titles Overlapped I/O, is a sentence that beings with:
Quote: If you use the SO_RCVBUF and SO_SNDBUF option to set zero TCP stack receive and send buffer, ....
I think I understand the remainder of the paragraph as saying: We can call the send or receive function telling the OS and the TCP part of the OS, to use the buffer we have supplied as the buffer to output/input the data. That saves the OS/TCP code from performing a copy of the data. This reduces the total number of CPU cycles dedicated to performing my I/O operation. It also means, as I noted earlier, our app cannot touch that buffer until the send/receive is complete.
That said, just what does that quoted part of the sentence mean? "... to set zero TCP stack ..." That appears to be just a simple case of not very good choice of words. On the other hand, I may be missing something important.
Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/
|
|
|
|
|
Well I didn't write that paper ... However, as I understand it, by using those settings you are allowing the low level data transfer to be done direct to/from your data buffers, rather than using an internal buffer which requires the data to also be copied to/from the application buffers. That is why you must guarantee not to use the buffer until the transfer is signalled complete.
Veni, vidi, abiit domum
|
|
|
|
|
Overlapped vs Async: I guess you have already programmed multithread apps for windows. Then you have probably met some synchronizations objects like CritcalSection, Mutex, Slim RWLock, ... Do you see, here MS used basically synonyms to differentiate lock types provided by the OS. Generally we could say that all of these are mutexes if we use the word "mutex" out of the context of the windows api documentation but the winapi documents use the word "Mutex" to refer to one of the winapi locks (the one created by CreateMutex) that can have a name and can be shared between processes in return for some performance penalty.
After the previous paragraph it will be easier to understand the following: In the socket api docs MS uses the word "async" and "asyncblahblah" to differentiate a set of its socket handling apis from the rest of the apis. Usually with "async" the MS docs refer to the socket handling apis that send you completion callback as a window message (WSAAsyncSelect) but sometimes some docs also use "async" to refer to the bsd compatible select() function call and its more effective windows "equivalent" WSAEventSelect+WSAWaitForMultipleObjects or WSAPoll. But this is true only if we are in the context of the windows api docs and this is quite confusing. If we use async outside the context of the socket winapi docs then we can say that overlapped is also an async operation, the winapi docs just use "async" and "overlapped" to differentiate two different set of apis, its still very confusing as an overlapped operation is also an async operation. I guess this unfortunate naming convention probably comes from the fact that the original "async" api existed earlier than the overlapped stuff.
If you search for "asynchronous" you will find a lot of explanations and some of them are so theoretically so abstract that they are totally impossible to practically interpret in my opinion. Here is a very dirty and rough explanation what async means when it comes to programming: An operation is async if it can be started without blocking the starter thread after starting the operation. The thread just starts the operation and later this thread or another one can poll whether the execution has ended or there is another more effective way to detect the operation finish: waiting for it. There is another mechanism to detect the operation finish event: a callback is called by a separate thread when the operation has finished but the pure waiting and the callback can be converted one to the other with user code so they are basically equivalent from some point. Note that the implementation of an async operation is often a background thread, for example your own thread or an OS thread or a set of these threads but the implementation of an async operation can also be a hardware implementation (for example a DMA transfer whose completion may be polled or it may be signaled by the hardware for example in the for of an interrupt) or an arbitrary mixture of all the previously listed options. The async operation is async if we are taking a look at it from the perspective of the thread that starts the operation but it isn't async if we are looking at it from the perspective of the thread or hardware that actually performs the operation.
So if we take a look at the previous explanation you see that overlapped operations are indeed async operations and besides this overlapped IO is the most effective IO mechanism of windows. You can start it and you can poll for the result or you can later blocking-wait for the result. From the perspective of the operation-starter thread a blocking call can also be treated as a special case of an async (maybe an overlapped) operation: A blocking call starts the operation and immediately starts blocking-wait for its completion.
If you want to exploit the full power of windows then you wait for the end of many overlapped operations with a single IO completion port (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198%28v=vs.85%29.aspx[^]). The idea behinde IO completion ports is simple: You create an IO completion port and you register many overlapped operations to this "IO completion port", when you start an overlapped IO operation you just register it to this port. When windows finishes with one of the registered overlapped operations then it places a message into the queue of the IO completion port about the result. Besides this what you have to do is creating a thread pool and all threads should blocking-wait on the IO completion port handle for a new incoming message. When one message arrives then a thread grabs it and performs the necessary work (for example if socket/file/pipe/... write has finished then it checks whether you still have writeable data for that handle and if so then it starts another overlapped operation for that handle). Note that the linux epoll api and the bsd kqueue api also works with the same registration and operation-finished-queue concept but the windows api is much more complex because it is mixed with the overlapped api that is terribly easy to put wrong and buggy.
Note that you can use a single IO completion port and a generalized thread pool to perform overlapped read/write operations on many different kind of handles (files/sockets/pipes), this is why WriteFile/ReadFile works also on socket handles just like WSASend/Recv. Besides this no other socket handling api comes close to the scalability of IO completion ports when it comes to handling IO on a lot of handles.
SO_RCVBUF and SO_SNDBUF to zero? Lets say you are writing a file with overlapped IO. Then the overlapped operation basically writes the buffer you supplied into the disk storage occupied by the file or if caching is enabled windows copies the contents of your buffer into the IO cache and then it marks your write operation as finished immediately even before writing the contents to the disk. The same may happen with a blocking file write operation if windows has a lot of disk cache space. You can think of the socket SO_SNDBUF in a similar way as about the IO cache of disk files. Even a blocking send() call can return immediately if you supply a buffer whose size is less than or equal to the size of the free space of the SO_SNDBUF of the socket handle, in this case windows just appends your buffer contents to the end of the SO_SNDBUF of the socket handle and returns immediately. This is true for both blocking and overlapped operations, you are just writing this buffer and not actually sending data with your blocking send() call or your overlapped write operation. Then in the background the network stack performs the actual transfer over the wire in the background...
If you set SO_RCVBUF and SO_SNDBUF to zero then your socket handle basically doesn't have this caching area and in this case windows sends the data over the wire directly from your buffer and your overlapped operation finishes only when all data has been sent. In case of overlapped operations this isn't a big problem because you probably don't care whether an overlapped operation is in progress because it would block on a full SO_SNDBUF or on actually sending the data through the wire. SO_SNDBUF is an extreme optimization that isn't even available on other platforms and if you set the SO_SNDBUF to zero then you have more control over the buffer sizes from which the network stack is working and this can be used for both good and bad, be careful with it.
There is no golden rule to write the "best" networking engine. What is "best" and "optimal" is dependent on the particular problem to be solved and on the target hardware. You can never write something that is the "best" solution when it comes to networking.
|
|
|
|
|
Sorry, it seems I sent my previous post as a reply to the wrong place. 
|
|
|
|
|
I wondered why you were telling me.
|
|
|
|
|
Hello,
I've been working on an application that would allow a program to communicate over lan, using UDP and TCP. Here's a general flow of what I was thinking:
1. Send UDP Broadcast to subnet on a port that all applications will listen on (i.e. all listening on 59200)
2. The application running on other nodes, receive the broadcast and echo a UDP broadcast back.
3. Using the information obtained from the UDP echo, a TCP connection is opened and data is exchanged.
4. Connections remain open until an error occurs (this was a requirement of design.)
Is such a design feasible, and if so how would it best be accomplished? I've been reading up on Winsock and MSDN articles on this, and have created client/server applications but have not found very much that would outline a peer-to-peer application like this. I would appreciate any guidance, or direction a resource that could further my understanding on this topic.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
