Support Board
Date/Time: Tue, 17 Feb 2026 04:16:34 +0000
[Locked] - Understanding Sierra Chart Work to Port To Linux and Windows is Doomed
View Count: 1333
| [2025-12-31 05:57:51] |
| Sierra_Chart Engineering - Posts: 22877 |
|
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: 22877 |
|
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: 22877 |
|
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 5% 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: 2026-01-01 20:02:52
|
| [2025-12-31 23:11:14] |
| Sierra_Chart Engineering - Posts: 22877 |
|
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: 22877 |
|
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 |
| [2026-01-01 20:33:07] |
| Sierra_Chart Engineering - Posts: 22877 |
|
Looking over MFC again, at most Sierra Chart was ever using about <5% of MFC classes. And now it would be less than 2%.
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: 2026-01-01 20:33:27
|
| [2026-01-03 20:41:30] |
| Sierra_Chart Engineering - Posts: 22877 |
|
Regarding this thread: OS Timers vs SC Timers discussion again... SC Timers chart update limitations We have shown the extreme speed of Sierra Chart and responsiveness, even with Sierra Chart timers. Completely refuting, the user post. Although you really do not see, the extreme speed in the videos we provide, because the update interval of Sierra Chart is far faster than the video capture interval. We are using Windows 7 versus Windows 11. Maybe that is the reason why we are getting much better update performance. We are not sure. So does this prove Windows 11 is terrible? Not really sure. Certainly windows 11 is terrible. But is it really bad in other ways including, overall performance. Not sure what to say. Clearly we are doing much better, with older hardware and windows 7, as compared to what the user is demonstrating with a high-performance AMD system with windows 11. 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: 2026-01-03 20:48:17
|
| [2026-01-03 21:09:24] |
| Sierra_Chart Engineering - Posts: 22877 |
|
What we can say in summary regarding the prior post, is as follows. And we have talked about this in this particular thread here: Microsoft Windows Is Truly Garbage. An Abomination. Software That is Woke and Insane Windows is not a serious, or trustworthy or high-performance operating system. It is not acceptable for business use, it is not acceptable for trading use. It is not acceptable even for server use. It is not trustworthy. Microsoft cannot be trusted. Microsoft, is an abomination to the world. How much suffering and wasted time are they inflicting upon, users both, personal and business with all of their updates and all of their problems. And we know Sierra Chart is not perfect but we are nowhere even close to as bad as Microsoft is. And we do not have bad, wicked or evil intentions but only good intentions. So therefore, the other choices would be Linux or Mac. And Sierra Chart will be ported first to Linux, and then we will look at Mac but apparently Linux programs can run on a Mac? So traders are going to have to get off of windows, and onto Linux or Mac, and use Sierra Chart. Which we will we will ensure has superb performance on Linux. At least Linux will be the first choice. Have a look at this video regarding Linux Mint: https://www.youtube.com/watch?v=g1XIYBYLvVc Something to think about. Windows is doomed. Microsoft is going to be gradually becoming history. There is no possibility of reform at this point for them. They have destroyed themselves. 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 |
| [2026-01-04 23:50:46] |
| TonyCipriani - Posts: 78 |
|
I understand you guys have a stance on Microsoft. A lot of us I'm assuming have Windows desktops/laptops. You mentioned, "Traders are going to have to get off of Windows, and onto Linux or Mac, and use Sierra Chart."; are you saying when that time comes that we won't be able to use Sierra Chart at all on Windows, and that we'd have to get another machine that has a Linux base instead? It would be great if Sierra Chart continues to have great usability with Windows PCs, as Microsoft 365 products like Excel, Word, etc. are heavily used. Based on my research, for multi-monitor workflow with different operating systems, it could be time consuming to transition between the two even with KVM switches unless one has the highest quality product. If Windows Operating System does become doomed, I think they'd still do well since it's only ~10% of Microsoft's revenue. |
| [2026-01-05 08:44:11] |
| Sierra_Chart Engineering - Posts: 22877 |
|
This thread was meant to be locked. It is now locked. No we are not saying this: are you saying when that time comes that we won't be able to use Sierra Chart at all on Windows,
Windows support will not be removed. 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: 2026-01-05 08:44:32
|
| [2026-01-05 16:24:09] |
| Sierra_Chart Engineering - Posts: 22877 |
|
Also we want to explain, it would be exceptionally stupid to the maximum, for us to be removing support for Windows. The statements made, never had that as the intention. Not at all. We are not going to be removing support for Windows. This would be totally and completely stupid and we are not going to do that. 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 |
| [2026-01-10 23:16:33] |
| Sierra_Chart Engineering - Posts: 22877 |
|
Some questions have come up, where some users are thinking that maybe support for Windows is going to be removed based on some of our statements. This is just not going to happen! And it is an annoyance of a question because inherently we know the complete stupidity and burden of doing this. Once again this is not going to happen. Window is indeed is not a serious, trustworthy or legitimate operating system at this point in time. A combination of a laptop and Windows 11, running on that laptop and with a battery is not a viable product. This is based on our own experience. Others may have different experiences, but this is our own experience and we would never even consider such a configuration. Businesses who use windows, cannot be burdened with problems, upgrades, interface changes requiring lost productivity and retraining, usability issues, stability issues and on and on and on with all the mayhem that Microsoft is creating. There is no other choice, but for businesses to begin to abandon Windows, This will need to happen gradually, it may take a very long time, maybe even 10 years. It is clear this shift is happening and going to continue to happen. The benefit is maintaining stability, consistency and usability, with IT infrastructure. And a cost savings. A huge cost savings. Not only the money saved on windows, but also gains in productivity, by eliminating all of the problems associated with Microsoft products and changes from those products. Libre Office is a great alternative to Microsoft office products. Internally, for the little amount of use of spreadsheet, and word processing we do, this is what we use: Libre Office And internally, we gradually are going to move our server processes off of windows and onto Linux. We are going to allow, two years for this. Our web services already run on Linux and that will not change. The reason Sierra Chart will always continue to support Windows is that there is nothing to gain by removing support for Windows. Windows does not create any more of a support burden upon us. Actually would be more of a support burden if we removed windows. And we do not have to pay Microsoft any money. Microsoft is actually a huge beneficiary, of all of the development that has been done on windows over the decades. It would also be a lot of work to remove support for Windows, and really there is simply nothing to gain from this. There simply is nothing to gain by doing this. And also inherently even though the internal architecture and code base of Sierra Chart is being changed to eliminate Microsoft specific code, in the non-OS layer, a lot of areas of that code, still architecturally or syntax wise, are modeled around the Windows API. Take for example when we set the position of a window. This is one of the function calls: else if (m_MDIWindowPlacement.WindowState == c_Window::WINDOW_STATE_NORMAL
&& !m_MDIWindowPlacement.NormalSizeWindowRectangle.IsRectNull()) { SetWindowPos({}, m_MDIWindowPlacement.NormalSizeWindowRectangle.left, m_MDIWindowPlacement.NormalSizeWindowRectangle.top, m_MDIWindowPlacement.NormalSizeWindowRectangle.Width(), m_MDIWindowPlacement.NormalSizeWindowRectangle.Height(), COMMON_WINDOW_POSITION_FLAGS); } SetWindowPos calls into our c_Window class (not provided here) and that then calls: bool n_OSLayer::c_WindowWrapper::SetWindowPos
( const c_WindowWrapper& hWndInsertAfter , int XPosition , int YPosition , int Width , int Height , unsigned int uFlags ) const { return ::SetWindowPos ( m_WindowHandle , hWndInsertAfter.GetHandle() , XPosition , YPosition , Width , Height , uFlags ) != FALSE; } The basic point of this, is that the original call to SetWindowPos has a syntax very similar to the windows API call. The only difference is that we do not work with this type directly: HWND. There is a wrapper class that goes around that type. So the main code base of Sierra Chart, is isolated from the windows API. However, a lot of the code, still has syntax and modeling closely resembling the windows API. So Sierra Chart still inherently is designed to work with windows but can be without great difficulty ported to other operating systems and used on other compilers. So there is simply nothing to gain by removing support for Windows even though hypothetically even if we did remove support for Windows, Sierra Chart still would have an internal architecture design that allows it to be use with windows very easily anyway. Now there is a very firm rule which has existed, for probably about more than 10 years now. And that is that we refuse to use any new functionality, beyond what is available in windows 7 in order to maintain compatibility with Windows 7, and there are other important reasons as well for this. The fewer windows API functions that Sierra Chart uses in the operating system makes it easier to port to another operating system. So we will only use standard operating system functions. And it exposes Sierra Chart to less operating system issues using a smaller number of functions. Software compatibility layers like wine, are going to work very reliably for programs like Sierra Chart because we use only the most basic and limited amount of functionality in the windows API. There is one exception to this, and that is the network I/O layer in Sierra Chart does use the highest performance interface, that the windows API has for network I/O, because high-performance is absolutely critical in that area. In the case of file I/O, the standard API functions for file I/O do deliver good performance, and we always write to files, on a background thread and any significant reading, is also done on a background thread. 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: 2026-01-10 23:30:17
|
To post a message in this thread, you need to log in with your Sierra Chart account: