Live data from Hacker News

Building a new Windows 3.1 app in 2019: A Slack Client

yeokhengmeng.com

151–160 of 248 posts

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#151
post #140

Earlier quoted context omitted.

His point is that this bare bones get/post app in Electron will be much, much "larger".

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.

Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution

And just because it's electron doesn't mean it's inherently Cross-Platform look at discord for example It took too long for a initial desktop client to be released and then it ha issues with things like screen sharing not working as expected

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#152

Earlier 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…

You can also write GTK+ in JavaScript for that matter, or Python. Vala is a very underrated language though and it should be very easy for a good JavaScript programmer to pick it up.

Enough languages have bindings for GTK or Qt to make it viable

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#154

Earlier quoted context omitted.

The quality of Microsoft's own documentation has also fallen considerably; the latest nail in the coffin is that docs.microsoft.com thing that started to replace MSDN several years ago, that created tons of ridiculous fuckups in the "migration process". While doing that they also "open sourced" their documentation on GitHub, which to me sounds more like they're just trying to rely on free labour from the "community"…

MSDN was a gold standard in the 90's. Now you have tragedies like social.technet.com

The low quality of the technet "answers" are mind-boggling. Why doesn't Microsoft pull the plug on this?

Also, what's the purpose of the people who will answer nearly any question with a very low-quality (but wordy) answer? What are they getting from this effort?

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#155

Earlier quoted context omitted.

There is Delphi and Lazarus as open-source clone of it Lazarus can use the Windows API on Windows, gtk/qt on Linux, and carbon/cocoa on Mac. There is also a custom drawn mode that draws the GUI directly rather than using platform apis. That also runs on Android, but it not maintained anymore, so only up to Android 5 or something Delphi is supposed to run on Android and iOS. And Delphi 1 ran on Windows 3.1, so you cou…

There is Delphi and Lazarus as open-source clone of it Shhh! Ixnay on the Lazarusay. If people find out, I'll lose my magical secret weapon for blasting out little windows gui apps. Seriously though, if you ever find yourself needing a few buttons on a windows desktop that do simple things, Lazarus is amazing for whipping that up in a few minutes and still looking professional.

Agreed. I'm not a huge fan of Pascal, but it's better than JS and Lazarus makes knocking up a simple GUI trivially easy.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#156
post #103
post #80

Earlier quoted context omitted.

Because the element isn't valid for the stricter form of HTML that they use. Invalid elements didn't used to show up.

From what I recall of that era, it's the exact opposite: invalid elements (like ) are simply ignored, and their contents shown. That's how works: newer browsers which understand JavaScript know the element and ignore its contents; older browsers which do not understand JavaScript don't know the element so its contents are shown. The same trick is used for : browsers like Netscape which understand frames don't show th…

XHTML came after HTML 4.0, so it had its advent around the rise of JavaScript's popularity.

However, HTML 2.0, which you can find specified here [0], and it specifies the "ignore" behaviour. Short of spinning up an old VM, I think I'll trust that my memory hasn't failed me.

From RFC 1866:

> markup in the form of a start-tag or end-tag, whose generic identifier is not declared is mapped to nothing during tokenization. Undeclared attributes are treated similarly...

> For example: > foo

... > => ,"foo",,

,"..."

[0] https://www.w3.org/MarkUp/html-spec/

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#157

Earlier quoted context omitted.

MCU?

Think MCUs are of the kinds like Arduino and microBit. There are also SBCs where bigger and more power hungry devices like Raspberry Pi belongs to.

Super late, but the term MCU refers to the actual chip -- analogous to SoC for the main chip on a raspi.

You don't call the raspi an SoC, and it's debatable that you'd call a prototyping platform like Arduino an MCU. The MCU is the main Atmel AVR, Microchip PIC, or similar part that drives such a board.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#158

You 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

One of those things usually only people who've written printf format parser know.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#159
post #99

Earlier quoted context omitted.

Windows 3.1 apps are somewhat cross-platform because they can be run with Wine on Linux.

It's even better: 64-bit Windows doesn't support 16-bit Win 3.1 apps anymore, but you can still run them via Wine on the Linux subsystem.

It should be noted that WineVDM[0] will allow you to run 16-bit Windows applications on Windows without the Linux subsystem.

[0] https://github.com/otya128/winevdm

It would have been relatively straightforward for Microsoft to support 16-bit on 64-bit, but they decided not to. I can't help but feel that that is just more evidence that whoever is running Windows development these days hates everything that used to make it a good desktop.

Re: Building a new Windows 3.1 app in 2019: A Slack Client

#160
After 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.

Post reply on HN