May 2002 - Wine-Devel - list.winehq.org

Re: wine can't find regedit.exe.so when it is not on the path

by Andriy Palamarchuk

--- Dustin Navea <speeddymon(a)yahoo.com> wrote: <skipped> > I do believe that you are running the wrong > regedit... > is /prj/wine your wine install dir or did you > install > to the default wine install dir (/usr/local/bin)? No, this is not wine install dir - this is wine source dir. And wineinstall runs not the installed regedit, it runs the one, compiled in the source three. This is how regedit path is defined in wineinstall: REGEDIT=programs/regedit/regedit I don't think there are other options of interpreting location of regedit. > If > you installed to the default winr install dir, run > that one... I also ran into the problem of "not > accessible from a configured dos drive" for the wine > progs, so I added a symlink to the .exe and the > .exe.so in my fake c drive windows directory and > everything worked like a charm... wineinstall script should run regedit from the source tree succesfully or it should be changed to run it from /usr/local/bin directory. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 31, 2002

Re: Problem with 64-bit file functions declarations

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > The same happens for some other file functions. > What is the correct fix for this problem? Just remove msvcrt from the import list, it isn't needed (or if you really want to use msvcrt, then you have to use the msvcrt headers too instead of the libc ones). -- Alexandre Julliard julliard(a)winehq.com

May 31, 2002

Re: wine can't find regedit.exe.so when it is not on the path

by Dustin Navea

--- Andriy Palamarchuk <apa3a(a)yahoo.com> wrote: > wineinstall fails because wine can't find > regedit.exe.so. > Obviously, the wine source directory does not exist > in > path of just created config file. > After the wineistall failure .wine directory with > config file are created. I get the same errors when > I > try to run regedit manually, even with using full > path: > > $ /prj/wine/programs/regedit/regedit > Could not stat /mnt/fd0 (No such file or directory), > ignoring drive A: > Could not stat /cdrom (No such file or directory), > ignoring drive D: > Warning: could not find wine config [Drive x] entry > for current working directory /mnt/buf/prj/wine; > starting in windows directory. > Warning: /prj/wine/programs/regedit/regedit.exe.so > not > accessible from a configured DOS drive > Warning: /prj/wine/programs/regedit/regedit.exe.so > not > accessible from a configured DOS drive > /prj/wine/miscemu/wine: cannot find > '/prj/wine/programs/regedit/regedit.exe.so' > > $ file /prj/wine/programs/regedit/regedit.exe.so > /prj/wine/programs/regedit/regedit.exe.so: ELF > 32-bit > LSB shared object, Intel 80386, version 1, not > stripped > > $ ls -l programs/regedit/regedit > lrwxrwxrwx 1 apalamar apalamar 23 May 30 > 06:53 programs/regedit/regedit -> > ../../tools/winewrapper > > Andriy > I do believe that you are running the wrong regedit... is /prj/wine your wine install dir or did you install to the default wine install dir (/usr/local/bin)? If you installed to the default winr install dir, run that one... I also ran into the problem of "not accessible from a configured dos drive" for the wine progs, so I added a symlink to the .exe and the .exe.so in my fake c drive windows directory and everything worked like a charm... -Dustin P.S. maybe I should put that symlink creation into the makefile or wineinstall? I would think the makefile would be the better place for it as not everyone runs wineinstall, and therefore may not get the symlinks if i put it there... __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 31, 2002

Re: PATCH: libntddl.so not found

by Dustin Navea

Hmmm, I found some problems with this: +print NEWMAKE <<EOF; shouldn't that be printf ? + \@if test -f /etc/ld.so.conf -a -z "`grep \$(libdir) /etc/ld.so.conf`" ; \\ shouldn't that be \$(LIBDIR) + echo " Add the line '\$(libdir)' to /etc/ld.so.conf" ; \\ I think that escaping the $ in this line is unnecessary as it this prints "$(libdir)" instead of the contents of that variable, and also libdir should be capitalized there too... + echo " export LD_LIBRARY_PATH=\$(libdir):\$LD_LIBRARY_PATH" ; \\ Same as above except that it doesn't apply to \$LD_LIBRARY_PATH as we want "$LD_LIBRARY_PATH" to be printed... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 31, 2002

Problem with 64-bit file functions declarations

by Andriy Palamarchuk

