> I think memory usage would be close (if not identical) because we are talking about a given struct within a finite array. ~ Correct. > As for speed, I don't know if that would matter until we were talking about thousands of elements or hundreds/thousands or new/delete pairs. Actually, calling X times an allocation/de-allocation routine is almost ~X times slower than calling it once with a X-time larger memory chunk (provided it doesn't trash the OS). cfr. a good OS internals book, e.g. http://www.sysinternals.com/insidew2k.htm > And yes, I obfuscate my code like this all the time, and no, I wasn't trying to embarass anyone. :-O Phew, thanks. Since we are on a roll here: Do you want to stick your neck out? Try this one: Write down the output of the listed program without compiling and running it. Then check the results... But then again, of course, you do this in a jiffy. :-D class foo { public: foo() {} virtual ~foo() {} virtual void Print(void) { cerr << "it's foo!\n"; } void Print(int err) { cerr << "it's foo with err : " << err << "\n"; } }; class childfoo1 : public foo { public: childfoo1() {} ~childfoo1() {} void Print(void) { cerr << "it's childfoo1!\n"; } void Print(int err) { cerr << "it's childfoo1 with err : " << err << "\n"; } }; class childfoo2 : public foo { public: childfoo2() {} ~childfoo2() {} void Print(void) { cerr << "it's childfoo2!\n"; } void Print(int err) { cerr << "it's childfoo2 with err : " << err << "\n"; } }; // which Print function is called ?? int main(void) { foo * foopointer1 = new childfoo1(); foo * foopointer2 = new childfoo2(); foo * foopointer3 = (childfoo1*) foopointer2; childfoo1 * foopointer4 = (childfoo1*) foopointer2; cerr << "\n1 "; foopointer1->Print(); cerr << "\n2 "; foopointer2->Print(); cerr << "\n3 "; foopointer3->Print(); cerr << "\n4 "; foopointer4->Print(); cerr << "\n5 "; foopointer1->Print(5); cerr << "\n6 "; foopointer2->Print(5); cerr << "\n7 "; foopointer3->Print(5); cerr << "\n8 "; foopointer4->Print(5); delete foopointer1; delete foopointer2; return 0; }

Back at work and armed with stroustrup and the compiler, I think there is only corect viewpoint: yours. :cool: But talking about obfuscating code. I hope for your work buddies sake you’re not using this kind of C++-isms all over your code. Completely beside the point, of course, but what is the advantage of your piece of code over the following code (and don’t say 'memory usage' please, because I will say 'speed'...) or did you just wanted to prove your point and embarrass your boss (and me)? ;P struct SLOT { CString sField1; int nField2; }; SLOT* m_pSlots = NULL; void InitSlots() { m_pSlots = new SLOT[5]; for (int i = 0; i < 5; i++) { m_pSlots[i].sField1 = "Empty slot"; m_pSlots[i].nField2 = i; } } void DeleteSlots() { delete [] m_pSlots; } int main(int argc, char* argv[]) { InitSlots(); DeleteSlots(); return 0; }

Aargh... the "pointers to pointers" syndrome. Without looking at a C++ reference book or looking at the compiler output, my money is on your boss. But then again...? Stroustrup will hopefully give you the correct answer...

Here, it has been raining since yesterday evening. Maybe it's the weather in combination with the "friday syndrome", don't kno', but for the past 2 hours, I have been staring at the trees through the window visualizing MY liquid supper. My colleges - hopefully - think I am solving an incredible difficult coding problem... Ah, Belgian trappist,... dark..mysterious..inspiring..sweet with a bitter aftertaste..here I come... (Have a nice weekend

I think this is it, unless I'm mistaken. int TestAndSet(int* pTargetAddress, int nValue) { __asm { mov edx, dword ptr [pTargetAddress] mov eax, nValue xchg eax, dword ptr [edx] } }

A Problem with the previously mentioned algorithms is that they assume "atomic" read and write operations. I also found this solution which is, like you say is dependent on "undividable" processor instructions. // ALGORITHM //////////// // wait(s) // { set s = 0 and if old value of s was 0 then // repeat // 'wait' // until set s = 0 and old value of s was 1 } // signal(s) // { s = 1; Tell OS if appropriate } Concerning, "how are you getting multiple threads if you don't have an OS?". From my perspective (WinNT/W2K backend programmer, now engaged in building software for a NO-OS device), the device we are building has two "tasks" ("Threads"). It has a slow main loop (task 1) which can be 'interrupted' ("pre-empted") by the driver level (task 2..N). The idea is to have the driver level handle the Hardware dependent stuff, e.g. detect if a keypad button that was pressed, and put it in an event queue for the slow main loop to process. If my main loop can get interrupted at any time, I need some protection (locking) on the queue, otherwise it will get corrupted. (if it is locked by the main loop, I could put the event in a temporary queue and put it in the real queue some time later (ASAP of course) ) The standard way of avoiding corruption is: mutex_begin() { disable_interrupts(); } mutex_end() { enable_interrupts(); } Which of course could lead to "event loss". The algorithm above (based on TestAndSet) is an improvement over this, but it needs to be supported by processor instructions. Since I am not a whizz kid in assembler (let's be honest, I never had to use it before so I never did), I am gratefull for any pointers or assembler crash courses that anyone can give me about these undividable SMP safe (i386) instructions I could use to implement a Test And Set function. // MSDN example int power2( int num, int power ) { __asm { mov eax, num ; Get first argument mov ecx, power ; Get second argument shl eax, cl ; EAX = EAX * ( 2 to the power of CL ) } /* Return with result in EAX */ } // my would-be function that sets a value (nValue) on the target address (pTargetAddress) and returns the previous value (that was found in pTargetAddress) int testandset(int* pTargetAddress, int nValue) { __asm ... // help ! } Best regards, Gert.

