Propeller Tool not updated?

Comments

It's really easy to write WIN32 applications that don't handle system wide display scaling well (aka adjusting the DPI settings in the Display control panel). It takes some extra work to do it correctly. Using absolute sizes and offsets, doing "owner draw" things without accounting for it, etc.

That extra work is why a lot of Windows applications have font sizing or layout issues when scaling isn't at 100%.

Really now. So I can write a Win32 application that correctly supports display scaling, and have it used on any implementation of Win32?

That is news to me. If there is continuity of OS on a given CPU given compatibility of the OS it is best practice to make applications that support versions of the OS that are at least 20 years old, unless there is a very good reason not to (like making heavy use of newer GPU that is unsupported in the older system), this assures the widest possible market for a given target OS. For Windows that means going to support at least Windows NT 4.0 and Windows 95 OSR2. And there are still people that use Windows 3.11 with Win32s, so to get the best market spread you would have to support Win32s on Win16 for your pure Win32 applications.

Now how do I write a Win32 application that correctly supports display scaling, will run on Windows 95OSR2, and does not need redundant code for seperate UI features for supporting display scaling vs supporting older systems?

Hoping for the Prop II. I like ARM, though need a Prop II to complement it.

davidsaunders,
That's not the issue that Heater is running into. It's not even relevant. I'm talking about Having an application work correctly with Display scaling on a given iteration of Win32.

I know there are issues when you start involving ancient revisions, but I pretty much only care about Win7 and newer, as should most applications. Win32 API has been pretty stable across these OS versions, and when it comes to the GUI stuff, if you code it correctly, then it will work correctly at any scale the users chooses in the Display Control panel.

Bringing up Windows 9x or NT stuff is pointless, Those are ancient and should not be running on any system that cares to be secure or even work at all. Yes, I know there are examples of it, those people doing it are failing.

Win32 API has been pretty stable across these OS versions, and when it comes to the GUI stuff, if you code it correctly, then it will work correctly at any scale the users chooses in the Display Control panel.

Problem is, given a not so old Windows application, I can mess with the settings in Win 10 to eventually get it scaled nicely. After some application and/or OS restarts.

Then, after plugging my Samsung monitor in and out, or whatever, everything goes to bonkers again.

Start messing with the settings again...

Nothing "sticks" the way I set it.

Of course, what works for one old app I need does not work for another.

Heck, even the desktop icons turn up on the Surface screen or my monitor at random. No matter how many times I drag them to the right place.

OpenSpin will handle files with ascii, utf-8, and UCS-2(the first page subset of UTF-16, which is what PropTool uses). It took a bit of special handling in the code to sort out, but it seems to work pretty well.
Internally, it converts them all into PASCII (a 256 character set which is basically ascii + 128 special characters), it also converts all newlines (0x0A) into carriage returns (0x0D). This is what Chip's compiler code works with.

MikeDYur,
The issue you are seeing with pasting and unicode is likely because the code handling pasting isn't properly handling the unicode. Possibly converting to ascii along the way or something similar.

davidsaunders,
That's not the issue that Heater is running into. It's not even relevant. I'm talking about Having an application work correctly with Display scaling on a given iteration of Win32.

I know there are issues when you start involving ancient revisions, but I pretty much only care about Win7 and newer, as should most applications. Win32 API has been pretty stable across these OS versions, and when it comes to the GUI stuff, if you code it correctly, then it will work correctly at any scale the users chooses in the Display Control panel.

Bringing up Windows 9x or NT stuff is pointless, Those are ancient and should not be running on any system that cares to be secure or even work at all. Yes, I know there are examples of it, those people doing it are failing.

Many systems that stay the ding off line (as I would expect most development systems do), are still running older versions of windows. So if you are writing a development tool it makes since to stick with the standard Win32 API that has remained unchanged since NT 3.5.

And you complain about the mention of Windows NT and yet state that you care about Win7 and newer, which are versions of Windows NT.

I see no problem with display scaling, so long as it works with applications that were written for older versions of the API that do not include display scaling. If they had it working correctly Heater would not be having the problem at hand, so it has everything to do with that issue.

Hoping for the Prop II. I like ARM, though need a Prop II to complement it.

That unicode warning comes when you paste unicode text into a document that was previously a different text format (usually ASCII). It seems that the source that you copied the MIT license from was unicode, while the destination file had been ASCII before pasting the unicode text into it.

Hoping for the Prop II. I like ARM, though need a Prop II to complement it.

MikeDYur,
The issue you are seeing with pasting and unicode is likely because the code handling pasting isn't properly handling the unicode. Possibly converting to ascii along the way or something similar.

