|
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?
|
|
|
|
|
|
Hi,
I show that some CMenu methods, need the ID of the menu that is already created inside the resource manager.
But, if the CMenu is created dynamically how do I assign a unique ID for that object ? If that is not possible, then how can I "translate" the menu handle to this unique resource ID so it would compatible with the Win32 API functions ?
Regards,
sdancer75
|
|
|
|
|
If it is a dynamically created menu then it cannot have a resource id, since there is no associated resource. It would probably help if you showed the piece of code that you are having a problem with.
|
|
|
|
|
You can definitely assign IDs to dynamically created menu items, see the CMenu::AppendMenu[^] method.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
From MSDN
AppendMenu function
7 out of 10 rated this helpful - Rate this topic
Appends a new item to the end of the specified menu bar, drop-down menu, submenu, or shortcut menu. You can use this function to specify the content, appearance, and behavior of the menu item.
That's correct, but if the menu is a brand new dynamically created popupmenu and I dont want to append it to an existing menu, there is no point to use AppendMenu, right ?
sdancer75
|
|
|
|
|
Not right. When you dynamically create a menu, it has no items: you have to use the AppendMenu method to add, at least a menu item to it.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
I suspect you are getting your terminology wrong, and as suggested please show the code that you are having problems with, and why you think it needs this id.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
