Support Board
Date/Time: Thu, 01 Jan 2026 17:15:09 +0000
Post From: Understanding Sierra Chart Work to Port To Linux and Windows is Doomed
| [2025-12-31 05:57:51] |
| Sierra_Chart Engineering - Posts: 22130 |
|
Note: The below was cleaned up in the evening of December 31. There were some dictation errors previously. We have long realized the windows operating system, is in a massive state of deterioration, and now the masses, are awakening, to the wickedness of that system, and the utter derangement and lunacy retardedness, and contempt towards their users, that Microsoft has, and the people working on it. It is no longer an operating system. It is an instrument of domination and control (In particular referring to Windows 11, to the extent it even works properly). Their intent is to assimilate you into the Borg. We do not make that statement for fun. It is a very serious statement and a factual statement. We still use windows, but internally we run significantly older versions of windows. And we use Visual C++ 2019 professional. Many people are moving away from Microsoft Windows, to other operating systems like Linux, and Mac. This is good. There is no other choice. We are doing the same. Although gradually. We have long talked about Sierra Chart supporting Linux. A significant percentage of our users do use Sierra Chart successfully on Linux, and also the Mac, by using the compatibility software layer called Wine. Direct Linux compatibility, will mean Sierra Chart will function flawlessly, and with higher performance directly on Linux. And, periodically there are statements we make that indicate that we are "working" towards this. We want to explain, what exactly that means, when we are working to support Linux or port Sierra Chart to Linux. We have explained this in the past, but we just want to restate it clearly and right here. To this day, we have not done any work, to actively "port" Sierra Chart to Linux. This does not mean there has not been a major progress towards supporting Linux. Or other operating systems. There has been major progress. And in 2026, is going to be finally a year that there will be potentially a direct Linux version. Although, we have, developed a Linux program, for processing exchange multicast data feeds. It is a bridge between a multicast feed, and a TCP/IP stream. This will allow us to process exchange fees, on Linux, very efficiently with no packet loss. Not that we lose packets on windows, we do not although there are some packets, mostly unimportant packets, lost for US equities. Very very small percentages and nothing of any consequence. Nevertheless, we always want to be perfect with everything that we do. There is no packet loss, with CME data. It makes complete sense, that the Sierra Chart code base, is moved away, from anything that is Microsoft specific. There are different reasons for this. One reason is Microsoft functionality, is substandard and garbage in many ways. We can develop and have developed, much higher performance, functionality as compared to what Microsoft has or even the C++ standard libraries have. For example, Sierra Chart has its own string class. This is a very high-performance string class, which has been in use, for probably like 10 years. Sierra Chart, uses what is called Microsoft Foundation Classes (MFC), but at this point in time as of this writing, the use of MFC is very little. There is not much more of that remaining in the program. Very little. And really from the beginning and many many years now, there has been minimal use of MFC. And MFC has only been used by Sierra Chart for user interface components. Nothing else. For more detail, refer to: Understanding Sierra Chart Work to Port To Linux and Windows is Doomed | Post: 432666 By removing MFC, it makes it dramatically easier to port Sierra Chart to another operating system. It is actually not reasonably possible unless we remove that. Other than MFC the only Microsoft specific code in Sierra Chart, are calls into the operating system. Those have now been isolated, into separate name spaces and classes. So when we port Sierra Chart to another operating system we just have to change code in one specific area. For example there is only one place, the CreateFile function is called. When we want to call the equivalent function in Linux, we just change that one place. So basically we are cleaning up Sierra chart and organizing the code, to eliminate MFC and to isolate operating system function calls, into their own name spaces and classes. This is not being done solely to support another operating system it is just making Sierra Chart a better more higher performance program. That is more flexible in many ways. For example, we are removing these old Microsoft based dialog windows not because we want to port to Linux, but because they are just garbage. Regarding the subject, refer to: Settings Windows Interface: New Chart Settings Window So major progress has been made, with the internal architecture and code base of Sierra Chart to design it in a way so it can be easily ported to another operating system and so the code base, is our own code base, and not, from other external libraries, or Microsoft specific code. We still do use external libraries like for encryption, and compression. This would include, Open SSL, LZ4, ZLib. This work is not being done, to specifically allow support for another operating system but just because it makes Sierra Chart a better program. And it needs to be understood, we are not doing this work constantly. There are other things we are doing. Answering questions about CME market data a policy (Insane), providing customer support, adding features to Sierra Chart, doing hardware infrastructure maintenance and upgrades, fixing issues, and improving the existing code, and doing data maintenance tasks. In 2026, we expect, MFC to be completely removed. The most recent work, by changing the main windows and child windows of Sierra Chart away from MFC, is a huge move forward away from MFC. This was a very major development task. The next step would be, to write an interface/management layer and/or, through conditional compilation, adapt OS specific function calls to Linux. That was the original plan. Now we have discovered, that there is a Wine library, to make a program that uses the windows API, which Sierra Chart does, to be natively built for Linux: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-Guide This will work well for us, and be a good shortcut for Linux support. The only other thing we then need to do is to make direct function calls, for network I/O, to Linux, and for file I/O. These two last things, network I/O and file I/O, are areas, where Sierra Chart needs very high performance. Everything else, the Wine library will be just fine. We would expect all three of these things to be done within a short amount of time. Maybe three months, after the removal of MFC. But we are not really sure. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2025-12-31 23:37:04
|