Support Board
Date/Time: Thu, 01 Jan 2026 17:15:45 +0000
[Sticky] - Understanding Sierra Chart Work to Port To Linux and Windows is Doomed
View Count: 189
| [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
|
| [2025-12-31 19:08:16] |
| Sierra_Chart Engineering - Posts: 22130 |
|
We always do our best to help users, even when we say no, never, no possibility. We will always think of a solution. Look at this thread: Input DisplayOrder breaks with non-contiguous inputs Coming up with a solution New Year's Eve and getting it released before midnight. Always doing our best to help users. Now compare that, with Microsoft who wants to assimilate you into the Borg. 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 |
| [2025-12-31 22:58:58] |
| Sierra_Chart Engineering - Posts: 22130 |
|
It just occurred to us, that our current and previous statements regarding the use of MFC (Microsoft Foundation Classes) within Sierra Chart where/are likely misleading or could be easily misinterpreted. MFC, covers a large amount of functionality. It wraps most of the windows OS and provides data containers, classes for file I/O. Classes for working with date and times. Probably network I/O classes. Graphics classes. Certainly classes, for user interface components like windows. Classes for strings. MFC has a lot of functionality. You can see everything here: https://learn.microsoft.com/en-us/cpp/mfc/hierarchy-chart?view=msvc-170 As we look through that, Sierra Chart has used hardly/barely any of that. Sierra Chart has used definitely less than 10% of that . We have always kept the use of MFC to an absolute minimum. MFC was only used, in a limited way, because in the beginning, we needed to support OLE for a spreadsheet control we were using. Something like that. Sierra Chart has always used a very small subset of this MFC functionality. Primarily classes for user interface components like windows and dialogs. For example, we never used any of the data containers like CArray. We always use C++ STL. So really it was never fair for us to ever say or imply that Sierra Chart is an MFC program. At this time, probably about 98% of Sierra Chart is not MFC. And there are also string classes, and functionality part of the standard C++ library. For this last part regarding C++ strings and related functionality, Sierra Chart does not use any of this. In the past there was some limited use of std::string but not much. Even functions like sprintf, Sierra Chart does not use. We used to, but that was replaced about 9 years ago with higher performance, functions to convert numbers to strings. And we have our own string class we have used for more than 10 years. We may have used a MFC file class but that was eliminated, probably like about 10+ years ago. Gradually the use of MFC in Sierra Chart has become less and at this point, it is very little. The only thing remaining is some remaining dialog windows. This is all. And of course the main message loop, runs within MFC. 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:02:12
|
| [2025-12-31 23:11:14] |
| Sierra_Chart Engineering - Posts: 22130 |
|
We are also aware of the problem, where the Chat window when opened, under Wine, it just freezes itself and the entire program. We thought this was because the chat ran on another thread. But we added an option in Global Settings >> General Settings to not use a secondary thread and instead the primary thread for Chat but that did not resolve the problem. We are going to figure out why this happens and get it resolved as quickly as possible. We just need to figure out how to do debugging on Linux, of a windows program. 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 |
| [2025-12-31 23:21:38] |
| Sierra_Chart Engineering - Posts: 22130 |
|
Sierra Chart also does not use .NET, or Java, or C#. It is high-performance native C++ unmanaged code. With direct calls into the underlying operating system for only the most essential functionality. Nearly everything, is written ourselves from scratch other than, encryption and compression. 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 |
To post a message in this thread, you need to log in with your Sierra Chart account: