snprintf() may not be C89, but fgets() sure is.
Noted. Will update my blog post!
Building a new Windows 3.1 app in 2019: A Slack Client
61–70 of 248 posts
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#62Earlier 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.
That's cross platform for Windows, Mac and Linux, but what about Web, Android and iOS?
Xamarin and Uno Platform
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#63> 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? :-)
Trumpet Winsock is not by Microsoft :P
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#64Related: winevdm makes running 16-bit apps on 64-bit Windows possible: https://github.com/otya128/winevdm
Oh I did not know about this! I just based my understanding from the official Microsoft documentation. Thanks!
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#65As a side note, since TFA mentions you can't run 16b apps on 64b Windows, I'd like to mention that otvdm/winevdm actually allows you to do it by running Win16 apps on Win32 using Wine!
Thanks for raising this to me!
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#66Notice 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 feels a lot closer to write for MCUs if you write for 16-bit programs nowadays. The only difference is that MCUs are much more barebone and so less managed, but the constraints set by hardware however is the most distinctive common spot.
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#67Earlier 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.
That's cross platform for Windows, Mac and Linux, but what about Web, Android and iOS?
That's exactly what your users don't want you to do!
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#68Earlier quoted context omitted.
Agreed. But such CDs are tough to locate today.
Borland's compilers had the best documentation. They included a much of the MSDN API reference in their built-in help files.
Hmm. Borland and Watcom compilers came up in my research. Will look into them for help next time!
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#69Notice 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…
> 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 of a modern CPU core to provide its basic functionality. If you’re so sure that this is possible, then where is the Electron competitor which allows us to build cross platform applications like this, with the same levels of productivity and a consistent and decent user interface? No…
What are your criteria for something being an Electron competitor?
Re: Building a new Windows 3.1 app in 2019: A Slack Client
#70Notice 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 feels a lot closer to write for MCUs if you write for 16-bit programs nowadays. The only difference is that MCUs are much more barebone and so less managed, but the constraints set by hardware however is the most distinctive common spot.
MCU?