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

201–210 of 248 posts

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

#201

Post by cr0sh »

vardump wrote: post #15
Ididntdothis wrote: post #11

Windows 3.1 and 16 bit would be a little too painful for me. Windows 95 was quite nice with 32 bit and preemptive multitasking though. I kind of miss this or Windows 2000.

NT4 was very nice, although no USB. Didn't crash and was smooth as butter.

Last time I "used" NT4 it was to set up a machine for a specific piece of software so I could test a SICK 2D LIDAR unit (one of the blue "coffee pot" units) I had purchased off Ebay; sometime around 2014/15 IIRC.

Initially turned out that it had been set to RS485 mode, and I didn't have an adapter, and I didn't even know if it worked if I was able to get it into that mode. So with the help of a sympathetic engineer at SICK, he had me send to unit to them and he reset it (to RS232) and tested it. When I got it back, I tested it with the machine again and it worked perfectly. He didn't charge me anything for the service.

You don't see that kind of support anymore - almost no company will say "yeah, sure, send us a unit you bought second-hand off Ebay to us and we'll take a look at it, fix it, etc - and no charge to you, either - even though you're just a hobbyist and have no support contract" - it shocked me.

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

#202

Post by cr0sh »

coryrc wrote: post #37

> Therefore, if one wants to write an app using Windows OS standard APIs, WFW 3.11 is the oldest one can go back without putting in even more exponential effort. Hey, what's wrong with Trumpet Winsock? :-)

My thought too - but then I recalled - vaguely - the "setup" procedure for it - so "even more exponential effort" sounded a bit right...

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

#203

Post by efreak »

muststopmyths wrote: post #193
AnIdiotOnTheNet wrote: post #159

Earlier quoted context omitted.

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

64-bit Windows has never supported 16-bit. This has nothing to do with "whoever is running Windows development these days" Back when 64-bit Windows came out (with XP and Server 20003), the adoption was pretty small since most applications were not 64-bit and did not need 64-bit address spaces. Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64…

Wasn't 64-bit windows 2k/64 itanium-based, not x86-based? If so it would have required supporting existing binaries compiled for a different architecture. My understanding is that the only 16-bit support in 64-bit windows is a few specific loaders for things like 16-bit installers (please correct me if I'm wrong)

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

#204

Post by efreak »

yeokm1 wrote: post #6
dboreham wrote: post #3

Earlier quoted context omitted.

Prior to online search engines there were similar offline resources such as the MSDN CDs.

Agreed. But such CDs are tough to locate today.

The Eye might have these, they have a bunch of old Microsoft/msdn related stuff.

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

#205

Post by jdsully »

muststopmyths wrote: post #193
AnIdiotOnTheNet wrote: post #159

Earlier quoted context omitted.

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

64-bit Windows has never supported 16-bit. This has nothing to do with "whoever is running Windows development these days" Back when 64-bit Windows came out (with XP and Server 20003), the adoption was pretty small since most applications were not 64-bit and did not need 64-bit address spaces. Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64…

Virtual 8086 mode was gone, but they could have just emulated it. The real reason 16-bit apps don't run is Microsoft didn't think it was worth the effort.

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

#206

Post by whateveracct »

shaan7 wrote: post #140
bluedino wrote: post #133

Earlier quoted context omitted.

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".

Fixed costs vs variable costs. That fixed cost of Electron does come with some sizable benefits, so if you don't take advantage of them ofc Electron will just be bloat.

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

#207

Post by clarry »

itronitron wrote: post #164
rvanmil wrote: post #127

Earlier quoted context omitted.

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.

Thanks, I'm assuming there is some core application capability that people are getting from Electron. In terms of 'write once run anywhere' Java has that covered but doesn't offer a means to spec UIs with HTML/CSS, so if that is the deal killer then it would be nice if Java added that capability for applications. Edit >> looks like JavaFX WebView is a thing now, plus the jxbrowser embeds chromium in a Java App... not…

> 'write once run anywhere'

That's the biggest lie ever, with these newfangled "cross-platform" solutions.

I want to watch the guy who has to sit down and port electron to a platform it doesn't run on yet. It's just a few lines of code, right?

Java had the same problem, everyone who ran Linux in early 2000s remembers. It's still not something I would want to port, but at least it runs on more systems ootb than electron.

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

#208

Post by otabdeveloper2 »

Const-me wrote: post #85
bonzini wrote: post #47

Earlier quoted context omitted.

Qt and to some extent GTK+ come close. GTK+ can be programmed in Vala which is a fine language that transpiles to C and supports idioms such as asynchronous programming.

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

> Both are C++: developers are more expensive to hire, and stuff takes more time to develop and debug.

Have you seen the state of Javascript 'ecosystem' and job market?? Both statements are false.

The real reason is that C++ toolkits don't have platform and device independence. HTML and CSS are really good and powerful design tools, especially compared to composing raw pixels like you'd (essentially) be forced to do with Qt and GTK.

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

#209

Post by WorldMaker »

yeokm1 wrote: post #2

I built a Win 3.1 app during a company hackathon just for fun. Here, I detail learnings and process for how a new old app can be created with the aid of modern tools and hindsight of old technologies. And perhaps what lessons can it offer us today. Without the benefit of modern libraries and languages, I had to read up and take care of many low level details, socket programming, HTTP, JSON parsing, UI design in code…

Some of your UI might have been easier to build with VB than VC. VB4 was the last version to support 16-bit Windows applications. You might have better luck finding VB6 libraries/code-samples that run in VB4 than you had finding C89 libraries.

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

#210

Post by vardump »

1996 wrote: post #197
vardump wrote: post #15

Earlier quoted context omitted.

NT4 was very nice, although no USB. Didn't crash and was smooth as butter.

I find this history so super interesting. Have you kept a nt4? Do you still use it? What do you think is the closest equivalent: win200, reactos??

No, I haven't used it since early 2000. Windows 2000 was the successor, also a good release. I guess both are pretty close to what NT4 was.
Post reply on HN