Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yeokhengmeng.com

Post reply on HN
Print view View original

131–140 of 248 posts

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

#131

Post by bluedino »

gattilorenz wrote: post #98
j88439h84 wrote: post #54

Earlier quoted context omitted.

It's Beeware. https://beeware.org/ > Write your apps in Python and release them on iOS, Android, Windows, MacOS, Linux, Web, and tvOS using rich, native user interfaces. Multiple apps, one codebase, with a fully native user experience on every platform.

This sounds great, but it seems there's no out-of-the-box support for a rich text textbox? I have a python script that I want to deploy as self-contained app for windows and osx with a gui. Finding a framework that works, is decent to use, doesn't need hundreds of MBs of dependencies, and has rich text support is...not easy.

In the old days, you would just go on AOL's Windows programming section, find a shareware rich text control, and use that.

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

#132

Post by bluedino »

gmueckl wrote: post #104
loa_in_ wrote: post #96

Earlier quoted context omitted.

Did you get to work with a co-operative task scheduling? This version of Windows still used one I think. What's your experience if so?

Windows NT and Windies 95 were the first versions to have preemptive scheduling. Windows 3.11 and older would only switch tasks when he program requested new messages from the queue. Thus was totally annoying because most applications were written badly and had moments where they would go off and do things and not return to their message loop for several seconds or worse, hanging the entire system during that time. W…

And in Win95, your 16-bit apps could still do whatever they want as they were only cooperatively multi-tasked

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

#133

Post by bluedino »

userbinator wrote: post #42

Notice the binary size of the app is only 64KiB. In the demoscene this would be a disqualification as it's 676 bytes over the limit, but in this case I'll overlook it because of the sheer awesomeness of what you've done (and I'm sure trimming off 676 bytes wouldn't be too difficult ;-) More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most…

It's kind of silly compare a bare bones get/post to an entire app. This reminds me of my attempts to write an IRC client in an evening.

Creating a native Windows app to mimic the Electron Slack client would not be a trivial task.

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

#135

Post by ct520 »

Reading how he cheated with proxy. That was what I wanted to see. :( Had a client of a enterprise style company integrate into one of our products. Dude was the definition of cowboy coder so we often looked at logs. All I can say is wow - them logs for negotiating a https connection in BASIC..

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

#136

Post by dfox »

Iv wrote: post #12
ink_13 wrote: post #10

Reading this article and others by the same author on his travails of getting Windows 3.11 to install and then bridging it to modern(-ish) tech was like being transported back to the 90s when I was first learning about computers. Seeing those screenshots of the unmistakable Win 3.1-style dialogs was a real nostalgia hit. What a treat. 10 points (well, an upvote, I guess) for anyone who knows why the Windows DOS-mode…

I seem to recall that F1 and F2 had some sort of hard wired functions (that were printed on my keyboard) but I don't remember which they were...

There was never any that much hardwired functions for F1 and F2 on PC (apart for the convention that F1 is almost always help).

On the other hand there is a related issue: on DEC (and some other) terminals with LK201-style keyboards (which in turn inspired the "modern" PC/AT keyboard layout with F1-F12) the keys in positions of F1-F5 had fixed functions. This is the reason why there are about four different escape sequences across vt220-compatible terminal emulators for F5. There simply was not any DEC terminal that had F5 on its keyboard (F1-F4 are almost always mapped to PF1-PF4).

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

#137

Post by BubRoss »

rvanmil wrote: post #127
itronitron wrote: post #69

Earlier quoted context omitted.

What are your criteria for something being an Electron competitor?

It was more or less a rethorical question (I guess that’s why I’m being downvoted), because there is no competitor. If there was, then Electron wouldn’t be so extremely popular in the first place, and we’d see a lot more popular apps made with all the tools mentioned in the other replies to my post.

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 mentality for toy programs, but at some point the false sweeping statements get pretty old.

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

#138

Post by dfox »

egorfine wrote: post #122
devit wrote: post #109

If the target was just "Windows 3.1", he should have built a 32-bit app using the Win32s API [ https://en.wikipedia.org/wiki/Win32s ] It's also probably possible to use a current compiler, maybe clang or gcc, to compile such code (officially only up to VC++ 4.2 is supported), although it might require some hacks.

Win32s applications can be executed on a limited subset of hardware supported by Windows 3.x.

Which is moot point given that the Microsoft-supplied TCP/IP stack is essentially also Win32s application and thus only runs on the same subset.

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

#139

Post by pavlov »

agumonkey wrote: post #114

When I found a win95 box with tp7 on it, my first thought was to write 'modern' things on it. HTTPS, Haskell... I starter writing a lisp. Didn't finish sadly. Because i love the idea of bridging 'old' with the good parts of 'new'

Though Lisp is much older than Windows 95 of course :)

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

#140

Post by shaan7 »

bluedino wrote: post #133
userbinator wrote: post #42

Notice the binary size of the app is only 64KiB. In the demoscene this would be a disqualification as it's 676 bytes over the limit, but in this case I'll overlook it because of the sheer awesomeness of what you've done (and I'm sure trimming off 676 bytes wouldn't be too difficult ;-) More seriously, this is an excellent proof-of-concept that a Slack client does not need to use hundreds of MB of RAM and consume most…

It's kind of silly compare a bare bones get/post to an entire app. This reminds me of my attempts to write an IRC client in an evening. Creating a native Windows app to mimic the Electron Slack client would not be a trivial task.

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