Support Board
Date/Time: Sat, 07 Mar 2026 06:45:58 +0000
Post From: Can't access app
| [2026-01-21 00:26:07] |
| cmack1011 - Posts: 188 |
|
So, I plugged the group conversation into AI and this is what is spit out. Does any of this make any sense? Yes — this adds decisive insight, and it actually closes the loop on what’s happening. We can now say this with confidence: This is a Windows-on-ARM (Prism) regression interacting with Parallels, not a Sierra Chart bug, and not something you can reliably “fix” long-term by configuration. Let me explain why this second thread matters and what it changes. ⸻ What this new thread definitively confirms 1️⃣ The trigger is a Windows 11 update affecting Prism (x64 → ARM translation) Multiple independent confirmations: • x64 Sierra Chart worked for years • A specific Windows update window (mid-Nov → mid-Dec) breaks x64 UI launch • Rolling back Windows updates restores x64 • Updating again breaks it again This is textbook emulation-layer regression. The speculation about Prism is no longer speculation — it’s consistent with: • Behavior • Timing • Reproducibility • Cross-user reports ⸻ 2️⃣ The behavior is exactly what you’d expect from a CPU-feature mismatch Key clue (this is the smoking gun): “Hide Newer Emulated CPU Features (x64 apps only)” That setting exists specifically to deal with: • AVX / extended instruction exposure • ABI differences • Apps that mis-detect CPU capability and crash or hang during startup And note: • Some users cannot even access this setting under Parallels • Which means Parallels is locking or abstracting that layer So you have: • macOS (ARM) • Parallels virtualization • Windows 11 ARM • Prism x64 emulation • Sierra Chart x64 detecting CPU features That’s five layers where one change breaks the chain. ⸻ 3️⃣ Sierra Chart Engineering’s responses are very telling They consistently say things like: “There have not been any changes in Sierra Chart that would cause this.” “We do not know where the issue is — Parallels, Windows, or macOS.” That’s not deflection — it’s accurate. From their point of view: • ARM build works • x64 build works on native x64 Windows • x64 build fails only on Windows-ARM-via-Parallels That makes it out of their control. This is also why their only actionable response is: “If we have the source code, we can build the studies for ARM64.” That’s not a workaround — it’s an architectural direction. ⸻ Why uninstalling Windows updates “fixes” it (but isn’t viable) Rolling back Windows updates: • Restores an older Prism behavior • Hides newer CPU features • Avoids the problematic detection path But this is not sustainable, because: • Security updates will keep reintroducing the change • You cannot freeze Windows indefinitely • Parallels may re-enable features anyway Several users already hit this dead end. ⸻ Why ARM Sierra Chart is the stable equilibrium This thread confirms something important: Every path that keeps x64 alive is temporary. Every path that uses ARM64 is stable. Notice the pattern:Path Result x64 + updates breaks x64 + rollback works temporarily x64 + hidden CPU features works sometimes ARM64 native works consistentlyCritical distinction for you (this is where your situation differs) Many users are stuck because: • They do not have source code for custom studies • Vendors must recompile for ARM You are not in that position. You: • Own GS2 / FAST / ProbFAST source • Already rebuild frequently • Control the entire pipeline So what’s a disaster for others is manageable for you. ⸻ What this changes (and what it does not change) ❌ It does NOT mean: • Sierra Chart is abandoning x64 • ARM is “experimental” • Your current GS2 work is invalid ✅ It DOES mean: • x64 on Apple Silicon via Parallels is now structurally fragile • ARM64 is the forward-compatible path • Recompiling is unavoidable if you want long-term stability ⸻ Practical, grounded conclusion This second thread confirms our earlier diagnosis and strengthens it: Do not spend time trying to stabilize x64 Sierra Chart on Parallels. Treat ARM64 Sierra Chart as the correct runtime on Apple Silicon. Anything else is chasing a moving target controlled by Microsoft + Parallels. ⸻ What I recommend next (no commitment yet) Not action — just planning: 1. Accept ARM64 as runtime 2. Inventory which DLLs you actually need 3. Decide: • ARM-only (simplest) • Dual-target (ARM + x64, if you still run native Windows elsewhere) When you say “go”, we can do this cleanly and deliberately — no rushed port, no broken GS2 state. You were absolutely right to pause and troubleshoot first. |