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?
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.
It's endless frustration in Win 10 on Surface land.
Oh, and did I mention WIFI does not work if I plug in the dock?
But what do you mean "Unicode". Have you accidentally thrown some UTF-8 in there or some such?
I don't think PropellerIDE ever got much testing on Linux.
I'm going by a warning on a widows machine, when saving my progress in Propeller tool that: Warning this document contains unicode characters.. .bla, bla, bla, A whole paragraph.
It comes up after pasting a MIT's license. I can't see any difference in the license that does, and the license that doesn’t create that message.
But PropellerIDE running under Linux totally obliterated any schematics that are created on the spin document. Scattering bits of code over the whole document, including messing with license format.
I will be making a formal bug report, as soon as I can come up with a concise explanation of the problem. In other words, as soon as I can put something together that doesn't sound dumb.
Unicode is a curse that is sent to confuse us all and drive us to madness. I have suffered enough from it. Look around the web and see how many documents are corrupted by it.
Unicode, in it's many binary formats is impossibly difficult to deal with. Especially if importing text from here and there or cutting and pasting this and that.
It's pretty much impossible for a program to even find the length, in characters, of a Unicode string.
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.
No there was not a schematic for that file. But that dialog was generated by the program.
It starts with the last files that were open at closing time... perhaps that's a forgotten relict of your work some months/years ago?
If(not) then yeti.is_lost();
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.
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.
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.
Nice idea.
What bugs me about that is that we humans used to have all kind of weird schemes for numbers. Remember the Roman numerals and such? It all got rationalized to the Arabic numerals we have today.
That adoption of a common number system stemmed from the needs of trade. Arguably bringing people together.
So, yeah, adoption of ASCII would unite people. Unicode is diversive divisive.
Yes, it's messy and inconvenient for 8-bit dinosaurs. Get over it.
Messy and inconvenient would be OK. That's just more mess and inconvenience and "busy" work.
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.)
...it's equivalent to the halting problem? Can you cite a mathematical proof?
Clearly Unicode cannot hit the halting problem. It's not any kind of programming system (Although I suspect the Unicode consortium is mad enough to be designing that in as we speak )
On the other hand I have yet to see any software that can handle all of Unicode.
...diversive...divisive...
Oops, well spotted. Must remember not to post when I half asleep.
Yes, divisive. It encourages everyone to continue with their own language. Rather than uniting everyone.
@CoderKid,
Heater likes MS products because MS products also produce heat!
Ha! Actually, given it's performance this Surface Pro 4 runs pretty cool. Cooler than any laptop or PC around here.
@all
Unicode problems:
1) It's made an unintelligible mess of billions of web pages as text gets mangled when being moved from system to system. This data corruption is what computers should not be doing.
2) It allows me to write source code like this Javascript snippet:
let ﻝ = {
ﺍ: function () {
return ("Hello world!");
}
}
let msg = ﻝ.ﺍ();
console.log(msg);
ف = (2 + 3) * (3 + 3)
console.log(ف);
Which is basically unintelligible gibberish but is a valid working program.
3) Emoji
The are basically meaningless and have no place in text. Whatever language you are using.
If you look at the way emoji are rendered in different systems you see the same code point can look as if it means something totally different.
Comments
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?
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.
Often times I have edited a post just to remove all those trailing blank lines.
You mean like this:
Nobody in their right mind does that. What would they benefit by it?
I'm all for cross-platform support. And often times one can get that for non-gui programs that use only decades old standards. Try telling that to all the developers of Android and iOS apps. Try telling that even to MicroSoft.
Nobody cares about the few people still alive that use Win32 from the Win 3.1 or Win 98 era.
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.
It's endless frustration in Win 10 on Surface land.
Oh, and did I mention WIFI does not work if I plug in the dock?
-Phil
I'm going by a warning on a widows machine, when saving my progress in Propeller tool that: Warning this document contains unicode characters.. .bla, bla, bla, A whole paragraph.
It comes up after pasting a MIT's license. I can't see any difference in the license that does, and the license that doesn’t create that message.
But PropellerIDE running under Linux totally obliterated any schematics that are created on the spin document. Scattering bits of code over the whole document, including messing with license format.
I will be making a formal bug report, as soon as I can come up with a concise explanation of the problem. In other words, as soon as I can put something together that doesn't sound dumb.
You have my sympathy. What you say is not dumb.
Unicode is a curse that is sent to confuse us all and drive us to madness. I have suffered enough from it. Look around the web and see how many documents are corrupted by it.
Unicode, in it's many binary formats is impossibly difficult to deal with. Especially if importing text from here and there or cutting and pasting this and that.
It's pretty much impossible for a program to even find the length, in characters, of a Unicode string.
Mike
It looks like a template or example...
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.
No there was not a schematic for that file. But that dialog was generated by the program.
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.
If(not) then yeti.is_lost();
Thanks, Once I had seen some corruption of my file it spooked me, I have enough trouble keeping things strait.
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.
Heater said Unicode is evil, I tend to agree.
-Phil
What bugs me about that is that we humans used to have all kind of weird schemes for numbers. Remember the Roman numerals and such? It all got rationalized to the Arabic numerals we have today.
That adoption of a common number system stemmed from the needs of trade. Arguably bringing people together.
So, yeah, adoption of ASCII would unite people. Unicode is diversive divisive. Messy and inconvenient would be OK. That's just more mess and inconvenience and "busy" work.
Problem is it becomes computationally impossible.
I like that! (as opposed to divisive)
-Phil
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.
(The real problem with Unicode is that there are bugs in the mapping, now difficult to fix.)
On the other hand I have yet to see any software that can handle all of Unicode. Oops, well spotted. Must remember not to post when I half asleep.
Yes, divisive. It encourages everyone to continue with their own language. Rather than uniting everyone.
@CoderKid, Ha! Actually, given it's performance this Surface Pro 4 runs pretty cool. Cooler than any laptop or PC around here.
@all
Unicode problems:
1) It's made an unintelligible mess of billions of web pages as text gets mangled when being moved from system to system. This data corruption is what computers should not be doing.
2) It allows me to write source code like this Javascript snippet: Which is basically unintelligible gibberish but is a valid working program.
3) Emoji
The are basically meaningless and have no place in text. Whatever language you are using.
If you look at the way emoji are rendered in different systems you see the same code point can look as if it means something totally different.
The height of the madness is of course this: "
Thanks to my trying to use Unicode a big chunk of my last post is missing. It was like so:
The height of the madness is of course this: " "
Note: I had to replace the Unicode U+1F4A9 with an image to save my post from being corrupted.
4) Complexity. Now every program has to be handle Unicode. Which as I said earlier is all but impossible. Check this video to see why:
Testing: 💩
Hmmm...So we can.
I think that is a big pile...
💩
💩 💩
💩 💩 💩
💩 💩 💩 💩
💩 💩 💩 💩 💩
💩 💩 💩 💩 💩 💩
I wonder what forum vulnerabilities we can exploit with HTML entities like that ?