I'm researching an issue when started regedit.exe fails to export registry. This started to happen after Alexandre's patch which included "config.h" in the regedit source file. I found out this problem was triggered by declaration #define _FILE_OFFSET_BITS 64 in config.h. The test case: ******************************************** /* Set this to 64 to enable 64-bit file support on Linux */ #define _FILE_OFFSET_BITS 64 #include <stdio.h> #include <windows.h> void test_write(void) { FILE *f = fopen("1.reg", "w"); printf("sizeof FILE: %d\n", sizeof(FILE)); fputs("DEBUG1\n", f); fclose(f); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { test_write(); exit(0); } ******************************************** Comment out the macro definition and it works, with macro it creates file of 0 length. With the defined macro many file functions are defined as functions for 64-bit access and are linked to the native platform calls instead of msvcrt ones. Differences in precompilation output: Without macro: # 203 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) ; With macro: # 211 "/usr/include/stdio.h" 3 extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) __asm__ ("" "fopen64"); The same happens for some other file functions. What is the correct fix for this problem? Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 31, 2002

Re: DOS memory Question..... or How to increase base memory for DOS apps

by Steven Edwards

I belive this is what the TWIN project did for there x86/Win Emulation based on WINE. TWIN is LGPL and wine has never been able to use that code untill now. - > do everything cleanly and even then, it may not fix > every dos app, or even worse it could break some > non-dos app in unforeseen ways... What is DOSEmu > licensed under and is it actually open source? I'm > wondering, maybe if it is under a compatible license > and open source, couldn't we take the DOS3CALL or > int21h routines (or at least parts of them) from > there... __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 31, 2002

Re: DOS memory Question..... or How to increase base memory for DOS apps

by Dustin Navea

--- Christian Costa <titan.costa(a)wanadoo.fr> wrote: > Hi, Hi! > Many DOS apps needs a lot of base memory even if EMS > or XMS memory are used. > > The first 64K of memory being lock to catch null > pointer, the DOS memory > must start > at 0x10000 as you can see in the code below > (msdos/dosmem.c) : > -snip- > > Changing this value to the end of the BIOS DATA area > (0x500) does the > job and things work > as expected (at least for DOS apps). > But I was told that this causes problems for others > apps. > Probably for Win16 ones that use DOS3CALL and not > int21h via DPMI. > I don't know it if is possible, but if that is true, why not just emulate int21h calls when DOS3CALL is called when we are running a win16 app, and the rest of the time, leave everything be? Or better yet, why not change the value to the end of the bios data area only when we are running pure dos apps? > If it's true, a solution could be to initialize DOS > memory differently > for pure DOS apps > by modifying the DOSMEM_Init function. > > DOSMEM_Init is called at 3 different places : > - process_attach in dlls/kernel/kernel_main.c > - DOSVM_Init in dlls/winedos/dosvm.c > - MZ_InitMemory in dlls/winedos.dosvm.c > > and acts differently the first and second calls. > > Since I don't know wine internals enough and the > "flow of execution", I > have no idea how > to do it in a clean way that do not break > everything. > > If someone can help me or give me hints? > Or you could do that, but there is no sure-fire way to do everything cleanly and even then, it may not fix every dos app, or even worse it could break some non-dos app in unforeseen ways... What is DOSEmu licensed under and is it actually open source? I'm wondering, maybe if it is under a compatible license and open source, couldn't we take the DOS3CALL or int21h routines (or at least parts of them) from there... -Dustin __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 31, 2002

Re: PATCH: libntddl.so not found

by Marcus Meissner

On Fri, May 31, 2002 at 08:12:24AM -0700, Dustin Navea wrote: > Hmmm, I found some problems with this: > > +print NEWMAKE <<EOF; > > shouldn't that be printf ? No, there are no % formatting strings inside. > + \@if test -f /etc/ld.so.conf -a -z "`grep \$(libdir) > /etc/ld.so.conf`" ; \\ > > shouldn't that be \$(LIBDIR) No, I am evaluating the libdir Make variable. > + echo " Add the line '\$(libdir)' to > /etc/ld.so.conf" ; \\ > > I think that escaping the $ in this line is > unnecessary as it this prints "$(libdir)" instead of > the contents of that variable, and also libdir should > be capitalized there too... perl expands that to $(libdir), which make expands to /usr/local/lib. If I would have use $(libdir) perl would have printed $( and libdir). > + echo " export > LD_LIBRARY_PATH=\$(libdir):\$LD_LIBRARY_PATH" ; \\ > > Same as above except that it doesn't apply to > \$LD_LIBRARY_PATH as we want "$LD_LIBRARY_PATH" to be > printed... Hmm, LD_LIBRARY_PATH is not printed correctly. But I do not know how to let make escape that correctly. Btw, why didn't you try the code before complaining? Ciao, Marcus

May 31, 2002

