191–200 of 248 posts
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 :)
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.
Earlier quoted context omitted.
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 mak…
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. They figured, rightly, that by the time x64 became widespread, 16-bit would be obsolete.
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…
Don't believe I said otherwise.
> This has nothing to do with "whoever is running Windows development these days"
> Microsoft saw the opportunity to kill at least one backward compatibility burden by not even trying to support 16-bit for x64.
These two statements are at odds. Microsoft used to take compatibility extremely seriously. It would have been relatively trivial to allow 16-bit applications to run, and obviously there is desire to do so since WineVDM exists, they just arbitrarily decided not to.
I suspect this is because they've become infected with developers who use Linux a lot and think nothing of breaking compatibility every release, let alone in cases like this.
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..
Earlier quoted context omitted.
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
>Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution They could but finding engineers with that kind of experience would be harder and cost a lot more. Far easier to retrain web frontend engineers.
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.
Have you kept a nt4? Do you still use it? What do you think is the closest equivalent: win200, reactos??
Earlier quoted context omitted.
>Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution They could but finding engineers with that kind of experience would be harder and cost a lot more. Far easier to retrain web frontend engineers.
It isn't like Qt is some bizarre arcane wizardry. You give a web developer a few days and they can productively be contributing to a Qt app.
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…
We use Visual Basic 6 for a lot more than we should at work...going back to that from using Python, Ruby, and even PHP was a shok. I thought porting a Python script to VB wouldn't be a big deal, but like you said, things youtake for granted like JSON and certain dictionaries are just lacking.
Not too long ago I remarked here on HN that I expected VB6 programmers might become in demand in the future (when, I don't know), similar to how COBOL programmers were/are.
Basically, for the need to convert apps, written internally for a business, from VB6 to something else (likely to VB.NET or C# - maybe on Mono - but there are other options too).
I expect this to happen when Microsoft finally kills off the VB6 runtime DLL - but so far they haven't; from what I understand, it's still available in Win10...