much more often than
necessary. I
think this could easily explain the performance problems that have been
reported, but I won't have a chance to test this on my (slow) XP system
for a while, and possibly not until tomorrow.
I've confirmed that fixing the typo solves the problem on my XP
this could easily explain the performance problems that have been
reported, but I won't have a chance to test this on my (slow) XP system
for a while, and possibly not until tomorrow.
I've confirmed that fixing the typo solves the problem on my XP system.
I suspect that this issue is not
Thank you Ken for first providing a useable patch and then finding the problem!
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
point in the
>> code, so it makes no sense to test that.) As a result,
>> g_wakeup_acknowledge() is being called much more often than necessary. I
>> think this could easily explain the performance problems that have been
>> reported, but I won't have a chance to test
t;wake_up_rec.events is always nonzero at this point in the
code, so it makes no sense to test that.) As a result,
g_wakeup_acknowledge() is being called much more often than necessary. I
think this could easily explain the performance problems that have been
reported, but I won't have a chance to t
this point in the
code, so it makes no sense to test that.) As a result,
g_wakeup_acknowledge() is being called much more often than necessary.
I think this could easily explain the performance problems that have
been reported, but I won't have a chance to test this on my (slow) XP
system
On 6/11/2012 11:10 AM, Ken Brown wrote:
On 6/11/2012 7:39 AM, Ken Brown wrote:
On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae4
rebaseall appears to resolved the issue. GVim is running as expected!
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Once again, please don't http://cygwin.com/acronyms/#TOFU .
On 6/11/2012 12:14 PM, K Stahl wrote:
I've reverted the suggested libraries and still no success with GVim.
Keep getting either a failed execution (exit code 127) or bad address
for /usr/bin/gvim.
Try running rebaseall. If that doesn
I've reverted the suggested libraries and still no success with GVim.
Keep getting either a failed execution (exit code 127) or bad address
for /usr/bin/gvim.
>
>
> On 6/11/2012 9:55 AM, K Stahl wrote:
>>
>> I've tried to revert the version of GLib 2.0 using the instructions
>> provided, but when
On 6/11/2012 7:39 AM, Ken Brown wrote:
On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
A
Please don't http://cygwin.com/acronyms/#TOFU . Thanks.
On 6/11/2012 9:55 AM, K Stahl wrote:
I've tried to revert the version of GLib 2.0 using the instructions
provided, but when I attempt to start GVim nothing happens. The
process appears to fail without an explanation. System WinXP and all
I've tried to revert the version of GLib 2.0 using the instructions
provided, but when I attempt to start GVim nothing happens. The
process appears to fail without an explanation. System WinXP and all
Cygwin libs updated to the latest.
On Sun, Jun 10, 2012 at 8:45 PM, Ken Brown wrote:
> On 6/8/
On 6/10/2012 10:54 PM, Yaakov (Cygwin/X) wrote:
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie
Date: Wed Aug 31 22:0
On 2012-06-10 19:45, Ken Brown wrote:
The bisection shows that the first problematic commit is this one:
http://git.gnome.org/browse/glib/commit/?h=glib-2-32&id=7eae486179e2799c369ed9ffcea663bf9161ce79
Author: Ryan Lortie
Date: Wed Aug 31 22:07:02 2011 -0400
GMain: simplify logic for g_wakeu
On 6/8/2012 12:45 PM, Ken Brown wrote:
On 6/8/2012 11:33 AM, Achim Gratz wrote:
Ken Brown writes:
As I said earlier, I don't understand very well how git branches work,
but I *think* this means we have to look in the 2-32 branch, prior to
the 2.31.0 tag, to find the problematic commit. I've che
Greetings, Ken Brown!
> Thanks, Achim. That helps a lot. The only thing I might have to change
> is the starting point for the bisection, since the tag 2.30.3 represents
> a fairly recent commit. But I think starting with 2.30.1 should work.
> I'll give it a try.
Why not slice relevant branc
On 6/8/2012 11:33 AM, Achim Gratz wrote:
Ken Brown writes:
As I said earlier, I don't understand very well how git branches work,
but I *think* this means we have to look in the 2-32 branch, prior to
the 2.31.0 tag, to find the problematic commit. I've checked out the
2-32 branch, and I guess t
Ken Brown writes:
> As I said earlier, I don't understand very well how git branches work,
> but I *think* this means we have to look in the 2-32 branch, prior to
> the 2.31.0 tag, to find the problematic commit. I've checked out the
> 2-32 branch, and I guess the next step is to find a problem-fr
On 6/6/2012 7:04 AM, Stephen L wrote:
Ken Brown cornell.edu> writes:
Never mind. I'm not up to this task. But if you're willing to
facilitate the bisection by doing the builds, I'll be glad to test them
on my XP system, at least as far as emacs is concerned. And I'm sure
there are gvim user
Ken Brown cornell.edu> writes:
> Never mind. I'm not up to this task. But if you're willing to
> facilitate the bisection by doing the builds, I'll be glad to test them
> on my XP system, at least as far as emacs is concerned. And I'm sure
> there are gvim users who would do the same.
ok so
On Mon, 04 Jun 2012 11:49:07 -0400, Ken Brown wrote:
| | |The emacs is not the only application, which is very slow now.
| | |Take a look at gvim.
| | |
| | |
| | |For my purpose I have not installed the changes to GNOME and work
| | |still with the old versions.
| | |With the f
On 6/3/2012 8:10 AM, Ken Brown wrote:
On 6/3/2012 5:08 AM, Yaakov (Cygwin/X) wrote:
On 2012-06-02 14:02, Ken Brown wrote:
I hope someone (Yaakov?) will take a look at the glib changes between
2.30.2 and 2.32.2 and try to find the cause of this problem.
I keep seeing XP in this thread. If this
On 6/3/2012 5:08 AM, Yaakov (Cygwin/X) wrote:
On 2012-06-02 14:02, Ken Brown wrote:
I hope someone (Yaakov?) will take a look at the glib changes between
2.30.2 and 2.32.2 and try to find the cause of this problem.
I keep seeing XP in this thread. If this is affecting only XP and not
other ver
On 2012-06-02 14:02, Ken Brown wrote:
I hope someone (Yaakov?) will take a look at the glib changes between
2.30.2 and 2.32.2 and try to find the cause of this problem.
I keep seeing XP in this thread. If this is affecting only XP and not
other versions of Windows, then it would be a bug in e
On 6/2/2012 11:09 AM, Ken Brown wrote:
We can revert by using the CTM (Cygwin Time Machine):
http://www.fruitbat.org/Cygwin/index.html#cygwintimemachine
I'm hoping to do that this weekend on my XP machine and see if I can pin
down when the problem started. I made some incorrect statements about
On 6/2/2012 10:15 AM, Angelo Graziosi wrote:
Ken,
Ken Brown wrote:
Is this on XP? I ask because I'm having trouble reverting my XP system
back to a state where there's no problem.
I think we cannot revert because many of "prev" packages have been
removed by Cygwin distro.
We can revert by
Ken,
Ken Brown wrote:
Is this on XP? I ask because I'm having trouble reverting my XP system back to
a state where there's no problem.
I think we cannot revert because many of "prev" packages have been
removed by Cygwin distro.
Anyway, I have only XP and Emacs 24 from trunk, and it cannot
On 6/1/2012 2:17 AM, Pach Roman (DGS-EC/ESG2) wrote:
The emacs is not the only application, which is very slow now.
Take a look at gvim.
For my purpose I have not installed the changes to GNOME and work
still with the old versions.
With the following packages everything is running as fast as ear
This morning, I reverted GLib2.0 to a previous version and it did not
solve the issue.
Steps used in testing:
Extracted "libglib2.0_0-2.30.2-1.tar.bz2" and ran /etc/postinstall/glib2.0.sh
Started XWin and attempted to edit a file via gvim (performance issue
still remain)
On Fri, Jun 1, 2012 at 2:
On 6/1/2012 7:00 AM, Ken Brown wrote:
I found an XP system that hadn't been upgraded in a few weeks, and I
upgraded libglib2.0_0 but nothing else. This was enough to trigger the
problem.
I've checked the git repository for glib at
http://git.gnome.org/browse/glib/log/?h=glib-2-32
and there
Ken Brown cornell.edu> writes:
> Fortunately for emacs users, the problem doesn't seem to occur with
> emacs-24. (Can anyone else confirm this?)
Hi Ken,
So I just upgraded to emacs-24 (24.0.96.1), and while it is certainly better, I
wouldn't say it's fixed.
Try opening a text file (I have a ~
[Reformatted. Please don't top-post.]
On 6/1/2012 7:20 AM, xxx@xxx wrote:
On Fri, Jun 1, 2012 at 1:00 PM, Ken Brown wrote:
On 5/31/2012 4:51 PM, Angelo Graziosi wrote:
My upgrade regarded these packages:
_autorebase-69-1.tar.bz2
_update-info-dir-01051-1.tar.bz2
fftw3-3.3.2-1.tar.bz2
g
Hello,
Sorry, I have the same issue with emacs24 (GNU Emacs 24.0.96.1
(i686-pc-cygwin, GTK+ Version 2.24.10)).
Well it seems this EMACS 24 is built with GTK2.
This is the emacs package 24.0.96-2 I installed with setup.exe.
Regards
Fabien
On Fri, Jun 1, 2012 at 1:00 PM, Ken Brown wrote:
>
> On
On 5/31/2012 4:51 PM, Angelo Graziosi wrote:
My upgrade regarded these packages:
_autorebase-69-1.tar.bz2
_update-info-dir-01051-1.tar.bz2
fftw3-3.3.2-1.tar.bz2
glib2.0-networking-2.32.3-1.tar.bz2
gsettings-desktop-schemas-3.4.2-1.tar.bz2
gtk3-demo-3.4.3-1.tar.bz2
gvfs-1.12.3-1.tar.bz2
libff
The emacs is not the only application, which is very slow now.
Take a look at gvim.
For my purpose I have not installed the changes to GNOME and work
still with the old versions.
With the following packages everything is running as fast as earlier
release/GNOME/GConf2/GConf2-3.2.5-1.tar.bz2
Ken Brown wrote:
Yes, that is a lot of packages (almost 200). I don't think that will be of any
help in pinning down the problem.
My upgrade regarded these packages:
_autorebase-69-1.tar.bz2
_update-info-dir-01051-1.tar.bz2
fftw3-3.3.2-1.tar.bz2
glib2.0-networking-2.32.3-1.tar.bz2
gsetti
On 5/31/2012 4:45 AM, Stephen L wrote:
Ken Brown cornell.edu> writes:
Which packages got upgraded? You can check this by looking at
/var/log/setup.log.
unfortunately, a lot of packages were upgraded, as it is some while since I last
did an upgrade :(
Yes, that is a lot of packages (almos
Ken Brown cornell.edu> writes:
> Which packages got upgraded? You can check this by looking at
> /var/log/setup.log.
unfortunately, a lot of packages were upgraded, as it is some while since I last
did an upgrade :(
fyi I put the log here:
http://whelk.landamore.com/setup.log.gz
best regards
On 5/30/2012 6:51 AM, Stephen L wrote:
I just upgraded this morning and can confirm emacs is also very sluggish for me
also.
I'm running windows xp pro 2002 sp 3, if that is any help.
Let me know if you need any more information and/or help testing,
Which packages got upgraded? You can check
I just upgraded this morning and can confirm emacs is also very sluggish for me
also.
I'm running windows xp pro 2002 sp 3, if that is any help.
Let me know if you need any more information and/or help testing,
best regards,
stephen
--
Problem reports: http://cygwin.com/problems.html
FAQ
Thu, May 24, 2012 at 08:51AM -0400 Ken Brown wrote:
> On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
> >After an cygwin-upgrade this morning I'm experiencing performance
> >problems with emacs-X11 (23.4.2). The performance problem seem to be
> >graphics relate
Hi Ken,
Ken Brown wrote:
I've noticed the same thing on my XP
I notice this, yesterday, after the upgrade announcede here:
http://cygwin.com/ml/cygwin-xfree/2012-05/msg00040.html
My builds of Emacs trunk, do not work any more correctly after the
upgrade. Emacs is very very slow...
Thi
his morning I'm experiencing performance problems
>> with emacs-X11 (23.4.2). The performance problem seem to be graphics
>> related. Window redraw is really slow, it can take up to a couple of seconds
>> to redraw the emacs window. Scrolling the cursor up or down in emacs i
On 5/24/2012 8:32 AM, Berglund Magnus (SE) wrote:
After an cygwin-upgrade this morning I'm experiencing performance problems with
emacs-X11 (23.4.2). The performance problem seem to be graphics related. Window
redraw is really slow, it can take up to a couple of seconds to redraw the
Boris Ouretskey wrote:
> I have severe performance problems with cygwin. Cygwin becomes almost
> unusable.
>
> The problem seems to go away when cygwin window is out of focus, e.g.
> when I click on some other window (not cygwin), cygwin performance
> rapidly increases.
>
Hi,
I have severe performance problems with cygwin. Cygwin becomes almost
unusable.
The problem seems to go away when cygwin window is out of focus, e.g.
when I click on some other window (not cygwin), cygwin performance
rapidly increases.
It has something with output to console window. When I
On Tue, Jun 07, 2005 at 08:44:40AM +0200, Jacek Piskozub wrote:
>Christopher Faylor wrote:
>>I guess eventually all of those old Win9x systems will have to stop
>>working and people will have to buy new XP systems. Who knows when
>>that will happen, though?
>
>Correction. Some of us will migrate
On Mon, Jun 06, 2005 at 06:51:46PM -0700, Linda W wrote:
>>>separate thread running which manages this (which implies careful
>>attention to locking issues and context switching) or you a schedule
>> timer signal (which has similar problems).)
>>
>>
>This may not be necessary if you only cache fil
Christopher Faylor wrote:
I guess eventually all of those old Win9x systems will have to stop
working and people will have to buy new XP systems. Who knows when
that will happen, though?
Correction. Some of us will migrate directly to Linux. I personally use
WindowsME for the win32 program
This may not be necessary if you only cache file handles within
1 execution of a program (like find), so that file-ops within the same
program achive speedup. You could time-out cache entries on an
as-needed basis or timer.
I was filling in the details here just to show that the solutio
On Jun 6 11:31, Corinna Vinschen wrote:
> On Jun 2 18:32, Brian Dessent wrote:
> > In order to implement stat(), cygwin has to call NtQueryInformationFile
> > (GetFileInformationByHandle for 9x/me) and this requires the file to be
> > opened. Thus the reason that stat takes forever is that each
On Jun 2 15:00, Christopher Faylor wrote:
> You could do things the other way around, so that NtCreateFile is used
> in the main code which invokes a NtCreateFile wrapper for 9x systems but
> I am leery of doing things this way since that means that the only
> people capable of writing code for cy
On Jun 2 18:32, Brian Dessent wrote:
> In order to implement stat(), cygwin has to call NtQueryInformationFile
> (GetFileInformationByHandle for 9x/me) and this requires the file to be
> opened. Thus the reason that stat takes forever is that each file has
There would be a theoretical way around
Yuk. Top-posting. Reformatted.
On Sun, 5 Jun 2005, Linda W wrote:
> Igor Pechtchanski wrote:
>
> > [snip]
> > Again, IMO, it would be ok to make Win9x functionality slower,
> > external to the Cygwin DLL, etc, etc, but I don't think dropping it
> > altogether is a good idea.
> > Igor
>
> On
On Sun, Jun 05, 2005 at 11:46:52PM -0400, Christopher Faylor wrote:
>I am talking about cache coherency.
It occured to me that I'm using the term "cache coherency" incorrectly
here. What I really mean to say is that Windows is in charge of all
file operations and so can and does maintain a consis
On Sun, Jun 05, 2005 at 08:00:44PM -0700, Linda W wrote:
>Christopher Faylor wrote:
>>On Sat, Jun 04, 2005 at 03:00:13PM -0700, Linda W wrote:
>>>You are technically accurate, but the cygwin layer is a POSIX
>>>complient-OS emulation layer by some definition, no?
>>
>>Yes, but that has nothing to d
for 10 milliseconds, might have saved nearly
90% of the calls to Windows. Windows is hardly a real-time OS where
tolerances need millisecond precision -- the clock defaults to about
a 20Hz clock speed unless you've tweaked it.
However, you spend time writing how no one _ever_ investigates
On Sun, Jun 05, 2005 at 12:52:58AM -0600, Warren Young wrote:
>Christopher Faylor wrote:
>>Well, *eventually* cygwin will be dropping cgf and corinna support.
>
>Is that another way of saying "over my dead [or MIA] body"?
I really don't know what I was trying to say, actually. :-)
Maybe I was sa
One wouldn't have to suffer much in performance...
see http://sourceware.org/ml/cygwin/2005-06/msg00087.html.
Dynamic library linking is relatively cheap -- cheaper if the
user has the option to pre-install the lib for their OS-flavor.
Igor Pechtchanski wrote:
Just a datapoint. WinXP does *
Christopher Faylor wrote:
Well, *eventually* cygwin will be dropping cgf and corinna support.
Is that another way of saying "over my dead [or MIA] body"?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation:
On Sat, Jun 04, 2005 at 08:55:08PM -0400, Christopher Faylor wrote:
>I merely represented our current thinking about the subject that you
>raised.
Oh, on rereading this thread, I remembered that the main reason that I
responded at all was that Igor suggested SHTDI and PTC. I thought it
behooved m
#x27;t know but, regardless, this would increase the possibility for
surprise to include local disks too. I'm not convinced that this is a
good thing. This would make the behavior that Gary R. Van Sickle
recently reported as the result of using google search (I think it was
google search
his separately and/or
in parallel. If so, all the better -- it indicates some form
of "synchronicity" (in the Jungian sense) -- an idea whose time
has come.
However, you spend time writing how no one _ever_
investigates performance problems or suggests solutions.
That appears to be a cynical v
On Fri, Jun 03, 2005 at 11:25:38AM -0400, Jim Drash wrote:
>Since Cygwin is open source, there is nothing stopping anyone from
>taking the current source for themseleves and doing what they will
>(as long as they give back ). It is possible that someone
>who cared about having a Win9x Cygwin port
Since Cygwin is open source, there is nothing stopping anyone from
taking the current source for themseleves and doing what they will
(as long as they give back ). It is possible that someone
who cared about having a Win9x Cygwin port would take up the
maintainance (not unlike the folks who contin
On Fri, Jun 03, 2005 at 09:16:14AM -0600, Warren Young wrote:
>Christopher Faylor wrote:
>>For the record: We are not dropping Win9x support.
>
>Not now, but eventually, I hope?
Well, *eventually* cygwin will be dropping cgf and corinna support. Who
knows what will happen after that point?
cgf
Christopher Faylor wrote:
For the record: We are not dropping Win9x support.
Not now, but eventually, I hope?
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
Christopher Faylor wrote:
> Keith, you don't have a complete reference for the Nt functions do
you?
Keith Moore wrote:
> So, unfortunately, I don't have a complete reference, but there are
> enough "islands of information" around for us to piece together
> everything we need.
Have you looked at
On Fri, Jun 03, 2005 at 12:05:28PM +0200, Keith Moore wrote:
>Christopher Faylor wrote:
>
>> Keith, you don't have a complete reference for the Nt functions do you?
>
>For the most part, using the APIs is pretty straight-forward if you have
>the required prototypes and structure definitions. With t
For the record: We are not dropping Win9x support.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
-
From: On Behalf Of Gerrit P. Haase
Sent: Thursday, June 02, 2005 5:33 PM
Subject: Re: Drop Win9x support? (was: Serious performance problems)
Terry Dabbs wrote:
> No!
>
> I am supporting applications requiring cygwin on '95 and '98 that are
> not going away anytime so
Original Message
>From: Keith Moore
>Sent: 03 June 2005 11:05
> Christopher Faylor wrote:
>
>> Keith, you don't have a complete reference for the Nt functions do you?
>
> For the most part, using the APIs is pretty straight-forward if you have
> the required prototypes and structure defi
Christopher Faylor wrote:
> Keith, you don't have a complete reference for the Nt functions do you?
For the most part, using the APIs is pretty straight-forward if you have
the required prototypes and structure definitions. With the possible
exception of NtCreateProcess(), there is not a lot of "
On Thu, Jun 02, 2005 at 11:21:16PM -0400, Larry Hall wrote:
>At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>>I think you will find that the cygwin DLL (and most of the base system)
>>>you are using now was probably cross-compiled.
At 09:40 PM 6/2/2005, Christopher Faylor wrote:
>On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>>I think you will find that the cygwin DLL (and most of the base system)
>>you are using now was probably cross-compiled.
>
>Yup. And, these days, it's cross-compiled on a Debian-based
On Thu, Jun 02, 2005 at 06:32:00PM -0700, Brian Dessent wrote:
>I think you will find that the cygwin DLL (and most of the base system)
>you are using now was probably cross-compiled.
Yup. And, these days, it's cross-compiled on a Debian-based system.
cgf
--
Unsubscribe info: http://cygwin
Igor Pechtchanski wrote:
On Fri, 3 Jun 2005, Gerrit P. Haase wrote:
Terry Dabbs wrote:
No!
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
I have not seen any Win98/ME PC since about 5 years, we're using NT all
over the place. As I sta
Linda W wrote:
> Not everyone can do all things. I didn't "speculate" on the cause, I
> noticed multiple opens for a program that really only needs stat/lstat I
> believe.
In order to implement stat(), cygwin has to call NtQueryInformationFile
(GetFileInformationByHandle for 9x/me) and
On Thu, Jun 02, 2005 at 11:57:26PM +0200, Ralf Habacker wrote:
>Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
>> Igor Pechtchanski wrote:
>>>Dropping it altogether would be unfortunate. Providing Win98 support
>>>DLLs in a separate package is a possibility. There's still the point
>>>tha
I know, but truthfully, you are taking my response a bit out of context.
I was responding, specifically to CFG's message:
Christopher Faylor wrote:
> Yep. This is pretty much what I expected. Now we'll see a stream of
> people commenting on slowness and speculating on the cause without
> spen
Might it be possible to build 2 versions and have the package
dynamically install the correct version?
On the other hand, instead of "if (win98)..." one could have a
cygwin1.dll that chooses a 2nd library to load and all entry points are
either runtime indirect calls into the 2nd library (cygwin_
On Fri, 3 Jun 2005, Gerrit P. Haase wrote:
> Terry Dabbs wrote:
>
> > No!
> >
> > I am supporting applications requiring cygwin on '95 and '98 that are
> > not going away anytime soon.
>
> I have not seen any Win98/ME PC since about 5 years, we're using NT all
> over the place. As I started to wo
Terry Dabbs wrote:
No!
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
I have not seen any Win98/ME PC since about 5 years, we're using NT all
over the place. As I started to work in this business NT4 was current,
then W2K came up, now every
Terry Dabbs wrote:
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
That's fine, but do you really need new functionality?
Again, I'm not saying "delete all Cygwin binaries that support Win9x".
I'm saying "stop requiring Win9x compatibility i
No!
I am supporting applications requiring cygwin on '95 and '98 that are
not going away anytime soon.
Terry
Gerrit P. Haase wrote:
>
> Alternatively, we could drop Win98 support.
Yes!
The requirement made sense back when WinXP wasn't dominant yet. By now,
the last machines still running Wi
Gerrit P. Haase wrote:
Alternatively, we could drop Win98 support.
Yes!
The requirement made sense back when WinXP wasn't dominant yet. By now,
the last machines still running Win9x are dying or being replaced at a
fairly high rate. I'm glad Cygwin was available during the years it's
tak
Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore:
> Igor Pechtchanski wrote:
>
> > Dropping it altogether would be unfortunate. Providing Win98 support DLLs
> > in a separate package is a possibility. There's still the point that CGF
> > raised, about there being many more people with the k
Igor Pechtchanski wrote:
> Dropping it altogether would be unfortunate. Providing Win98 support DLLs
> in a separate package is a possibility. There's still the point that CGF
> raised, about there being many more people with the knowledge of Win32 API
> than those with the knowledge of Nt* API.
On Thu, 2 Jun 2005, Gerrit P. Haase wrote:
> Igor Pechtchanski wrote:
>
> > On Thu, 2 Jun 2005, Robb, Sam wrote:
> > > Is there any reason why the cygwin DLL couldn't be built
> > > twice: once for Win9x, and once for WinNT-based systems?
> > >
> > > Aside from potential installation issues ("inst
Igor Pechtchanski wrote:
On Thu, 2 Jun 2005, Robb, Sam wrote:
Is there any reason why the cygwin DLL couldn't be built
twice: once for Win9x, and once for WinNT-based systems?
Aside from potential installation issues ("install this
version of the DLL under 9x, that version under NT), it
seems
Gerrit P. Haase wrote:
> Sunil wrote:
>
>> machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
>> on W2K, -> build time for texinfo = 345 seconds.
>> machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
>> cygwin 1.5.17 on WinXP, -> build time for texinfo =
>> 334 seconds.
>
>
> -> 345 seconds vs
On Thu, Jun 02, 2005 at 02:38:06PM -0400, Robb, Sam wrote:
>>OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
>>if it wasn't for the requirement that everything has to work on Windows
>>9x, the DLL would be smaller and faster. Instead, every system call
>>currently needs to h
Sunil wrote:
machine 1: 533Mhz, 10GB 5400rpm disk, 384MB RAM, SFU
on W2K, -> build time for texinfo = 345 seconds.
machine 2: 2400Mhz, 100GB 7200rpm disk, 768MB RAM,
cygwin 1.5.17 on WinXP, -> build time for texinfo =
334 seconds.
-> 345 seconds vs. 334 seconds
So actually, cygwin is faster t
On Thu, 2 Jun 2005, Robb, Sam wrote:
> > OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
> > if it wasn't for the requirement that everything has to work on
> > Windows 9x, the DLL would be smaller and faster. Instead, every
> > system call currently needs to have a "do thi
> OTOH, Corinna is hard at work adding low-level Nt* calls to cygwin so,
> if it wasn't for the requirement that everything has to work
> on Windows
> 9x, the DLL would be smaller and faster. Instead, every system call
> currently needs to have a "do this if it's NT and that if
> it's 9x" test
>
On Thu, Jun 02, 2005 at 11:04:40AM -0700, Sunil wrote:
>>Any favorable mention of SFU on this list had better be a joke. :-)
>
>:)
>
>but can't deny the truth. Seriously, open source on windows can't do
>better than what it does(upto the limits provided by OS) in terms of
>efficiency. Its hardly
On Thu, 2 Jun 2005, Sunil wrote:
> > Any favorable mention of SFU on this list had better
> > be a joke. :-)
>
> :)
>
> but can't deny the truth. Seriously, open source on
> windows can't do better than what it does(upto the
> limits provided by OS) in terms of efficiency. Its
> hardly at fault, t
> Any favorable mention of SFU on this list had better
> be a joke. :-)
:)
but can't deny the truth. Seriously, open source on
windows can't do better than what it does(upto the
limits provided by OS) in terms of efficiency. Its
hardly at fault, the thing below it is so darn closed.
Everything on
On Thu, Jun 02, 2005 at 01:02:30PM -0400, Igor Pechtchanski wrote:
>On Thu, 2 Jun 2005, Linda W wrote:
>>In tracing the Win32 file operations, find seems to perform multiple
>>file open operations for each file processed. One way to speed up
>>operations in this area might be to keep a "cache" of
1 - 100 of 147 matches
Mail list logo
