r/crystal_programming

naqvis/CrysDA: Crystal library for Data Analysis, Wrangling, Munging

naqvis/CrysDA: Crystal library for Data Analysis, Wrangling, Munging

Not my project.

I discovered it while browsing Github. Seems like a nice effort so I'm sharing it on Reddit for more visibility.

The developer is also working on Cryplot (a plotting library that uses gnuplot under the hood), and CrysDA-Plot (an integration between the dev's two projects).

Hopefully, the developer finds the motivation and support needed to continue working on these projects.

github.com
u/Bassfaceapollo — 15 hours ago
▲ 4 r/crystal_programming+2 crossposts

Legacy 32bit app was OK on W11 Pro 24H2 strange behavior on W11 Pro 25H2

We have a legacy 32bit ERP Application from 2006 which is highly specialized and would be a huge lift to replace, financially and practically. The application was originally installed as administrator on WXP Pro SP3. We migrated it to W7 Pro, installed as administrator, and the only issue we had was local users group Users's permissions to the Program Files (x86)\Installation Directory needed to be bumped to Modify.

Now it's installed on W11 pro 24H2 as administrator, and the shortcut to launch the application is placed on \users\public\desktop. The backend for the app is Oracle 19c. Client is 11gR2. The app compatibility settings are at default. It works fine for all domain users.

From within the app, you can run Crystal Reports (XI) and print, export (to different formats, Excel and PDF are the most common), or preview the report to the screen, and then print or export from the preview screen. This all was working fine under W11Pro 24H2.

Our Windows updates are not under house control, so they are applied sporadically. Since the suspected trigger event 25H2, we've gotten a few (less than 10) tickets, where the user A chooses to preview a report, the preview screen appears, and then Crystal Reports asks for any required user input data, the Print button is clicked, and that’s it. The application stops responding, turns white, and then must be task killed. We’ve tried enabling logging in Crystal Reports with reg keys, but haven’t succeeded thus far in getting it to create logs. The application doesn’t write any logs we can find to the event viewer, and the only event recorded says xxxx.exe applicaion stopped responding. Application hang.

Troubleshooting, user A can print and preview on other workstations without issue. We’ve determined that it doesn’t have anything to do with which report file is called, they all hang equally. We think the hang is triggered by a call to the oracle client and are trying to get the Oracle Trace File Analyzer to look at some trc files we found on the workstation, and will continue to work that. As previously noted the backend is Oracle 19c, the workstation client is 11g. The application uses the 2.xx version of OCI. The user A can directly Print or Export the report (any report) without issue. It’s only the preview function that’s causing the hang. But wait, it gets better.

If a new (to that workstation) domain user B logs in on the very same machine, it works flawlessly. If you copy user A’s data out and whack his profile on the machine, and log him back in, same result, it works flawlessly, so that kind of rules out something with the installation or configuration. Pursuing the theory that it’s in the user registry hive, we have tried comparison tools but the volume of data they dump is daunting. I haven’t fed it to an AI yet, and would rather not, but it’s not out of the question.

For background, we are a SMB with only about 150 endpoints and the IT Department is me, a co-sysadmin, and a helpdesk guy. Workstations are HP600SFF, and we do not believe it is hardware or resource problem.

Edit: I'm aware the app is old. The company is aware the app is old, and needs to be replaced. However it is running on modern hardware, with modern EDR behind a modern network firewall. It works perfectly (for now) on 90+ percent of the endpoints. I've made them aware that M$ could deprecate it out of existence at any time, but is not generally in the habit of doing that without giving due notice.

TL;DR: 2005 Application Embedded Crystal Reports 11.0 (XI) migrated from W11Pro 24H2 to W11Pro 25H2 works to print or export, but hangs on preview, but only for the normal user of the workstation. Works fine for new users or if you replace the user’s profile with a new one.

reddit.com
u/PlsChgMe — 4 days ago

Mimer SQL driver for Crystal

Hi,

I just wanted to announce that I sat down with Claude the other day and we came up with a database driver for Crystal for the RDBMS Mimer SQL that is now released as a 0.1.0 version:

https://github.com/majorproblem/crystal-mimer
https://shards.info/github/majorproblem/crystal-mimer/
https://crystaldoc.info/github/majorproblem/crystal-mimer/

I would very much appreciate any comments or input on this driver.

reddit.com
u/Slight-Mousse1508 — 3 days ago
▲ 16 r/crystal_programming+1 crossposts

[Blog] Why the corporate world is stuck in a 'simplicity trap' – and why I’m betting on V.

It turns out that V (Vlang) is a unique choice for systems programming – it is simple to learn while remaining fast enough for system-level tasks.

When I consider the fact that many IT companies are primarily hiring developers for C#, Java, and JavaScript, while the demand for Go or Rust developers is significantly lower, it suggests one thing: a large part of the corporate world still relies heavily on established technologies and operating systems like Windows.

Here, we run into another interesting observation: many corporations build monolithic applications that they deploy to Azure and various containers (Docker). These then communicate via Kubernetes to maintain their ecosystem. Consequently, corporations spend huge amounts of money on cloud operations, keeping "heavy," not necessarily systems-oriented languages like C#, Java, and JavaScript, running.

Why is this the case? From a company's perspective, it is simply difficult to find someone who understands systems architecture and can program in it; a developer must understand hardware principles for the application to function efficiently.

This is where Go comes in—it is easy to learn and can be used to write system utilities. However, a problem arises here: Go is primarily optimized for backend requests, but it isn't ideal for system applications where there is a strong emphasis on minimal binary size. For that, we have Rust, which is safe but very difficult to learn. For many, Rust is so complex that even programming in C and C++ seems more accessible.

We find ourselves in a vicious cycle. Companies won't use C because it is prone to memory errors and it is hard to find experts who truly understand it. So, they prefer to hire developers who know C# or Java, where there is a massive ecosystem and where one simply "glues" code together for monolithic applications, for which corporations then pay significant cloud costs.

I used to wonder if there was even a language that could be fast to compile, produce small binaries, be easy to learn, and minimize the room for error. For production use in companies, such a language was essentially missing.

And that is where Vlang comes in. It meets all the requirements to become a low-maintenance tool for systems developers, ideal for creating fast and small system tools, or even backends. This changes the perspective on where the language is heading. I finally understand why Vlang is trying to build a large ecosystem of modules that can be easily integrated into one's own projects.

Vlang is a systems language that is easy to learn and creates binaries that can be incredibly performant. I have personal experience with this—as an experiment, I created an SSG program called Mustela, which really surprised me in this regard. It has a 1.3 MB binary and can be integrated with various other applications, thereby fulfilling the Linux philosophy.

However, when I try to promote the benefits of this language to corporations, I run into the fact that they often don't understand Linux principles and prefer to stick with languages that are cumbersome but, at first glance, "safer" for typical DevOps staff. It is such a vicious cycle that I find myself thinking that in 2026, we are not yet technologically mature enough to build programming on simplicity; it is all still in the building phase.

u/Intelligent-End-9399 — 10 days ago