Comments by _coder (Top 27 by date)

ok, for me I think still is more reasonable to use header/cpp files. cause I guess it would take me some time to learn creating dlls

Hi nv 3, but this also means if I update my myfuncs.hpp and myfuncs.cpp files it means I must copy these new versions to all the projects that were using it? (your suggestion #1).

Hi Fredrik. But this also means if I update my myfuncs.hpp and myfuncs.cpp files it means I must copy these new versions to all the projects that were using it?

CPallini thank you. I think I may not need to specify what sendBuffer contains, as I write the data and I read back(I know where I will store what). About string example I was thinking memcpy could also work, to memcpy string (e.g., "hello world") to sendBuffer, right? The only problem I can think of now is that sendBuffer must contain 16 bytes or multiple of 16. If string I want to write is say 11 bytes, I would probably have to pad it right?

why DLL OriginalGriff? First I don't know how to do it, and it is not reasonable for me to spend time on learning that now. I just want solution which works as I mentioned above. Are header files bad for it?

please see my edit

are you sure brydon??

I think you still didn't get my point. Let's say I have y[2] - how does the compiler know correctly how many bytes it should offset by looking at [2]?? Probably it would check type of y, say int, and y[2] would be 8 (8=4*2) bytes further address of y, right? My question was how does the compiler know how many bytes further from (&x-99) to move when it looks at expression (&x-99)[2]?? 4 bytes? 8? or maybe 2?

honestly, I didn't get the point of your example. so like you wanted to show p[2] started pointing to an address very far from p?

What is int (*p)[1000] ?? Is it array if pointers? Have never seen it. Anyway, I think I didn't get your point. Btw. I did some tests. Like here:

int x = 12;
cout<<&x<<endl;
cout<<(&x-188); // prints exactly 4x188 bytes behind address of x
cout<<&((&x-188)[1]); // Prints exactly 4 byes AFTER above address

It seems to work Ok for an int type. But I was curious about cases, when &x-188 refers to a memory address - from which, and using [1] the program does not know how many bytes to move forward... am I making it clear?

Hi Anorexic, thanks. Honestly speaking, I didn't understand to what you are referring to using "higher" protocols?

Thanks for this response. But I think if you use SCARD_AUTOALLOCATE as the last parameter to the SCardListReaders method, you don't need this double calling mechanism which you suggested right? (ps. I will look at your other post above too and let you know if I have question....)

Anorexic thanks for reply, I will look into it. I also have one question hope you can help as I could not find much info on the net. Like I said above as I understood we can use Win32 API functions like SCardListReaders to communicate with Mifare smart cards. The thing is, I have Mifare Plus card. Now, the developer guide: http://www.hidglobal.com/sites/hidglobal.com/files/omnikey_contactless_developer_guide.pdf, in Section 6.2 says that if the card is in security layer 1 or 2 application can't use direct card communication. And in that case they suggest use of some kind of HID proprietary transparent channel. My confusion is that if I use this proprietary channel, then will OTHER readers be able to communicate with the smart card?? How should one communicate with Mifare Plus if the latter is in security layer 1 or 2. Thank you in advance.

Thanks.

Can you explain why this is needed:

"Call it once with a NULL parameter for the data (to get the length), then allocate a data storage area based on that length and call SCardListReaders again with this data store as a parameter. Use one of the names returned to call SCardConnect."

?

Ok, how I delete this question in an ordinary way?? there is no red cross button anywhere i can see

maybe he should re read it, I don't think he has the right to make conclusions as to which questions make someone feel "stupid"/foolish for instance

They didn't make me foolish - and that's not the reason why I removed them. I advice you to mind your own business :)

indeed