This looks like a school project, but it's not. Having used mutexes and semaphores a zillion times, "finally the time has arrived to write my own implementation for use in an embedded system without OS." :-( I did some research on the matter and I found Peterson's Algorithm (for 2 processes, threads or whatever) and Lamport's bakery algorithm (for N processes, threads or whatever). ;) There is no need to reinvent "hot water" again, an existing algorithm will do just fine. For info, Peterson's Algorithm: int flag[2] = { FALSE, FALSE } // flag[i] indicates that Pi wants to // enter its critical section. int turn = 0; // turn indicates which process has // priority in entering its critical // section. // mutexbegin: flag[i] = TRUE; turn = 1 - i; while (flag[1 - i] && turn == 1 - i) ; // mutexend: flag[i] = FALSE; Now Lamport's Bakery algorithm. Assumptions: NPROCS is the number of processes. max(int *array) returns the maximum value in array. Each process has a unique ID, so ties on the number chosen are broken by comparing IDs. Replace i with the appropriate process ID. // Global initialization: int choosing[NPROCS] = { FALSE }; int number[NPROCS] = { 0 }; // mutexbegin: choosing[i] = TRUE; number[i] = max(number) + 1; choosing[i] = FALSE; for (j = 0; j < NPROCS; ++j) { while (choosing[j]) ; while (number[j] != 0 && (number[j] < number[i] || number[j] == number[i] && j < i) ) ; } // mutexend: number[i] = 0; THE QUESTION: in the line number[i] = max(number) + 1; we see the function 'max'. How do I interprete this? I thought it meant the maximum of all the numbers in number[], but that does not seam to work. Also, any suggestions on writing a bool CPP_Mutex::TryEnter(unsigned int PNumber) function ? Any input or pointers greatly appreciated! :cool: NOTE: I know this class produces what is called a "spinning lock", but that's OK. I tested it with a dual processor machine with the following code: #define NPROCS 2 #undef Max #define Max(A,B) ((A)<(B)?(B):(A)) // Implementation of LAMPORTS Bakery Algorithm class CPP_Mutex { public: CPP_Mutex() { memset(m_nChoosing, 0, sizeof(int)*NPROCS); memset(m_nNumber, 0, sizeof(int)*NPROCS); } ~CPP_Mutex() { } void Enter(unsigned int PNumber) { m_nChoosing[PNumber] =

Hello, I think you are on the wrong track with FindWindow. Why don't you just store the pointers to the ChildWindows in a nice collection class (e.g. in the parent or in your application object) when they are created, and remove them when you destroy them. You can even make them searchable on a particular key (hey, you are the boss, so you decide what the key should be). Then don't use (p_whatever)->SendMessage(...); // p_whatever is a pointer to a CWnd but use HWND theWindow = (p_whatever)->GetSafeHwnd(); if (theWindow != NULL) { SendMessage(theWindow, ...); } or better use PostMessage. better still when sending messages to other threads use PostThreadMessage. Don't over-complicate things...

Like everybody here points out - as frustrating :mad: as this may be - there is no crack-proof software or security. Protecting software is as difficult as protecting a "bit stream" (cfr DVD, DECSS, ...). If it's 'ones and zeros', it can be copied, dissected, cracked and altered. That does not mean you do not have to try, as Shane Hyde implies. Maybe a third party library can do the trick. Our company uses "Sheriff software" :eek: (http://www.sheriff-software.com) which is relatively cheap and offers in my opinion an acceptable level of protection. (NB: Please note that this is not a sales speech) I tested the library and it is possible to crack at least a part of it. (NB2: So this is definitely NOT a sales speech) It depends on the license policy you use. If you automatically issue a "fully functional for a limited time" evaluation licenses you are more vulnerable to an attack. I did not exhaustively test :cool: the key generation scheme but it 'seems' robust enough. At least a third party software library might be the answer since they are (hopefully) constantly improving their product, and they are more focused and putting more effort into the software security design goal than you and me have time for. Just my 2 cents. NB3: These Board Emoticons :rolleyes: are cool !