Re: Keyboard layout detection not working??

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > I am also having trouble editing keyboard.c with snavigator. Upon > saving, it totally screws up the non-ASCII characters in the keyboard > layouts. It didn't used to do that (I played with the default charset, > and wound up on ASCII at the end), but what do the list have to say > about converting the whole string to \x notation? I strongly disagree. And the readability is the main reason. > Your native keyboard > will be less readable on your personal machine, but the file will stand > a lot less chances of corruption. Till now, there was no such a problem. So I personally suggest leave it as it is. -- Dmitry.

May 31, 2002

Re: Keyboard layout detection not working??

by Shachar Shemesh

Dmitry Timoshkov wrote: >"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > > > >>The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9. >> >> > >According to keysymdef.h Hebrew keysyms are in the range 0xcdf - 0xcfa >What says xev when you type hebrew characters? > > xev agrees with keysymdef.h. Strange...... I got the 0x0fxx codes by placing debug messages in the relevant places in keyboard.c. It seemed to me that keyboard.c received characters in the range 0x0fxx, but I just rechecked and it was 0x0cxx range again. Wwwwierd. I am also having trouble editing keyboard.c with snavigator. Upon saving, it totally screws up the non-ASCII characters in the keyboard layouts. It didn't used to do that (I played with the default charset, and wound up on ASCII at the end), but what do the list have to say about converting the whole string to \x notation? Your native keyboard will be less readable on your personal machine, but the file will stand a lot less chances of corruption. Besides, there is no being in the world for which keyboard.c today shows all characters correctly anyways. I am attaching a diff against the latest CVS (i.e. - overriding my previous patch) that does this, as well as a small C prog I used to generate this (it contains a very useful C state machine that understands comments and strings, and only replaces the files inside strings). Oh oh, so this is not that simple. It appears that C will not terminate the \ processing, so '\x000000020' is a perfectly legal way of specifying space. As a result, we are having problems with some of the encodings being continued to the characters after the encoding. So, if the orginal string said: "F8E", after encoding that will be "\xf8E", and the compiler will try to understand it as one character. I checked, and it is defined like that in "The C programming language". We can translate it to "\xf8""E", but the resault will be way ugly. I'm at a loss. Anyone cares to share their insight? >>The second problem I encountered was that keymaps that had three letters >>per key, but the third letter was wrong, received the same score (i.e. - >>were not counted as mismatches) as keymaps that only had two letters. In >>fact, if the X representation had only two letters, the three letter >>keymaps were not penalized for trying to match a non-existing key. I >>believe this is not the right behaviour, but as it does not block me at >>the moment, I did not try to fix it. >> >> > >Probably keyboard detection code need some additional work. But since >it works for (almost?) all, then it's fine to leave it as it is. > > > Your'e right. I lack the incentive now too. Shachar /* * This is a small C state machine skeleton that can be used as a way to know whether your'e inside a string * or a comment when analyzing source. This code will fail miserably given creative preprocessor usage. * * This source code is copyrighted by Shachar Shemesh, and can be distributed freely under the GPL version 2 * license. You may, at your descression, use any later version of the GPL as the license. A copy of the * license can be obtained at http://www.fsf.org/licenses/gpl.txt */ #include <stdio.h> int main() { int chr=0; enum state { PLAIN, SLASH, LCOMMENT, COMMENT, COM_STAR, DQUOTE, DQUOTE_BACKSLASH, QUOTE, QUOTE_BACKSLASH } state=PLAIN; while( (chr=getchar())!=EOF ) { switch( state ) { case PLAIN: switch( chr ) { case '/': state=SLASH; break; case '\'': state=QUOTE; break; case '"': state=DQUOTE; break; } break; case SLASH: switch( chr ) { case '/': state=LCOMMENT; break; case '*': state=COMMENT; break; default: state=PLAIN; break; } break; case LCOMMENT: switch( chr ) { case '\n': state=PLAIN; break; } break; case COMMENT: switch( chr ) { case '*': state=COM_STAR; break; } break; case COM_STAR: switch( chr ) { case '/': state=PLAIN; break; case '*': break; default: state=COMMENT; break; } break; case DQUOTE: switch( chr ) { case '"': state=PLAIN; break; case '\\': state=DQUOTE_BACKSLASH; break; } break; case DQUOTE_BACKSLASH: state=DQUOTE; break; case QUOTE: switch( chr ) { case '\'': state=PLAIN; break; case '\\': state=QUOTE_BACKSLASH; break; } break; case QUOTE_BACKSLASH: state=QUOTE; break; } if( chr>=0x80 && ( state==QUOTE || state==DQUOTE ) ) printf("\\x%02X", chr ); else putchar(chr); } return 0; }

May 31, 2002