Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Terminal Source Code

github.com

Post reply on HN
Print view View original

181–190 of 214 posts

Re: Windows Terminal Source Code

#181

Post by tmottabr »

justin66 wrote: post #166
dboreham wrote: post #129

Earlier quoted context omitted.

Lawyers concerned in-house code may become virally GPL licensed (I think, it has been a while since I had insight into MS inner workings). Same sort of thing as many/most companies won't allow their employees to look at patents.

> in-house code may become virally GPL licensed Without reusing any of that code, simply by osmosis? I don't know what the legal theory could be, but is that something that has ever happened in the entire history of the GPL?

no, by writing similar \ equal code somewhere that later other people looking at it could argue is a re-use of the GPL code they looked at and thus causing the whole project to became GPL.

it is just them thinking it is better being safe then sorry. if they don't even look at the code there is no way to argue that they are copying it.

Re: Windows Terminal Source Code

#182

Post by PufPufPuf »

kramerger wrote: post #139

Note that this is not the source code for the command shell utility (command.com, cmd.exe, etc). This is a new (-ish) project for creating a modern terminal It works really nice with WSL, for example I have configured each OS to have its default font and wallpaper :)

It actually is both! They put both codebases, Windows Terminal and cmd.exe, in this repo. See the readme for more info.

Re: Windows Terminal Source Code

#183

Post by matvore »

disruptiveink wrote: post #67
tambourine_man wrote: post #26

Apple should follow MS's example and open source its Terminal.app It's a decent terminal emulator, but could use several enhancements and the community could help. For some reason I haven't changed to iTerm yet, even though it's been objectively better in every way for years. Even the minor gripe I had with font rendering is fixed. There's something about using default apps as much as possible that appeals to me. But…

I was a Terminal.app user since Tiger, only recently had to switch to iTerm 2 as since Big Sur it forces anti-aliasing on non-HiDPI displays, even when turned off in the settings (I like non anti-aliased Monaco 10pt). It looks like a bug, but hasn't been fixed since.

If you use a font which doesn't have outline data Terminal.app and you set the rendered size to whatever is the native size of the font, Terminal.app will show you the unadulterated bitmap (if you use a multiple of the size, Terminal.app should scale it up without anti-aliasing).

I generate a .dfont without outline data based on a tweaked version of my favorite bitmap font, in Font Forge.

Now, if there is a way you can pre-render your favorite outline font to a bitmap and write it as a .dfont without outlines (other extensions may be fine, not sure though), you could switch back to Terminal.app. But font tools on GitHub etc. are very very few and never work that well, if they even do what they advertise at all.

Re: Windows Terminal Source Code

#184

Post by dundarious »

forgotpwd16 wrote: post #180
dundarious wrote: post #177

Earlier quoted context omitted.

Yes, I’m skeptical that WT will incorporate his design, as it is a big design change. There’s no way to just “plug it in” somewhere, without replacing the beating heart of WT. It would be great if they did that though, and I’d applaud them for it.

Apparently they did and in retro-perspective it was indeed that simple. (Simple as in they made their own custom renderer afterall.) https://devblogs.microsoft.com/commandline/case-study-how-ma...

Brilliant! Haven't had time to read it yet, but that's great to hear.

Re: Windows Terminal Source Code

#185

Post by pjmlp »

mattl wrote: post #178
pjmlp wrote: post #176

Earlier quoted context omitted.

None of them had anything to do with UNIX terminals. Ironically you even list one that is a RDP server, completly unrelated to CLI. Random Google search without diving into details?

I worked with Concurrent DOS about 25 years ago. I had heard of Windows Terminal server but I’ve barely touched a Windows computer in 20+ years.

Since Windows Terminal application doesn't care about Concurrent DOS ever existing, and Windows Terminal Server is actually the Windows version of X Windows based on DirectX and grown out of Citrix networking protocol, they don't apply here.

Re: Windows Terminal Source Code

