Search
483 results for “zirias”
-
@dryak Oh boy! I really just learned the "classic" Windows Console palette was even "more broken", I wasn't aware so far. This would also mean there would be a very dark "dark white" and a second "black", but no, those two were adjusted...
Also found they only changed that in #Win10, but instead of going for a real #RGBI palette with brown adjustment, they picked pretty arbitrary values creating a new less greenish "dark yellow" 🤦♂️
https://devblogs.microsoft.com/commandline/updating-the-windows-console-colors/Indeed, I remember seeing lots of very regular dithering in Windows 3.x ... so you probably have a point here 😉
-
Found one of these old ones using lots of cursor movement foo that even mis-renders on
https://16colo.rs/pack/1991/SOUL.ANSGuess #dos2ansi is really implementing these correctly now 😎 (finally!)
-
Playing around some more with some *very* old #ANSIart files ... blinking was obviously used more back then, and it's really nice #xterm can actually do that! 😎
(need to pass an extra -k flag to #dos2ansi here because there's no #SAUCE in this old file and the default is assuming bright colors instead)
-
BTW, the color difference you see in these Windows screenshots is the classic "dark yellow vs brown" issue.
Quick background, with digital #RGBI signals (like used with #CGA), you couldn't have brown, but high-quality monitors (including IBM's own, but also a Commodore 1084 I have here) had extra circuitry adjusting dark yellow to brown by reducing the green component. With #CGA on a cheap monitor or a TV set, you still had "dark yellow".
#VGA finally moved to analog #RGB and used brown. Still many terminals today (including #Windows #Console) have dark yellow in their default palettes.
#dos2ansi must rely on the default palette when the terminal supports only 8 or 16 colors, but with a 256-color terminal, it uses "original" CGA/VGA colors. And of course, there's a switch to disable the "brown adjustment" 😎
Screenshot from #xterm on#FreeBSD showing both modes, actually this example looks like it might have been designed with "dark yellow" in mind.
-
BTW, the color difference you see in these Windows screenshots is the classic "dark yellow vs brown" issue.
Quick background, with digital #RGBI signals (like used with #CGA), you couldn't have brown, but high-quality monitors (including IBM's own, but also a Commodore 1084 I have here) had extra circuitry adjusting dark yellow to brown by reducing the green component. With #CGA on a cheap monitor or a TV set, you still had "dark yellow".
#VGA finally moved to analog #RGB and used brown. Still many terminals today (including #Windows #Console) have dark yellow in their default palettes.
#dos2ansi must rely on the default palette when the terminal supports only 8 or 16 colors, but with a 256-color terminal, it uses "original" CGA/VGA colors. And of course, there's a switch to disable the "brown adjustment" 😎
Screenshot from #xterm on#FreeBSD showing both modes, actually this example looks like it might have been designed with "dark yellow" in mind.
-
BTW, the color difference you see in these Windows screenshots is the classic "dark yellow vs brown" issue.
Quick background, with digital #RGBI signals (like used with #CGA), you couldn't have brown, but high-quality monitors (including IBM's own, but also a Commodore 1084 I have here) had extra circuitry adjusting dark yellow to brown by reducing the green component. With #CGA on a cheap monitor or a TV set, you still had "dark yellow".
#VGA finally moved to analog #RGB and used brown. Still many terminals today (including #Windows #Console) have dark yellow in their default palettes.
#dos2ansi must rely on the default palette when the terminal supports only 8 or 16 colors, but with a 256-color terminal, it uses "original" CGA/VGA colors. And of course, there's a switch to disable the "brown adjustment" 😎
Screenshot from #xterm on#FreeBSD showing both modes, actually this example looks like it might have been designed with "dark yellow" in mind.
-
BTW, the color difference you see in these Windows screenshots is the classic "dark yellow vs brown" issue.
Quick background, with digital #RGBI signals (like used with #CGA), you couldn't have brown, but high-quality monitors (including IBM's own, but also a Commodore 1084 I have here) had extra circuitry adjusting dark yellow to brown by reducing the green component. With #CGA on a cheap monitor or a TV set, you still had "dark yellow".
#VGA finally moved to analog #RGB and used brown. Still many terminals today (including #Windows #Console) have dark yellow in their default palettes.
#dos2ansi must rely on the default palette when the terminal supports only 8 or 16 colors, but with a 256-color terminal, it uses "original" CGA/VGA colors. And of course, there's a switch to disable the "brown adjustment" 😎
Screenshot from #xterm on#FreeBSD showing both modes, actually this example looks like it might have been designed with "dark yellow" in mind.
-
BTW, the color difference you see in these Windows screenshots is the classic "dark yellow vs brown" issue.
Quick background, with digital #RGBI signals (like used with #CGA), you couldn't have brown, but high-quality monitors (including IBM's own, but also a Commodore 1084 I have here) had extra circuitry adjusting dark yellow to brown by reducing the green component. With #CGA on a cheap monitor or a TV set, you still had "dark yellow".
#VGA finally moved to analog #RGB and used brown. Still many terminals today (including #Windows #Console) have dark yellow in their default palettes.
#dos2ansi must rely on the default palette when the terminal supports only 8 or 16 colors, but with a 256-color terminal, it uses "original" CGA/VGA colors. And of course, there's a switch to disable the "brown adjustment" 😎
Screenshot from #xterm on#FreeBSD showing both modes, actually this example looks like it might have been designed with "dark yellow" in mind.
-
As hard to believe as it is, the #Windows #Console still supports #CP437. And with the "virtual terminal processing" introduced in #Win10, it also accepts escape sequences, obviously even the more obscure ones from ANSI.SYS 😂
So, on a somewhat recent #Windows, you can display most #ANSIart without any extra tool, 'chcp 437' and 'type' is enough.
#dos2ansi will still be helpful:
* The output is sanitized, using *only* SGR sequences and a #Unicode encoding (so, also suitable to store in a file)
* Correlated here, some "exotic" MS-DOS #codepages are supported.
* On Windows > win10, colors will be corrected to the CGA/VGA palette (first screenshot)
* It will still work if your terminal width is different from what the input file assumes (second screenshot)Screenshots show first 'type' with cp437 selected, then 'dos2ansi' 😎
-
As hard to believe as it is, the #Windows #Console still supports #CP437. And with the "virtual terminal processing" introduced in #Win10, it also accepts escape sequences, obviously even the more obscure ones from ANSI.SYS 😂
So, on a somewhat recent #Windows, you can display most #ANSIart without any extra tool, 'chcp 437' and 'type' is enough.
#dos2ansi will still be helpful:
* The output is sanitized, using *only* SGR sequences and a #Unicode encoding (so, also suitable to store in a file)
* Correlated here, some "exotic" MS-DOS #codepages are supported.
* On Windows > win10, colors will be corrected to the CGA/VGA palette (first screenshot)
* It will still work if your terminal width is different from what the input file assumes (second screenshot)Screenshots show first 'type' with cp437 selected, then 'dos2ansi' 😎
-
As hard to believe as it is, the #Windows #Console still supports #CP437. And with the "virtual terminal processing" introduced in #Win10, it also accepts escape sequences, obviously even the more obscure ones from ANSI.SYS 😂
So, on a somewhat recent #Windows, you can display most #ANSIart without any extra tool, 'chcp 437' and 'type' is enough.
#dos2ansi will still be helpful:
* The output is sanitized, using *only* SGR sequences and a #Unicode encoding (so, also suitable to store in a file)
* Correlated here, some "exotic" MS-DOS #codepages are supported.
* On Windows > win10, colors will be corrected to the CGA/VGA palette (first screenshot)
* It will still work if your terminal width is different from what the input file assumes (second screenshot)Screenshots show first 'type' with cp437 selected, then 'dos2ansi' 😎
-
As hard to believe as it is, the #Windows #Console still supports #CP437. And with the "virtual terminal processing" introduced in #Win10, it also accepts escape sequences, obviously even the more obscure ones from ANSI.SYS 😂
So, on a somewhat recent #Windows, you can display most #ANSIart without any extra tool, 'chcp 437' and 'type' is enough.
#dos2ansi will still be helpful:
* The output is sanitized, using *only* SGR sequences and a #Unicode encoding (so, also suitable to store in a file)
* Correlated here, some "exotic" MS-DOS #codepages are supported.
* On Windows > win10, colors will be corrected to the CGA/VGA palette (first screenshot)
* It will still work if your terminal width is different from what the input file assumes (second screenshot)Screenshots show first 'type' with cp437 selected, then 'dos2ansi' 😎
-
As hard to believe as it is, the #Windows #Console still supports #CP437. And with the "virtual terminal processing" introduced in #Win10, it also accepts escape sequences, obviously even the more obscure ones from ANSI.SYS 😂
So, on a somewhat recent #Windows, you can display most #ANSIart without any extra tool, 'chcp 437' and 'type' is enough.
#dos2ansi will still be helpful:
* The output is sanitized, using *only* SGR sequences and a #Unicode encoding (so, also suitable to store in a file)
* Correlated here, some "exotic" MS-DOS #codepages are supported.
* On Windows > win10, colors will be corrected to the CGA/VGA palette (first screenshot)
* It will still work if your terminal width is different from what the input file assumes (second screenshot)Screenshots show first 'type' with cp437 selected, then 'dos2ansi' 😎
-
A few fixes were needed to #zimk (my very own #GNU #make framework) to make everything work perfectly again in #Windows #CMD.
Testing these now, here's building #dos2ansi on Windows with just 'make' and 'mingw' installed from #chocolatey 😎
(building worked before as well, but there were lots of glitches and issues like e.g. partially broken "clean" rules)
-
Oh freakin hell, of course this happens directly *after* release: I found some #ansiart file that really uses every obscure display-related feature of ANSI.SYS, and as a result, #dos2ansi v1.4 just renders garbage 😠
It now works with the latest commit, I had to implement:
- absolute cursor positioning
- cursor position saving and restoring
- all the erasing (line/screen) commands
- and additionally at least ignoring sequences to set the screen mode 🤯Why is anyone doing that? First I thought save bandwidth for BBS, but this file has 7620 bytes, and processed with -AId flags (so only sequences used also available in ANSI.SYS), it shrinks down to 5906 bytes even using #UTF8... I really don't understand that 🙈
Here's this file: https://16colo.rs/pack/arc-17/M0D-RMS1.ASC
#dos2ansi v1.5 will be there soon I guess...
-
Time to verify all my additions to my #GNUmake framework #zimk didn't break compatibility with #Windows #CMD -- they didn't 😎
So, you can still build #dos2ansi yourself on Windows with the minimal set of tooling installed, e.g. using #chocolatey, 'choco install mingw' and 'choco install make' is enough ☑️
The garbled output seen in the screenshot is a consequence of Windows #Console output being strictly unbuffered, which allows these things to happen with make jobs ... I see no way to work around this .... 🙄
-
#FreeBSD users can get a #port of #dos2ansi v1.4 here, patch applies to the ports tree with `git am` (hint, use a local git branch to avoid cluttering your `main`):
https://people.freebsd.org/~zirias/patches/0001-textproc-dos2ansi-Add-new-port.patchThe port comes in two flavors: "nox11" makes #showansi optional and doesn't add any dependencies. "x11" (the default flavor) always includes showansi and adds runtime dependencies to #xterm and #ibmfonts, so the default configuration of showansi works out of the box.
Still unsure whether I should add it to the official ports tree .... 🤔
-
Two more examples using showansi from #dos2ansi v1.4:
1. Autoselecting a different codepage (here CP-855 cyrillic)
2. Autoselecting a "wide" font (here VGA-9x8, mapped to VGA18x16)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
And here's the upcoming "feature" for #dos2ansi v1.2: Attempt to format #SAUCE comments nicely. 🙈
It seems to be common practice to wrap comment lines in the middle of a word, so here's an attempt to be "smart" with this, adding an (optional) formatting heuristic:
* Empty lines are alway printed as is
* Same for lines containing "drawing" characters (anything >= 0xb0 in #cp437)
* Otherwise, if the last character of a line *and* the first of the next line are non-space, it's assumed to be one word
* Formatted lines are filled with as many complete words as possible, preserving spaces except at the end of the line
* More than two spaces at the end of a (raw) line are interpreted as a line breakHere are two real examples of the result, while the second already shows some classic shit-in-shit-out case (to fix this, I'd probably need a language model 😂)
-
Never say something is finished 🙈
Browsing https://16colo.rs/ I found some #ansiart file that immediately had my attention because it crashed my #terminfo writer. Turns out attempting fallback to #termcap names makes no sense with terminfo ... although it shouldn't hurt either, but it did with "xterm-256color" on #FreeBSD for the "blink"/"mb" capability, "mb" returned something, but something "else" 🙄 ... so I fixed that.
This file was strange enough to use it for more testing, it had "blinking" characters (according to #SAUCE), although ignoring that and using bright colors instead looked much more sane, see two screenshots for comparison (oh wow, #xterm can actually blink? although not like #VGA would...)
Anyways, I found a lot more things to optimize and fix in both my "plain ANSI" and "terminfo" color writers!
So, there will be #dos2ansi v1.2 soon. Will probably add some small feature first, just "because" 😂
-
BTW the specific #win32-api-braindamage that hit me in #dos2ansi 1.0 was FlushFileBuffers(): https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-flushfilebuffers
Sure, my fault not to read the *whole* docs before using it and just assuming sane semantics 🙈:
> The function fails if _hFile_ is a handle to the console output. That is because the console output is not buffered.
Okayyyy. I mean, not *having* to know what some "handle" used to do I/O is referring to exactly is kind of the whole point of any I/O abstraction, at least I thought so. Any API I've seen so far would just make it a no-op (and, of course, succeed) in such a case. 🤯
-
Ist this still crazy or outright insane? Spoiler, it involves the #C #preprocessor 🤯😏
I had a need to suppress a #warning ... this ominous thing about string literal sizes you get for free when asking your compiler to be -pedantic 🤡
Found a way to define a #macro to do this in a comfortable and defensive way for #clang and #GCC. 🙈
-
Here's a mystery on #FreeBSD using tput(1) in #xterm with $TERM set to xterm-256colors:
$ tput colors
80
$ tput Co
256I think this *should* query the exact same property, once by its #terminfo name, once by the short #termcap name.
To add to the confusion, in the "dos2ansi" tool I currently write, I use tigetstr() and tigetnum() and prefer the terminfo names, but fall back to the termcap names. The response I get for "number of colors" there is 256, with the same configuration.
Anyone got any ideas which weird magic is going on here? 🤔
-
@wader I think I can add a bit of explanation here. MSVCRT.DLL (as a "standard C library") was included with windows for a long time, but they quickly ran into issues with it, most likely caused by not having sane mechanisms for versioning. So, what they did was including a C runtime with each release of their compiler (#MSVC) and expect this runtime to be redistributed with software using it. MSVCRT.DLL had its public API/ABI frozen in a state with #C89 and partial(!) #C99 support and was declared "private" to the OS.
#Mingw (which is also distributed by #MSYS2) nevertheless continued linking to MSVCRT.DLL (and I see why, it's really stupid to have tons of copies of the C runtime ...). So, while the compilers support newer C standards, the standard lib doesn't, and therefore you need quite some hacks and workarounds. And I wouldn't be surprised to find lots of funny misbehavior, that's why I think the issue might indeed be the strftime() from MSVCRT.DLL.
[...] -
@wader I had a quick look at your code now and see you're already "handling" this using wmain() and doing the conversion. So, this seems to be a bit mysterious.
Is all your output #utf8? Then adding SetConsoleOutputCP(CP_UTF8); should fix output for anyone without requiring them to use chcp first, but I don't see why specifically argv values continue to have a problem. It probably needs some experimentation 😞
Text encoding on #Windows is so borked because they jumped on #Unicode early using #UCS2 and now they need to handle everything in #UTF16 stored in 16bit wide wchar_t ... and also want to remain compatible with any older crap ... 🙈