Building a new Windows 3.1 app in 2019: A Slack Client
171–180 of 248 posts
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#172> The stack size of a 16-bit program is typically 4-6 KiB with a similar size for the heap. This is smaller than the size of the HTTP reply + JSON returned by Slack! Maybe this would be a good opportunity to stop for a moment and reflect about whether or not the industry is really moving in the right direction.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#173> Also, we can’t write our code directly on the Windows 2000 VM as it has limited software support for modern IDEs like Visual Studio Code not to mention security issues. I'm guessing that Visual C++ 1.52 has no code editing capabilities like Visual Studio?
I also use Git and sourcetree and they won't run on Win 2K.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#174Re: Building a new Windows 3.1 app in 2019: A Slack Client
#175You could avoid the copy out of the JSON string by using a field width specifier in your printf formatting string. Those should be available in ANSI C / C89/90. currentToken = tokens[index]; tokenSize = currentToken.end - currentToken.start; if(tokenSize
In actual fact, I'll have to copy the data to a char array to be sent to display in the listbox.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#176You could avoid the copy out of the JSON string by using a field width specifier in your printf formatting string. Those should be available in ANSI C / C89/90. currentToken = tokens[index]; tokenSize = currentToken.end - currentToken.start; if(tokenSize
The printf is just for example code. In actual fact, I'll have to copy the data to a char array to be sent to display in the listbox.
> hence I need to use those values to copy out from memory to a separate char array for printing purposes. Certainly not so trivial.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#177Earlier quoted context omitted.
You are being downvoted because the idea that electron is the only way to get cross platform GUIs is absurd and comes from inexperience and a lack of research. FLTK, Juce and Qt are just some of the options for creating cross platform UIs that end up being much smaller and MUCH faster than electron. Electron is popular because people learn javascript and don't want to learn C++. I can't completely fault this mentalit…
It's weird to assume that developers who use Electron do so because they are ignorant, incompetent and lazy. The truth is, everybody knows about Qt, GTK and so on, and everybody knows Electron is heavy but you have to be realistic. As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time, or do you go for the solution which, while not ideal, allows you to deve…
I don't think I said all that
> As a company do you want to spend that much money hiring a ton of C++ developers over a much longer period of time,
This I think is a big assumption. Making a GUI isn't really that difficult. Most of the time in a program doesn't go into making the actual UI. I never hear someone who is experienced in making UIs say that electron saves them so much time, it is always people assuming it takes an army of C++ people to do what one person can do with electron, which is bizarre, especially over the course of something that is more than a prototype.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#178After the first few paragraphs, I was most eager to see how he managed to handle modern TLS on Win3.1. Last time I wrangled with vintage stuff near that timeframe, that was the toughest part. Alas, he "cheated" for it with a proxy app. Can't say I blame him, since it's probably about as much work over again to get modern TLS 1.2 working on such an old Windows.
Seems to me you'd pretty much have to write a simple TLS 1.2 or 1.3 client by hand, or port an existing simple implementation.
But yeah, makes sense as it would be way too much work.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#179Re: Building a new Windows 3.1 app in 2019: A Slack Client
#180Earlier quoted context omitted.
> Qt and to some extent GTK+ come close Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug. I'm proficient in C++ (programming for living since 2000), but I wouldn't pick the language for 2D GUIs in 2019. > GTK+ can be programmed in Vala Picking a non-mainstream languages is risky. Harder to find developers. Way more likely to find bugs in the toolchain and these can e…
but I wouldn't pick the language for 2D GUIs in 2019 Which one would you recommend?
Cross-platform story is complicated, though. I have good experience creating a custom GUI framework for embedded Linux: drm/kms, gles, NanoVG, [DllImport], everything on top is custom C# code in .NET core 2.2. But that approach is not for everyone. I only needed 10-15 screens with simple GUI on them, it’s a 5” touchscreen with no other user-facing devices. Creating more advanced UX this way would consume too much time.
There’re Avalonia and Xamarin. Didn’t used them at that time because I needed full-screen GUI for a single-application Linux, without any desktop environments or user mode OS components. For desktops and especially mobile apps they might work OK.
It’s unpopular opinion here, but I think Electron is not that bad for GUI, esp. when writing TypeScript instead of JS. I think it’s similar story to Unity3D or PHP: low entry barrier attracted inexperienced programmers, then the whole ecosystem is judged based on the output of these inexperienced people.