#186

Post by jajcjuvuvgy »

naikrovek wrote: post #107
nyolfen wrote: post #64

winterm looks very nice but it often screws up character alignment if you resize the window. it happens so frequently that i gave it up, because at least once a day i could no longer tell what i was typing or trying to copy. i'm a happy customer with alacritty windows builds, but i wish it had tabs.

Wezterm is nice and it has tabs.

No post body was provided.

Re: Windows Terminal Source Code

#187

Post by mattl »

pjmlp wrote: post #185
mattl wrote: post #178

Earlier quoted context omitted.

I worked with Concurrent DOS about 25 years ago. I had heard of Windows Terminal server but I’ve barely touched a Windows computer in 20+ years.

Since Windows Terminal application doesn't care about Concurrent DOS ever existing, and Windows Terminal Server is actually the Windows version of X Windows based on DirectX and grown out of Citrix networking protocol, they don't apply here.

Does Windows Terminal replace HyperTerminal too? Hadn't thought about that one in a while.

Re: Windows Terminal Source Code

#188

Post by dundarious »

dundarious wrote: post #184
forgotpwd16 wrote: post #180

Earlier quoted context omitted.

Apparently they did and in retro-perspective it was indeed that simple. (Simple as in they made their own custom renderer afterall.) https://devblogs.microsoft.com/commandline/case-study-how-ma...

Brilliant! Haven't had time to read it yet, but that's great to hear.

I think Casey did a lot of other great work on more correct and speedy non-ASCII support, and very efficient scrollback (in both memory and time cost), etc. It's been a while, but I think the atlas approach is also different. But kudos for what seems to be a good step. I'm curious to see some data on the resulting performance and memory usage (presuming the latter is mostly unchanged).

Re: Windows Terminal Source Code

#189

Post by Maursault »

babylonunited wrote: post #150
Maursault wrote: post #111

Earlier quoted context omitted.

I probably shouldn't dignify this with a response, but yeah, you don't know what you're talking about. The kernel XNU is OSS. The BSD userland is OSS. This means that technically, the operating system is open source. If you go by file count, there is far more OSS in macOS than not. But if you want to go by file sizes, then the only closed source parts of macOS, again, are the GUI, the Quartz Compositor, and a lot of…

I think a lot of value comes with the Frameworks, with them you get at least source compatibility with macOS and without them the core operating system will just be another Unix operating system without much hardware supports. So I personally put much more weight on the Frameworks over XNU and BSD userland. There is a reason GNUStep is less dead than PureDarwin :D

That's fine, but the frameworks are not installed with macOS. In order to get them, one must sign up for a free developer account, at least, and install Xcode, which is massive, but I'm not sure how you can say it is part of the OS when most people never install it.

Re: Windows Terminal Source Code

#190

Post by Maursault »

tambourine_man wrote: post #172
Maursault wrote: post #111

Earlier quoted context omitted.

I probably shouldn't dignify this with a response, but yeah, you don't know what you're talking about. The kernel XNU is OSS. The BSD userland is OSS. This means that technically, the operating system is open source. If you go by file count, there is far more OSS in macOS than not. But if you want to go by file sizes, then the only closed source parts of macOS, again, are the GUI, the Quartz Compositor, and a lot of…

Cocoa/UIKit, Quartz, Core*, drivers, etc are all closed source and much larger (by line count) than the kernel and BSD stuff. You can even throw WebKit and LLVM (which are humongous) in the mix and it won't change the balance. But since I can't link to them and neither can you, we're just going to keep saying the other one is wrong in a web forum.

And that is expected, because graphics takes up a lot of space, so this comparison is not intellectually honest. But I'd like to see you try running just the "Cocoa/UIKit, Quartz, Core*, drivers, etc" without the kernel and BSD userland. Without the GUI, we still have an operating system that is entirely OSS. With only the GUI, we have nothing that works.
Post reply on HN