|
You may also consider Codelite[^] and even passing to Java programming language.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
Thanks,
Java is something I would never consider. The suite is leased by customers under an annual licence. Distributing Java Code would jeopardise revenue collection because of easy decompilation. CodeLite merits further investigation though.
However, The entire project consists of 1100 Files, roughly 900 of these relate to MFC, the remaining 200 relate to Non MFC CPP Classes, or, to plain 'C' Code. Hence, I am looking for File Conversion(and not of the video type) This can range from a set of suitable and crafty '#define'S to the writing of a parser and code generator.
The project started in earnest in 2001 on Win98 Architecture. The existing Code Base is considered 'Bug Free' since 2005.
Bram van Kampen
modified 17-Sep-14 19:55pm.
|
|
|
|
|
If you have a lot of existing MFC code, wxWidgets is really modeled to be similar (actually not sure if it was modeled on MFC or it just sort of evolved similarly).
|
|
|
|
|
 Wx would have been my suggestion, too.
A gui I have with custom controls and drawing works equally well under XP, Vista, Win7 and linux. On hardware as varied as a q8400, i3, i7 and a raspberry pi. Simply build for the appropriate platform and voila! Portable, consistent code/gui.
"When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down 'happy'. They told me I didn't understand the assignment, and I told them they didn't understand life." - John Lennon
|
|
|
|
|
Bram van Kampen wrote: Windows 8.XX is entirely incompatible with providing software for a cash register program.
(just curious)
In what way? it does not make sense; usually, hardware like that have their own "OS" (and it is usually not Windows)
AFAIL, MFC has not changed since the 2008 feature pack.
Are you using a proprietary SDK/OS for the cash register machine ?
I'd rather be phishing!
|
|
|
|
|
Maximilien wrote: usually, hardware like that have their own "OS" (and it is usually not
Windows)
Not true at all... a bunch of POS systems run on Windows. Of course, a bunch others run on Linux... so it just depends on the manufacturer.
|
|
|
|
|
I stand corrected.
but if POS' OS is windows, than it will probably will not allow be be replaced by linux. (or the other way around).
(just askin')
I'd rather be phishing!
|
|
|
|
|
The POS software is simply just that... software. It runs on a standard computer. Again, depending on the manufacturer, the computer can be a standard computer (since they're relatively cheap) or a smaller form factor embedded computer with a screen (those can be really cheap, have a smaller footprint).
Since it's just a computer w/ software, it can be hosted on whatever OS you want as long as you've built it that way. If you have full-blown Windows on a machine, odds are it's a bigger machine, because most small-form factor embedded computers don't have that much RAM.
Some places may even still be on Unix systems. The big companies are slow to adopt changes and their Unix systems worked so well they've been hesitant to change. I believe Home Depot may still use Unix systems. They're fast and are all linked together so they can track everything based on their databasing of collected data.
|
|
|
|
|
fair enough.
I have to say, I never really looked at the POS to know better!!!
Thanks.
I'd rather be phishing!
|
|
|
|
|
I've worked on embedded systems... so as an engineer (and nerd) I pay attention to what OS's things run on.
|
|
|
|
|
Albert Holguin wrote: Not true at all... a bunch of POS systems run on Windows
Actually I would suspect that the vast majority of POSes run on either windows or a unix variation. Even if one includes systems going back 20 years I would expect that probably at least 90% run one or the other.
|
|
|
|
|
Not sure how your statement differs from what I said...
|
|
|
|
|
You statement could have been taken to mean that even though there was a significant number on Linux/windows, but there could have been others on something else. And this could be a fairly recent development.
But instead almost all of them all windows/Linux and have been for a long time. And I only say almost because it is possible there are some. Although I suspect very few in the US.
|
|
|
|
|
I guess you didn't read the plethora of other posts I wrote? 
In any case, we're not in disagreement.
|
|
|
|
|
Maximilien wrote: In what way? it does not make sense; usually, hardware like that have their own "OS" (and it is usually not Windows)
Well, our existing App runs on XP.
Laundrette and Drycleaning POS systems are far more complicated than say your average Corner shop POS. The latter deals in Commodities. (A Packet of Branded butter is the same as the Next one. We don't care which particular package leaves the shop, or, who walks out with it, as long as we get the money, and update the stock.) In a laundrette, every customer wants their own shirt back, and, we need to know who did what in case of complaint. So a laundrette POS System comprises indeed of the functions of a traditional POS system, such as keeping track of cash and cash drawer contents. In addition to this, the POS System needs means to identify customers, and to book in customer orders, and prioritize these. The staff doing the actual work need a way to find out which orders are at hand, and a way to mark these orders as 'Completed' Management needs statistics. Personell needs records of Production in order to calculate Staff production bonuses, etc, etc. We are talking 'Database Management'
Our system consists of a suite of a bakers dozen interlocking applications. The lot works well in Windows XP. In fact, there is nothing that either Vista, Win7 or Win8 has to offer that would be of any benefit to our system.
The Software is written to be used by staff which are employed because of their Laundry skills, not their computer skills. Any change in IDE experience constitutes a major re-training exercise for all users. The presence of 'charms' and 'Apps' on a Win8 system constitutes a real problem in this respect.
Our suite runs under MFC42, and does not need any of the further extensions introduced in 2008
Hope I satisfied your curiosity.
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: Are there equivalents for the same environment for Linux.
For developing GUIs? ...there's a bunch of frameworks out there. A few are Qt, WXwidgets, GTK+. Of course, some of those frameworks are much more than GUIs nowadays (much like MFC). Qt seems to be pretty prevalent in business applications, but if I remember correctly, as a business user you have to pay some fee.
As for non-gui elements, the boost library offers quite a selection of nice cross-platform libraries. If it's in the new C++ standards, it was likely in boost first. 
As for IDEs.. there's a handful to choose from there:
0. Eclipse- Probably one of the most popular, install CDT version (comes with C/C++ plug-ins preinstalled). Bad thing is that Eclipse runs on Java so you'll be running Java to code your C/C++.
1. Netbeans- Probably second most popular. Nice interface, probably "lighter" than Eclipse.
2. CodeBlocks- I've never used this one, but it seems to also have a following. It's probably more bare bones than the others.
3. Others? Run off the terminal?- There should be plenty of choices for coding in C/C++.
|
|
|
|
|
While it is true that XP has gone away, the componentized point of sale version of Windows XP - called "POSReady" will continue to be supported for some time.
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=POS&Filter=FilterNO
You're good until 2019.
modified 17-Sep-14 15:07pm.
|
|
|
|
|
Never heard of PoSReady... it's probably just a pre-built version of XP Embedded or one of their other embedded variants.
|
|
|
|
|
Hi
Thanks for the Reply.
bling wrote: While it is true that XP has gone away, the componentized point of sale version of Windows XP - called "POSReady" will continue to be supported for some time.
We Don't use that version.
Laundrette and Drycleaning POS systems are far more complicated than say your average Corner shop POS. The latter deals in
Commodities. (A Packet of Branded butter is the same as the Next one. We don't care which particular package leaves the
shop, or, who walks out with it, as long as we get the money, and update the stock.) In a laundrette, every customer wants
their own shirt back, and, we need to know who did what in case of complaint. So a laundrette POS System comprises indeed
of the functions of a traditional POS system, such as keeping track of cash and cash drawer contents. In addition to this,
the POS System needs means to identify customers, and to book in customer orders, and prioritize these. The staff doing
the actual work need a way to find out which orders are at hand, and a way to mark these orders as 'Completed' Management
needs statistics. Personell needs records of Production in order to calculate Staff production bonuses, etc, etc. We are
talking 'Database Management'
Our system consists of a suite of a bakers dozen interlocking applications. The lot works well in Windows XP. In fact,
there is nothing that either Vista, Win7 or Win8 has to offer that would be of any benefit.
The Software is written to be used by staff which are employed because of their Laundry skills, not their computer skills.
Any change in IDE experience constitutes a major re-training exercise for all users.
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: Any change in IDE experience constitutes a major re-training exercise for all users.
Do the users interact with the actual OS? If so, switching to Linux might suffer from the same problem.
Sorry, I know this is not a very constructive comment, but it needs to be considered as well.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
SoMad wrote: this is not a very constructive comment
Those are the best kind... 
|
|
|
|
|
The POSReady version carries one distinction.
It is component-ized which means you can omit the parts of the OS that you don't use (like IIS or IE). If your system needs to be PCI compliant - omitting unused components means fewer security patches. If someone publishes a "0" day exploit to a subsystem you don't use - you don't have to scramble to patch all your systems.
From a UI perspective - it looks just like XP Professional.
Of course, 2019 isn't that far off. At some point you will have to move to a newer OS. This might give you an extra five years to make that decision.
|
|
|
|
|
Bram van Kampen wrote: for a cash register program.
Are you selling a POS or a program? If the latter then to increase your market you need to support both anyways. If the former then you roll out a new platform when you roll it out. Since they are still selling Windows 7 you don't need to move to Windows 8 until you want to.
Windows 7 extended support goes to 2020.
And of course Linux variants also do OS updates so you would still need to deal with those as well.
|
|
|
|
|
I am crazying with a problem with the following function:
CStringA EncryptDecryptString(CStringA szString, BOOL bEncrypt)
{
HCRYPTPROV hCryptProv = NULL;
LPCWSTR keyContainer = _T("MyKeyContainer");
if(CryptAcquireContext(&hCryptProv,keyContainer,NULL,PROV_RSA_FULL,0))
if (GetLastError() == NTE_BAD_KEYSET)
CryptAcquireContext(&hCryptProv,keyContainer,NULL,PROV_RSA_FULL,CRYPT_NEWKEYSET);
HCRYPTHASH hHash = NULL;
TCHAR szPassword[11] = _T("Password");
if(CryptCreateHash(hCryptProv,CALG_MD5,0,0,&hHash))
{
if(!CryptHashData(hHash,(BYTE *)szPassword,wcslen(szPassword),0))
{
CryptDestroyHash(hHash);
hHash = NULL;
}
}
HCRYPTKEY hKey = NULL;
CryptDeriveKey(hCryptProv,CALG_RC4,hHash,0x00800000,&hKey);
DWORD length= szString.GetLength() + 1;
BYTE * cipherBlock= (BYTE *)malloc(length);
memset(cipherBlock, 0, length);
memcpy(cipherBlock, szString, length -1);
if (bEncrypt)
CryptEncrypt(hKey,0,TRUE,0,cipherBlock,&length,length);
else
CryptDecrypt(hKey,0,TRUE,0,cipherBlock,&length);
CStringA szOutString(cipherBlock);
if(cipherBlock)
free(cipherBlock);
if(hKey)
CryptDestroyKey(hKey);
if(hHash)
CryptDestroyHash(hHash);
if(hCryptProv)
CryptReleaseContext(hCryptProv,0);
return szOutString;
}
It's all ok with function, but sometimes when string is very very long during the Decryption i have only a part of string becouse the allocated memeory is not enought.
How can i alloc the correct amount of memory during the decryption phase?
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