Thanks, Once I had seen some corruption of my file it spooked me, I have enough trouble keeping things strait.

davidsaunders,
The Display scaling thing I am talking about has been in Windows for a very long time, it was around in the 9x versions and ancient NT versions. It was called different things over the versions, but it's doing the same thing.
It changes the DPI, such that the size of buttons, title bars, fonts, etc. are larger or smaller. It makes it so that when you run a 4K monitor your icons and text are not microscopic.

Yes, technically, Windows 7 is a "version" of NT, but there have been some pretty significant overhauls and changes since it was last called NT. Vista was a huge difference. Native 64bit is another huge difference. Calling Windows 7 and newer just versions of NT, is being silly.

And I don't care if you run offline, you still should be concerned with security issues in your OS, and those older versions have giant gaping holes in them. You also can't run anything built with the last 3 or 4 version of Visual Studio, the majority dev tool for native Windows apps.

You're living in a pipe dream if you think new applications developed today should be made to work on anything older than Windows 7.

His father told me that Windows NT was a reimplementation of DECs VMS for Microsoft by Dave Cutler.

In this modern world the first thing you need to do is get your stuff running on Linux. If it's good it will end up running on Windows. See Visual Studio Code (based on Electron) or node.js with the MS Chakra JS engine.

Should I expect that there will be a work around for PropellerIDE, or just be careful of what I'm working with. I cant begin to tell you how many times I had seen that warning in Windows. If I have to purge my spin library of suspect MIT license, I'll do it. But that will sure take some time.

Unicode is evil? As opposed to what? ASCII chauvinism? Unicode is just the necessary consequence of recognizing that there are languages that do not use the Roman alphabet, but that still deserve nearly equal footing in a digital world. Yes, it's messy and inconvenient for 8-bit dinosaurs. Get over it.

-Phil

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery

Not sure what you mean. Would it force everyone to comment in Esperanto?

I don't understand how forcing people to use ASCII would unite anybody. Say you had people from Mainland China using Hanyu Pinyin to express themselves in ASCII. Would people from say Taiwan be happy with it? No way. That's quite political even in Chinese language preschools here in America.

It's a nice bit of hardware. Very good for a lot of things. What I've done, for the people who choke on Post-Win 7 UX issues is load the classic shell and pin a few things they use all the time to the taskbar. They end up pretty happy. Interestingly, once I show them how the search / command bar works, and get their "Command Prompt" setup nicely, I don't hear much from them.

Recommended. Those things are very useful devices.

As for Windows itself, I'm staying on my "let someone else buy it" path. I'll gladly do the work, and often get left with a license for a variety of reasons. Usually, all I have to do is agree to some "just in case" support time, and I'm golden.

On that basis, it's a fine OS! I keep my Linux skills reasonably current too. Just hedging risks and costs with that. Mostly, since Vista, I've had very few troubles with Win OSes.

Re: 20 year old support

I suppose people can ask. I sure wouldn't expect much personally, not without paying. There are tools from that time frame too. Maybe if there is interest, people would pool money, or labor to get it done.

Rolling your own is a lot of work, but may pay off for a very long time too.

Comes down to what is worth what? I know some people who do support older era computing, various embedded, machinery. They've got some old hardware, libraries, things they've written to make whatever needs to happen, happen. They get paid well for it, or it's a hobby.

Very little grey area there. YMMV

I will tell you, I've got some stuff from the late 80's, and early 90's era archived myself. It's CAD / systems related code, some hardware, procedures, and the few times I've been called on that stuff, I made bank! Nobody else left! Worth it, but only because I was able to get those skills in that time frame and do so with an income that made sense.

Asking someone to look that far back? Very painful. It's not gonna happen. Not without a very good reason, IMHO. Last time for me took darn near a week to run back through it and get competent. Money was good, but I won't lie: Had to work for it too. That and go shopping on E-bay!

What I've found is people lock into a system, or have customized it, or have machinery they depend on, or that just is profitable for them. They save a ton this way too! Reasonable, but doing that does come with costs and risks.

They can bank that, and spend every so often to get a repair or maintenance, or invest some of it to make their own they can self manage too. Both very often make sense over a modern replacement, should better capability not be indicated. So much depends on the scenario.

Re. ASCII. For the non-English languagues I'm more than a bit familiar with, ASCII is not, and can never be, an option. To believe that is more than just an illusion. It's simply.not .possible. It is not at all like going to a decimal number system. Yes, Unicode is a problem when you try to go from 7-bit ASCII to multi-byte characters. It wouldn't have been a problem if the industry hadn't settled for 'byte' as the basic character unit.
(The real problem with Unicode is that there are bugs in the mapping, now difficult to fix.)