FIXME about GetCompressedFileSizeA was too annoying when running
Cygwin
programs, so I implemented it. The code uses st_blocks when possible
to
account for sparse files and falls back to st_size if st_blocks is
missing
in struct stat. The code uses shift operations so that both systems
with
32-bit and 64-bit off_t will do their best to provide accurate
results.
Works cool, but you could return INVALID_FILE_SIZE when the function fails. I patched it into win32/newfns.c for long time but never sent a patch.
OT : Too bad that we dont have GetProcessMemoryInfo, this is what keeps cygwin programs unable to start into bash.
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thu, 2 Oct 2003, [iso-8859-1] Sylvain Petreolle wrote:
Works cool, but you could return INVALID_FILE_SIZE when the function fails.
Maybe. If the patch is not applied, I'll recheck error codes.
OT : Too bad that we dont have GetProcessMemoryInfo, this is what keeps cygwin programs unable to start into bash.
I don't think it's the reason. GetProcessMemoryInfo is not even present on Windows 98, yet bash works on it.
It seems that all Cygwin programs think that they are using COM1 as terminal (try "wine tty"). That's most likely the reason why bash exits silently. It even displays the prompt if I give it "-i" but then exits seeing that the terminal is closed. GetProcessMemoryInfo is called after that:
<proski@portland bin>$ PS1="WINE/BASH> " wine bash.exe -- -i fixme:cdrom:CDROM_GetInterfaceInfo not implemented for true scsi drives fixme:console:SetConsoleCtrlHandler (0x61011400,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x61011400,1) - no error checking or testing yet err:dosfs:DOSFS_CreateCommPort Couldn't open device '/dev/ttyS0' ! (check permissions) fixme:dosfs:DOSFS_OpenDevice device open L"COM1" not supported (yet) err:file:CreateFileW Couldn't open device L"com1"! err:comm:GetCommState FILE_GetUnixHandle failed fixme:ntdll:NtQueryObject Unsupported information class 1 err:comm:GetCommState FILE_GetUnixHandle failed fixme:ntdll:NtQueryObject Unsupported information class 1 err:dosfs:DOSFS_CreateCommPort Couldn't open device '/dev/ttyS0' ! (check permissions) fixme:dosfs:DOSFS_OpenDevice device open L"COM1" not supported (yet) err:file:CreateFileW Couldn't open device L"com1"! fixme:comm:ClearCommError no handle (nil) found fixme:comm:ClearCommError no handle (nil) found err:comm:GetCommState FILE_GetUnixHandle failed fixme:comm:ClearCommError no handle (nil) found err:comm:GetCommState FILE_GetUnixHandle failed WINE/BASH> fixme:comm:ClearCommError no handle (nil) found fixme:comm:ClearCommError no handle (nil) found fixme:comm:PurgeComm no handle (nil) found exit fixme:psapi:GetProcessMemoryInfo (hProcess=0x48, 0x408c2bf0, 40): stub <proski@portland bin>$
To get rid of the COM1 problem, just run wcmd under wineconsole. wineconsole -- --backend=user wcmd
It seems that all Cygwin programs think that they are using COM1 as terminal (try "wine tty"). That's most likely the reason why bash exits silently. It even displays the prompt if I give it "-i" but then exits seeing that the terminal is closed. GetProcessMemoryInfo is called after that:
This is what I get if I try to run a external command, all internal bash commands work today.
bash-2.05b$ ls
ls
25 [main] bash -12 sync_with_child: child 16(0x104) died before initializat ion with status code 0x1
6891 [main] bash -12 sync_with_child: *** child state waiting for longjmp bash: fork: Resource temporarily unavailable
and on wine output I have : fixme:console:SetConsoleCtrlHandler (0x61011400,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x61011400,1) - no error checking or testing yet fixme:psapi:GetProcessMemoryInfo (hProcess=0x44, 0x40922af0, 40): stub
I've edited /etc/profile and put a comment before all external commands to avoid them in cygwin startup and put a 'set -v' to see all commands runned.
A typical run of cygwin.bat under wineconsole/wcmd gives : (/etc/profile attached)
WCMD Version 0.17
J:\cygwin>cygwin PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
#USER="`id -un`"
# Set up USER's home directory #if [ -z "$HOME" ]; then # HOME="/home/$USER" #fi
if [ ! -d "$HOME" ]; then mkdir -p "$HOME" fi
export HOME USER
#for i in /etc/profile.d/*.sh ; do # if [ -f $i ]; then # . $i # fi #done
export MAKE_MODE=unix #export PS1='[\u@\h \W]$'
cd "$HOME"
test -f ./.bashrc && . ./.bashrc alias ls='ls --color' alias cp='cp -i' alias mv='mv -i' alias rm='rm -i' echo "I'm here!" I'm here! #PS1=[\u@\h \W]$ bash-2.05b$
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Fri, 3 Oct 2003, [iso-8859-1] Sylvain Petreolle wrote:
To get rid of the COM1 problem, just run wcmd under wineconsole. wineconsole -- --backend=user wcmd
Yes, it works. Thank you! But I think that interactive programs using stdin and stdout should be useful without wineconsole. stdin should not be closed, and of course the programs should not think that it's COM1. But I think we'll need to look at Cygwin sources to know what each side thinks about the other side.
This is what I get if I try to run a external command, all internal bash commands work today.
bash-2.05b$ ls
ls
25 [main] bash -12 sync_with_child: child 16(0x104) died beforeinitializat ion with status code 0x1
6891 [main] bash -12 sync_with_child: *** child state waiting for longjmp bash: fork: Resource temporarily unavailable
That almost certainly requires a closer look at Cygwin sources. My guess their implementation of fork() may be OS specific and full of workarounds, especially for Win9x.
-
Pavel Roskin -
Sylvain Petreolle