Am 28.05.2019 um 20:16 schrieb René Berber:
On 5/28/2019 12:29 AM, Thomas Wolff wrote:
I have uploaded mintty 3.0.1 with the following changes:
Scroll bar now appears on the right side, its configured to be on the
left... and there is no way to change it back to the left, only no
scroll bar
On 5/28/2019 12:29 AM, Thomas Wolff wrote:
> I have uploaded mintty 3.0.1 with the following changes:
Scroll bar now appears on the right side, its configured to be on the
left... and there is no way to change it back to the left, only no
scroll bar works (other than right s.b.) if you
I have uploaded mintty 3.0.1 with the following changes:
Highlights
* New character attributes superscript, subscript, shadowed, overstrike.
* DEC VT420 screen control features.
* Fully VT100-compatible, including VT52 mode (with graphics).
* Up to 6 key modifiers, including Meta (Win
I have uploaded mintty 3.0.1 with the following changes:
Highlights
* New character attributes superscript, subscript, shadowed, overstrike.
* DEC VT420 screen control features.
* Fully VT100-compatible, including VT52 mode (with graphics).
* Up to 6 key modifiers, including Meta (Win
- Original Message -
> From: Tatsuro MATSUOKA
> To: cygwi
> Cc:
> Date: 2019/3/17, Sun 13:56
> Subject: copy and paste on mintty are strange for lines containing wide width
> characters after 2.9.7
>
> After 2.9.7,
>
>
> copy and paste on mintty
I have uploaded mintty 3.0.0 with the following changes:
Character processing
* Fixed wide character width and cursor position handling.
Keyboard handling
* Switchable auto-repeat; DECSET 8 (DECARM), option AutoRepeat,
toggle function.
Bidirectional rendering (Unicode Bidi Algorithm
I have uploaded mintty 3.0.0 with the following changes:
Character processing
* Fixed wide character width and cursor position handling.
Keyboard handling
* Switchable auto-repeat; DECSET 8 (DECARM), option AutoRepeat,
toggle function.
Bidirectional rendering (Unicode Bidi Algorithm
On Thu, 28 Mar 2019 22:33:48, Thomas Wolff wrote:
It's a bit strange that you're telling my that *you* don't care about
*my* information.
I'm trying to raise some awareness about privacy on this occasion (which
is quite a topic nowadays) and if you don't care, you don't need to comment.
Yeah,
Am 28.03.2019 um 20:47 schrieb Achim Gratz:
Thomas Wolff writes:
I do not like the dual chaos of manual vs info pages, and I'm maybe a
bit old-fashioned to insist that manual pages should be complete, but
isn't that their purpose?
You are barking up the wrong tree, but if you're that bothered
.
And what I was pointing out is that nobody but you needs to. This whole thread
is about trying
to solve *your* problem, not someone else's. As I said, if I built mintty, I
would just use cygport
and be done with it. I don't care about user information, because I'm not
distributing the package
Thomas Wolff writes:
> I do not like the dual chaos of manual vs info pages, and I'm maybe a
> bit old-fashioned to insist that manual pages should be complete, but
> isn't that their purpose?
You are barking up the wrong tree, but if you're that bothered by it,
you can file an RFE or bug report
t; neither of those
>> objections are really a problem.)
> What I wanted to point out with my last objection is that some people may not
> be able to create an account as they like, in an enterprise environment.
And what I was pointing out is that nobody but you needs to. This whole thread
is
Am 28.03.2019 um 19:16 schrieb Vince Rice:
On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
A potential solution is, add another user to your system named cygwin.
When you build you packages use the cygwin user. The debug information
will reference your cygwin user, and not your real user
Am 28.03.2019 um 19:21 schrieb Achim Gratz:
Thomas Wolff writes:
In fact that seems to work, although there is no TAR_OPTIONS
documented in the manual page.
The already much too long manual page does tell you to consult the info
manual right at the top, does it not?
I do not like the dual
On 2019-03-28 7:36 am, Steven Penny wrote:
On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote:
Mintty can be used to run any command-line application directly (like
top, your editor, ...), a shell is not needed.
That may be true, the by default Mintty is configure to load Bash. So
Thomas Wolff writes:
> In fact that seems to work, although there is no TAR_OPTIONS
> documented in the manual page.
The already much too long manual page does tell you to consult the info
manual right at the top, does it not?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb
> On Mar 28, 2019, at 1:09 PM, Thomas Wolff wrote:
>
>> A potential solution is, add another user to your system named cygwin.
>> When you build you packages use the cygwin user. The debug information
>> will reference your cygwin user, and not your real user account.
> Thanks for the suggestion,
Am 28.03.2019 um 15:02 schrieb Jeffrey Walton:
On Thu, Mar 28, 2019 at 4:44 AM Thomas Wolff wrote:
...
Björn Stabel wrote:
On 27/03/2019 23:59, Yaakov Selkowitz wrote:
On Wed, 2019-03-27 at 21:02 +0100, Thomas Wolff wrote:
I used to use tar rather than cygport package to generate the
Am 28.03.2019 um 18:40 schrieb Achim Gratz:
Björn Stabel writes:
Sorry for commenting from the peanut gallery, but his problem may be
that he doesn't want to disclose his user name to anyone nosy enough to
snoop around in the package files.
Not tested, but something like
env
Björn Stabel writes:
> Sorry for commenting from the peanut gallery, but his problem may be
> that he doesn't want to disclose his user name to anyone nosy enough to
> snoop around in the package files.
Not tested, but something like
env TAR_OPTIONS="--user=0 --group=0" cygport ...
should do
Thomas Wolff writes:
> Mintty can be used to run any command-line application directly (like
> top, your editor, ...), a shell is not needed.
Your _package_ has a dependency to the shell by way of including a shell
script. If you so desperately want to get rid of it (even though it's
On 2019-03-28 05:36, Steven Penny wrote:
> On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote:
>> Mintty can be used to run any command-line application directly (like top,
>> your editor, ...), a shell is not needed.
>
> That may be true, the by default Mintty is confi
On Thu, Mar 28, 2019 at 4:44 AM Thomas Wolff wrote:
> ...
> Björn Stabel wrote:
> > On 27/03/2019 23:59, Yaakov Selkowitz wrote:
> >> On Wed, 2019-03-27 at 21:02 +0100, Thomas Wolff wrote:
> >>> I used to use tar rather than cygport package to generate the packages.
> >>> One reason was that I
On Thu, 28 Mar 2019 08:34:34, Thomas Wolff wrote:
Mintty can be used to run any command-line application directly (like
top, your editor, ...), a shell is not needed.
That may be true, the by default Mintty is configure to load Bash. So it is
disingenuous so simply say that it does not require
he "release" repository was only a fallback rescue setting,
> because due to github's strange URL scheme, the working download URL would
> confuse cygport.
If your repo is on github anyway it would be much simpler to define
the source as a git repo. Rather than SRC_URI, just use
ring to the "release" repository was only a fallback rescue
setting, because due to github's strange URL scheme, the working
download URL would confuse cygport.
from the release area, and not from the separate “release” repository,
unfortunately it’s github URL does not include the “mintty-”
are installed.
...
"some shell should be a dep".
Mintty can be used to run any command-line application directly (like
top, your editor, ...), a shell is not needed.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
On 27/03/2019 23:59, Yaakov Selkowitz wrote:
> On Wed, 2019-03-27 at 21:02 +0100, Thomas Wolff wrote:
>> I used to use tar rather than cygport package to generate the packages.
>> One reason was that I didn’t want my local user/group to appear in them.
> They won't show up like that once
On Wed, 27 Mar 2019 20:44:44, Brian Inglis wrote:
Both dash and bash are in Base, installed by default, and both are login
shells, while dash requires only cygwin1.dll to run, and can be used during
setup, before other libraries or utilities are installed.
Yeah, I did not mean to say login
On 2019-03-27 19:12, Steven Penny wrote:
> On Wed, 27 Mar 2019 19:09:07, Yaakov Selkowitz wrote:
>> "Only" if /bin/bash is your preferred shell. Granted, that's the
>> default, and what most users would want anyway, but that is not
>> strictly speaking a mintty de
On Wed, 2019-03-27 at 18:12 -0700, Steven Penny wrote:
> On Wed, 27 Mar 2019 19:09:07, Yaakov Selkowitz wrote:
> > "Only" if /bin/bash is your preferred shell. Granted, that's the
> > default, and what most users would want anyway, but that is not
> > strictly spea
On Wed, 27 Mar 2019 19:09:07, Yaakov Selkowitz wrote:
"Only" if /bin/bash is your preferred shell. Granted, that's the
default, and what most users would want anyway, but that is not
strictly speaking a mintty dependency. As I mentioned in my response,
the auto-detected dependen
On Wed, 2019-03-27 at 15:51 -0700, Steven Penny wrote:
> On Wed, 27 Mar 2019 21:02:47, Thomas Wolff wrote:
> > >>> mintty requires: bash cygwin
> > I remember some discussion that the cygwin dependency, which most
> > packages have, should not (or does not need
> cygport refer to this if the package is locally available?) from the
> release area, and not from the separate “release” repository,
> unfortunately it’s github URL does not include the “mintty-” prefix
> (it’s just 2.9.9.tar.gz) which causes the source package generated by
> cygp
On Wed, 27 Mar 2019 21:02:47, Thomas Wolff wrote:
>>> mintty requires: bash cygwin
I remember some discussion that the cygwin dependency, which most
packages have, should not (or does not need to be) listed.
And in fact, mintty does not depend on bash. Why does cygport think so?
U
On Wed, Mar 27, 2019 at 4:36 PM Achim Gratz wrote:
> ...
> > I removed -s as suggested by Achim, added -g as advised by Corinna,
> > but cygport still says:
> > *** Info: No debug files, skipping debuginfo subpackage
>
> Well, do not reset CFLAGS in your Makefile and cygport helpfully
> provides
is locally available?)
It's generally considered bad form to provide a cygport file that
doesn't work standalone and the SRC_URI you provided only got me a 404.
> from the release area, and not from the separate “release” repository,
> unfortunately it’s github URL does not include the “m
he package is locally available?) from the
release area, and not from the separate “release” repository,
unfortunately it’s github URL does not include the “mintty-” prefix
(it’s just 2.9.9.tar.gz) which causes the source package generated by
cygport to be empty:
>>> Creating sou
Thomas Wolff writes:
> Sorry, I neither know how to make use of such a package nor how to
> generate it or what it contains.
> But I'd take a patch:)
As you wish…
mintty.cygport
Description: Binary data
--- origsrc/mintty-2.9.9/src/Makefile 2019-03-16 07:13:38.0 +0100
+++ s
On Mar 25 00:36, Thomas Wolff wrote:
> Hi Corinna,
>
> Am 24.03.2019 um 19:19 schrieb Corinna Vinschen:
> > On Mar 24 16:57, Thomas Wolff wrote:
> > > Hi Achim,
> > >
> > > Am 16.03.2019 um 15:00 schrieb Achim Gratz:
> > > > Thoma
Hi Corinna,
Am 24.03.2019 um 19:19 schrieb Corinna Vinschen:
On Mar 24 16:57, Thomas Wolff wrote:
Hi Achim,
Am 16.03.2019 um 15:00 schrieb Achim Gratz:
Thomas Wolff writes:
I have uploaded mintty 2.9.9 with the following changes:
While you're at it, could you please stop using the release
Greetings, Thomas Wolff!
> Am 16.03.2019 um 15:00 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> I have uploaded mintty 2.9.9 with the following changes:
>> While you're at it, could you please stop using the release number "0" for
>> your packages?
On Mar 24 16:57, Thomas Wolff wrote:
> Hi Achim,
>
> Am 16.03.2019 um 15:00 schrieb Achim Gratz:
> > Thomas Wolff writes:
> > > I have uploaded mintty 2.9.9 with the following changes:
> > While you're at it, could you please stop using the release number "
On 2019-03-24 09:57, Thomas Wolff wrote:
> Am 16.03.2019 um 15:00 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> I have uploaded mintty 2.9.9 with the following changes:
>> While you're at it, could you please stop using the release number "0" for
>> you
Hi Achim,
Am 16.03.2019 um 15:00 schrieb Achim Gratz:
Thomas Wolff writes:
I have uploaded mintty 2.9.9 with the following changes:
While you're at it, could you please stop using the release number "0" for your
packages?
I had previously explained why I used to like this (nati
On Sat, 16 Mar 2019 15:00:54, Achim Gratz wrote:
Thomas Wolff writes:
I have uploaded mintty 2.9.9 with the following changes:
While you're at it, could you please stop using the release number "0"
for your packages? That's supposed to be used for test packages only
(if you wa
Am 17.03.2019 um 06:24 schrieb Takashi Yano:
On Sun, 17 Mar 2019 13:56:40 +0900 (JST) Tatsuro MATSUOKA wrote:
After 2.9.7,
copy and paste on mintty are strange for lines containing wide width characters
(e.g. Japanese Kanji).
Also the cursor position is strange on wide characters
On Sun, 17 Mar 2019 13:56:40 +0900 (JST) Tatsuro MATSUOKA wrote:
> After 2.9.7,
> copy and paste on mintty are strange for lines containing wide width
> characters
> (e.g. Japanese Kanji).
Also the cursor position is strange on wide characters.
It is at the position as if the cha
After 2.9.7,
copy and paste on mintty are strange for lines containing wide width characters
(e.g. Japanese Kanji).
-rw--- 1 MATSUOKA LAB なし 180 3月 30 2018 .serverauth.12420
Copy 180 and paste it to notepad.
It become 0 3.
Tatsuro
--
Problem reports: http://cygwin.com
Thomas Wolff writes:
> I have uploaded mintty 2.9.9 with the following changes:
While you're at it, could you please stop using the release number "0"
for your packages? That's supposed to be used for test packages only
(if you want to make an effort to convey that in the pack
I have uploaded mintty 2.9.9 with the following changes:
Keyboard handling
* Fixed modifyOtherKeys mode 1 to use verbatim control keys.
The homepage is at http://mintty.github.io/
It also links to the issue tracker.
--
Thomas
--
Problem reports: http://cygwin.com/problems.html
FAQ
I have uploaded mintty 2.9.9 with the following changes:
Keyboard handling
* Fixed modifyOtherKeys mode 1 to use verbatim control keys.
The homepage is at http://mintty.github.io/
It also links to the issue tracker.
--
Thomas
I have uploaded mintty 2.9.8 with the following changes:
Unicode and Emoji data
* Unicode 12.0 update.
Keyboard handling
* Fixed control-key reporting in modifyOtherKeys mode to use small
letters.
The homepage is at http://mintty.github.io/
It also links to the issue tracker
I have uploaded mintty 2.9.8 with the following changes:
Unicode and Emoji data
* Unicode 12.0 update.
Keyboard handling
* Fixed control-key reporting in modifyOtherKeys mode to use small
letters.
The homepage is at http://mintty.github.io/
It also links to the issue tracker
I have uploaded mintty 2.9.7 with the following changes:
Highlights (details see below)
* Significant improvements in bidirectional handling.
* Text can be selected with the keyboard.
* Explicit hyperlink attributes.
* Avoid keyboard/echo latency.
Bidirectional rendering
* Fixed
I have uploaded mintty 2.9.7 with the following changes:
Highlights (details see below)
* Significant improvements in bidirectional handling.
* Text can be selected with the keyboard.
* Explicit hyperlink attributes.
* Avoid keyboard/echo latency.
Bidirectional rendering
* Fixed
I have uploaded mintty 2.9.6 with the following changes:
Terminal features
* Fixed bidi "run" handling (~#837).
* Fixed bidi embedding handling (#837).
* HTML export/copy: Fixed HTML style attributes.
Window handling
* Flexible window grouping configuration (#789).
* If st
I have uploaded mintty 2.9.6 with the following changes:
Terminal features
* Fixed bidi "run" handling (~#837).
* Fixed bidi embedding handling (#837).
* HTML export/copy: Fixed HTML style attributes.
Window handling
* Flexible window grouping configuration (#789).
* If st
Thomas Wolff writes:
> Tweaks to HTML clipboard/export feature
> * Flexible HTML formatting levels.
> * Configurable, also in Options dialog.
> * No more table cell container.
> * HTML escaping.
> * Apply styles individually and other tweaks for increased compatibility.
> * Font
?
You have apparently set up some cmd scripts as mintty user commands, so
you're thinking in Windows terms here.
One is very distantly related to another.
I set up programs to work as user commands, it's not actually relevant, if
they are cmd scripts, or perl, both, or neither.
Acknowledged
?
> You have apparently set up some cmd scripts as mintty user commands, so
> you're thinking in Windows terms here.
One is very distantly related to another.
I set up programs to work as user commands, it's not actually relevant, if
they are cmd scripts, or perl, both, or neither.
&g
of knowledge.
BTW, Cygwin itself does it differently. %Cygwin%\bin is converted to /usr/bin.
This setup should be handled in the Posix path domain.
Give me a good reason why should you second-guess Cygwin's own functionality?
You have apparently set up some cmd scripts as mintty user commands, so
Greetings, Thomas Wolff!
> Am 07.12.2018 um 22:41 schrieb Andrey Repin:
>> Greetings, Thomas Wolff!
>>
>>> Am 06.12.2018 um 22:32 schrieb Andrey Repin:
Greetings, Achim Gratz!
> a) Just warn about the missing PATH component without changing the PATH.
> b) Give the user an option
Am 07.12.2018 um 22:41 schrieb Andrey Repin:
Greetings, Thomas Wolff!
Am 06.12.2018 um 22:32 schrieb Andrey Repin:
Greetings, Achim Gratz!
a) Just warn about the missing PATH component without changing the PATH.
b) Give the user an option to let the command run with a separate PATH.
Indeed
Greetings, Thomas Wolff!
> Am 06.12.2018 um 22:32 schrieb Andrey Repin:
>> Greetings, Achim Gratz!
>>
>>> a) Just warn about the missing PATH component without changing the PATH.
>>> b) Give the user an option to let the command run with a separate PATH.
>>> Indeed there might be other things
Am 06.12.2018 um 22:32 schrieb Andrey Repin:
Greetings, Achim Gratz!
a) Just warn about the missing PATH component without changing the PATH.
b) Give the user an option to let the command run with a separate PATH.
Indeed there might be other things that are missing in the environment,
so
On 2018-12-06 12:39, Achim Gratz wrote:
> Thomas Wolff writes:
>> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>>> Thomas Wolff writes:
Ensuring /bin in PATH for user commands.
>>> Blindly prepending /bin to the existing PATH is asking for trouble with
>>> certain setups.
Many setups: my
Greetings, Achim Gratz!
> a) Just warn about the missing PATH component without changing the PATH.
> b) Give the user an option to let the command run with a separate PATH.
> Indeed there might be other things that are missing in the environment,
> so instead of just fixing up PATH you might
Thomas Wolff writes:
> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> Other
>>> * Ensuring /bin in PATH for user commands.
>> Blindly prepending /bin to the existing PATH is asking for trouble with
>> certain setups.
> Just to clarify, this is only applicable to
regular %PATH% at the place I want it. I.e. when
using
tools and commands, I expect them to behave in a certain way.
Changing it have potential to produce unexpected results.
The issue that caused me to apply this change: if you start mintty from
a desktop shortcut, cygwin /bin is not in the PATH
. when using
tools and commands, I expect them to behave in a certain way.
Changing it have potential to produce unexpected results.
The issue that caused me to apply this change: if you start mintty from
a desktop shortcut, cygwin /bin is not in the PATH of mintty (unless you
would set
Greetings, Thomas Wolff!
> Am 05.12.2018 um 21:21 schrieb Achim Gratz:
>> Thomas Wolff writes:
>>> Other
>>> * Ensuring /bin in PATH for user commands.
>> Blindly prepending /bin to the existing PATH is asking for trouble with
>> certain setups.
> Just to clarify, this is only applicable to
Am 05.12.2018 um 21:21 schrieb Achim Gratz:
Thomas Wolff writes:
Other
* Ensuring /bin in PATH for user commands.
Blindly prepending /bin to the existing PATH is asking for trouble with certain
setups.
Just to clarify, this is only applicable to user-defined commands added
to the extended
Thomas Wolff writes:
> Other
> * Ensuring /bin in PATH for user commands.
Blindly prepending /bin to the existing PATH is asking for trouble with
certain setups.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional
I have uploaded mintty 2.9.5 with the following changes:
Window handling
* Fixed startup directory after cloning new window after starting
from desktop shortcut (#784, mintty/wsltty#96).
* Avoiding stale hover indication in unfocussed window.
* Changed default handling of resolution
I have uploaded mintty 2.9.5 with the following changes:
Window handling
* Fixed startup directory after cloning new window after starting
from desktop shortcut (#784, mintty/wsltty#96).
* Avoiding stale hover indication in unfocussed window.
* Changed default handling of resolution
On Dec 1 09:57, Houder wrote:
> On 2018-11-30 14:19, Corinna Vinschen wrote:
> [snip]
>
> > I'm trying to avoid remote debugging so I rather try to reproduce this
> > @work. However, if you're interested in debugging this, set a
> > breakpoint to clk_monotonic_t::now() and observe how the call
On 2018-11-30 14:19, Corinna Vinschen wrote:
[snip]
I'm trying to avoid remote debugging so I rather try to reproduce this
@work. However, if you're interested in debugging this, set a
breakpoint to clk_monotonic_t::now() and observe how the call to the
virtual init() method hangs or crashes.
On 2018-12-01 04:18, Brian Inglis wrote:
On 2018-11-30 01:33, Houder wrote:
[snip]
Now I know, there should be an "GdiPlus.dll" in "system32".
Alas, I have no idea how to recover it (and neither does Microsoft).
Thanks for the feedback, Brian.
You should have a selection of alternatives
tem32, because there is a version of this
> file in the "SxS" location.
> One of my previous posts shows the output of strace (trying to start
> MinTTY from a "Dos box" ...)
> Although comctl32.dll is present in c:/Windows/system32, the file in
> the "Sx
Greetings, Houder!
> Btw, I do not think that the "loss of GdiPlus.dll" on my system explains
> why
> I cannot start MinTTY with Corinna's latest cygwin1.dll ...
> I believe something else is preventing the launch of MinTTY using the
> latest
> cygwin1.dll ...
I
nclear *when* and *why* it happens.
>
> It only occurs if mintty is the first process in a process tree. I.e.,
> when starting mintty from a shell running in a DOS window, the problem
> disappears.
>
> Worse, the problem also disappears when running mintty under gdb.
(I do not
12 loaded C:\Windows\System32\winspool.drv at
> > > 07fef9f1
> > > --- Process 3112, exception c005 at 000180044bb3
> > > --- Process 3112 exited with status 0xc005
> > > Segmentation fault
> >
> > I can reproduce this but while it's clear *where* i
--- Process 3112 exited with status 0xc005
Segmentation fault
I can reproduce this but while it's clear *where* it happens, it's
unclear *when* and *why* it happens.
It only occurs if mintty is the first process in a process tree. I.e.,
when starting mintty from a shell running in a DOS
box" results in a
> > > prompt from bash.
> > >
> > > Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty )
> > >
> > > Placing strace in front of this call, results in:
> > >
> > > 64-@@ strace /usr/bin/mintty
> > &
On 2018-11-30 11:21, Andrey Repin wrote:
Greetings, Houder!
[snip]
Apparently MinTTY requires this DLL.
Q: Should my system (Windows 7) have this DLL? (Is it present
on your system?)
Yes. It is located in WinSxS, as many other versioned DLL's.
I.e. on my system, MinTTY loading
C
Greetings, Houder!
> Because I have a problem w/ Corinna's latest snapshot (using
> MinTTY!), I executed (among others):
> 64-@@ cygcheck mintty
> ...
>C:\Windows\system32\WINSPOOL.DRV
> cygcheck: track_down: could not find gdiplus.dll
> None of the individual DLL's
he "SxS" location.
One of my previous posts shows the output of strace (trying to start
MinTTY from a "Dos box" ...)
Although comctl32.dll is present in c:/Windows/system32, the file in
the "SxS" location is "loaded", not the file available in the former.
On Thu, Nov 29, 2018 at 11:24 PM Houder wrote:
> On 2018-11-29 20:53, Michael Wild wrote:
> > On Thu, 29 Nov 2018, 19:14 Houder wrote:
> [snip]
>
> >> Apparently MinTTY requires this DLL.
> >>
> >> Q: Should my system (Windows 7) have this DLL? (Is it
On 2018-11-29 23:11, Thomas Wolff wrote:
On Nov 29 19:41, Houder wrote:
[snip]
Placing strace in front of this call, results in:
64-@@ strace /usr/bin/mintty
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at
777b
...
--- Process 3112 loaded
C
On 2018-11-29 23:11, Thomas Wolff wrote:
On Nov 29 19:41, Houder wrote:
[snip]
Placing strace in front of this call, results in:
64-@@ strace /usr/bin/mintty
--- Process 3112 created
--- Process 3112 loaded C:\Windows\System32\ntdll.dll at
777b
...
--- Process 3112 loaded
C
On 2018-11-29 20:53, Michael Wild wrote:
On Thu, 29 Nov 2018, 19:14 Houder wrote:
[snip]
Apparently MinTTY requires this DLL.
Q: Should my system (Windows 7) have this DLL? (Is it present
on your system?)
[snip]
Hi
GDI+ is a graphics and font rendering engine that has been part
Am 29.11.2018 um 20:58 schrieb Corinna Vinschen:
On Nov 29 19:41, Houder wrote:
Hi,
As I wrote in the preceding post ...
Using Corinna's latest snapshot in a "Dos box" results in a
prompt from bash.
Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty )
Placing strac
On Nov 29 19:41, Houder wrote:
> Hi,
>
> As I wrote in the preceding post ...
>
> Using Corinna's latest snapshot in a "Dos box" results in a
> prompt from bash.
>
> Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty )
>
> Placing strace in
On Thu, 29 Nov 2018, 19:14 Houder wrote:
> Hi,
>
> Because I have a problem w/ Corinna's latest snapshot (using
> MinTTY!), I executed (among others):
>
> 64-@@ cygcheck mintty
> ...
>C:\Windows\system32\WINSPOOL.DRV
> cygcheck: track_down: could no
Hi,
As I wrote in the preceding post ...
Using Corinna's latest snapshot in a "Dos box" results in a
prompt from bash.
Once in bash, I can launch MinTTY ( 64-@@ /usr/bin/mintty )
Placing strace in front of this call, results in:
64-@@ strace /usr/bin/mintty
--- Process 31
Hi,
Because I have a problem w/ Corinna's latest snapshot (using
MinTTY!), I executed (among others):
64-@@ cygcheck mintty
...
C:\Windows\system32\WINSPOOL.DRV
cygcheck: track_down: could not find gdiplus.dll
None of the individual DLL's from "cygcheck mintty" requires
the g
dows 7 in a VM
2) use rdesktop (ubuntu xenial, rdesktop Version 1.8.3) to connect to
the windows box's desktop (used to run visual studio, etc.)
3) launch mintty, maximize the window
4) run a build that spits out a lot of logging. This can be simulated
with "od /dev/urandom".
On my machine
lines.
> VT100 smooth scroll with No Scroll key toggle was like having more/less built
> in
> to the terminal; VT52 had a Scroll key which supported something similar.
>
> > Mintty does not support smooth scrolling. (I gave it a try once but there
> > is no
> >
ough remote interface.
Glass ttys needed special hardware because the early uP chips running at low
speeds with small ROMs could not do much between displaying lines.
VT100 smooth scroll with No Scroll key toggle was like having more/less built in
to the terminal; VT52 had a Scroll key which supported
401 - 500 of 2214 matches
Mail list logo