>> Again, none of this will prevent a determined cracker, or even a half-good one. Agreed, but what you suggest is cracked in 10 minutes, using RegSnap, RegMon and Regedit. (We use a third party copy protection scheme, which I eh... tested). It uses encrypted keys which also contain some of the information about the type of the license (time/user limited - trial or full version, etc...). Althoug I did not remove the key's encryption protection, I was always able to fool the program in extending (renewing) the evaluation time/license. I do not have an adequate answer to this problem, but maybe it is still worthwile to invest in a good third party protection program (And try to break the security yourself when you are evaluating the product so you have an idea how difficult it is for a thief to rob you from your bread and butter)

Well, First check if you are exporting and importing OK. http://support.microsoft.com/support/kb/articles/Q128/1/99.asp Concerning a possible MFC bug take a look at http://support.microsoft.com/support/kb/articles/Q152/2/54.asp

Hi, I suggest you create a Win32 windowless application. You do not need to change anything in your existing Console Application (except getting rid of the console App). Here comes a bulk of code. Try to understand it. This mechanism will create a message loop for your application so it can respond to WM_CLOSE and WM_QUIT and WM_QUERYENDSESSION (Windows Exit or Log off) messages. It creates a Console in Debug Mode so you can print some debug messages to this console but there is no window in release. It is not hidden, it is never created hence you do not use the resources. In debug mode ctrl-C and ctrl-break can be caught. (sounds familiar to a Unix-dude doesn't it?) WaitUntillKeyPressed is a function that will enable you to see the debug output in the console when the App has done its work. (can be handy) Win32 Apps do not have a "int main(argc, argv)" form entry function but a "WinMain" entry function. #include #include DWORD dwMainThread = 0; // pseudo code for the worker thread object // give it Start() and Stop() functions // WorkerThreadObject* p_YourThreadObject = NULL; static __int32 ConsoleHandler(DWORD fdwCtrlType) { switch(fdwCtrlType) { case CTRL_C_EVENT: case CTRL_CLOSE_EVENT: case CTRL_LOGOFF_EVENT: case CTRL_BREAK_EVENT: { UINT Msg = WM_QUIT; // message to post WPARAM wParam = NULL; // first message parameter LPARAM lParam = NULL;// second message parameter BOOL Answer = PostThreadMessage( dwMainThread, // thread identifier Msg, // message to post wParam, // first message parameter lParam // second message parameter ); _ASSERT(Answer == TRUE); return TRUE; } default: { return FALSE; } } } static void WaitUntillKeyPressed(void) { HANDLE hConsoleInput = GetStdHandle( STD_INPUT_HANDLE ); INPUT_RECORD Buffer; DWORD NumberOfEventsRead = 0; while ( ReadConsoleInput( hConsoleInput, // handle of a console input buffer &Buffer, // address of the buffer for read data 1, // number of records to read &NumberOfEventsRead // address of number of records read ) ) { if (Buffer.EventType == KEY_EVENT && Buffer.Event.KeyEvent.bKeyDown == TRUE) { break; } } } int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { #ifdef _DEBUG BOOL Answer = AllocConsole(); _ASSERT(Answer == TRUE); if (! SetConsoleCtrlH

Problem solved: I did get a very usefull reply from Mr Miller from Manaware. --- NT can do up to 256. The card manufacturer has not set up the registry and the 'DosNames' for the devices correctly. There might be other names for those serial ports, but the "COM" file names need special aliases created in the registry. Some manufacturers fail to add those when they install or initially load the device driver. Use RegEdit and look for 'SerialPort' or 'Serial Port' and you might find their real names. So the answer to your quesitons is "Yes, you are right, and the card manufacturer still has some work to do on their device drivers." --- The problem was solved by using "\\.\COMxx" In stead of opening "COMxx" (where xx is is the number)

Hello, Friday afternoon, ... Thought I should post this question now: "How does a programmer open COM 10, 11 or higher" [ccode] HANDLE hCom = CreateFile(szPort, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL)); [/ccode] It fails when using szPort = "COM10" although I do have the COM Ports available. Anyone experience in this field? I am working on NT. The cards are MOXA CI-134/ISA and C168H/PCI. I know there is a limitation when working with standard Win32 COM lib on Win 3.11, but does it still apply to WinNT ?? I thought WinNT could handle up to 256 COM ports? Help!

Do you mean you want to test or speed up the process launch and you find your process is already cached in the windows cache? FlushInstructionCache -> Process instruction cache is flushed (but not the data) FlushFileBuffers -> Call this for every open file handle and all writes are performed. (purges write cache) use FILE_FLAG_WRITE_THROUGH in the file create or open call. (disables write caching) more interesting than the above blabla is http://www.sysinternals.com/cacheset.htm