Re: MSI database _Streams table
Dan Kegel wrote: In http://www.winehq.org/pipermail/wine-patches/2006-June/027528.html, Andrey Turkin wrote: Some installers depends on _Streams built-in table Which installers? It'd be nice to have a bug in bugzilla to hang your MSI work on. Thanks! - Dan For example, Microsoft's .NET Framework 1.1 installer. With my MSI fixes it almost completes install, but fails inside .NET programs (RegSvcs).
Re: ntoskrnl status
* On Tue, 20 Jun 2006, Mike McCormack wrote:
* Saulius Krasuckas wrote:
http://wiki.winehq.org/GitWine seems to be more oriented at making
patches, not importing a patch made by someone else.
$ cat origin_sd1.diff | patch -p1
$ tools/make_requests
$ git commit -a -m ntoskrnl: Experimental implementation.
If the patch is created with git format-message, you can use git am
origin_sd1.diff to add it to your tree. 'am' applies a mailbox, which is a
series of patches and their commit info.
Nice, thanks Mike.
BTW, my tutorial won't work well, because after the patch cmd no one
instructs git to add newly created files to a repository. So my answer
should be enchanced. I've just accidentally found a command to replace
patch, it's git-apply. Unfortunately it doesn't add newly created
files for me, thus I change my advise this way:
$ cat origin_sd1.diff | patch -p1 | awk '{print $3}' | xargs git-update-index
--add
$ tools/make_requests
$ git commit -a -m ntoskrnl: Experimental implementation.
Re: Win64 status
Ge van Geldorp [EMAIL PROTECTED] writes: __attribute__ seems most logical to me. Perhaps __attribute__(__msvccall__) (in the __attribute__(__stdcall__) tradition? An alternative to -msvc could perhaps be -mrtd (Alternate calling convention). For i386 builds of gcc, -mrtd makes stdcall the default calling convention. It is currently a noop for x86_64. I kind of like your -msvc though :-) For Wine the compiler option seems more important then the override. Just the other way around actually, Wine can't use a global option since we have to call Unix functions. The only way is to have an explicit attribute on Windows APIs. -- Alexandre Julliard [EMAIL PROTECTED]
ddraw assert prevents Ankh from starting
hiho on the end of this mail is a patch, that removes an assert(0) from the surface code in ddraw. but removing it let Ankh[1][2] start (it started before, but there where no loading screen visible). yet there are other problems with this game - but it now actually works better than before. so let the ddraw developers decide what to do there - this mail is just a reminder, that there is a poor little homeless assert, that needs your attention ;) [1] german demo: http://www.gamershell.com/download_12062.shtml [2] engl. demo: http://www.gamershell.com/download_12202.shtml -- cu Index: dlls/ddraw/surface.c === RCS file: /home/wine/wine/dlls/ddraw/surface.c,v retrieving revision 1.4 diff -u -r1.4 surface.c --- dlls/ddraw/surface.c19 Jun 2006 10:44:41 - 1.4 +++ dlls/ddraw/surface.c20 Jun 2006 07:10:07 - @@ -1865,7 +1865,6 @@ WINED3DFORMAT newFormat = WINED3DFMT_UNKNOWN; HRESULT hr; FIXME((%p)-(%p,%lx)\n, This, DDSD, Flags); -assert(0); if(!DDSD) return DDERR_INVALIDPARAMS; pgpJfvH6fGMTv.pgp Description: PGP signature
RE: Win64 patch 1/13
From: Mike McCormack [mailto:[EMAIL PROTECTED] Except that dlls/ntdll/tests/generated.c was hand-modified. That would explain the rather large diff that I saw when I regenerated these tests :/ Sorry, I mixed up two files :( I have no evidence that dlls/ntdll/tests/generated.c was hand-modified (dlls/oleaut32/oaidl_p.c, another file for which I sent a patch, was). After updating to current git I saw that you already changed tools/winapi/tests.dat, but it seems the tests were not regenerated (so the dlls/*/tests/generated.c files are out of sync). Should I send a patch with the regenerated files or is it easier if Alexandre just runs tools/winapi/winapi_test? Gé van Geldorp.
Re: ddraw assert prevents Ankh from starting
Hi, on the end of this mail is a patch, that removes an assert(0) from the surface code in ddraw. but removing it let Ankh[1][2] start (it started before, but there where no loading screen visible). yet there are other problems with this game - but it now actually works better than before. so let the ddraw developers decide what to do there - this mail is just a reminder, that there is a poor little homeless assert, that needs your attention ;) Ooops. Well, that assert is a sort of debugging assertion to be sure to catch apps which call this function. It wasn't meant to go into the winehq tree, I missed it when doing my cleanup checks :-( Anyway, that call is pretty much untested, I don't expect it to work as-is(especially if the app sets a surface memory pointer). You can send the patch to remove that assert to wine-patches, it's clearly wrong. I'm just downloading the demo to test it myself, but I'm quite busy at university right now :-( pgpElb9mYqlnI.pgp Description: PGP signature
Re: msi: Fix handling of the no-op identifier in the Directory table [resend]
James Hawkins [EMAIL PROTECTED] writes: Is there anything wrong with this patch? Changelog: * Fix handling of the no-op identifier in the Directory table. You are assigning a const string to a non-const variable, that causes warnings. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [WINED3D 3/3] Fix fog in the case of vertex shaders
On 6/19/06, Jason Green [EMAIL PROTECTED] wrote: - Fixes both ARB and GLSL shaders that use fog.Is it really necessary to keep track of whether the shader uses fog or not?What happens if you disable this post-processing for a shader that doesn't write to the fog register? Also, how come the ARB version forces the fog value to be 0, but the GLSL one has both lower and upper limit (clamp to 0,1) ? Shouldn't you use saturate (_SAT) to achieve the same effect?
LoadResource with module=0x00400000 followed by stack overflow
I get this stack overflow exception while trying to run the Watchtower Library Setup on FreeBSD 6.1. I have extracted some debug lines which I think is relevant. Please ask if you need more information. 0009:Call ntdll.LdrFindResource_U(0040,0034ecf0,0003,0034ec8c) ret=9c266b12 0009:trace:resource:LdrFindResource_U module 0x40 type #0006 name #0901 lang 0414 level 3 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b000 id 0006 ret 0x40b090 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40b090 id 0901 ret 0x40bb98 0009:trace:resource:find_entry_by_id root 0x40b000 dir 0x40bb98 id 0414 ret 0x40d1c8 0009:Ret ntdll.LdrFindResource_U() retval= ret=9c266b12 0009:Ret kernel32.FindResourceExA() retval=0040d1c8 ret=00405ac0 0009:Call kernel32.LoadResource(0040,0040d1c8) ret=00405ae4 0009:trace:resource:LoadResource 0x40 0x40d1c8 0009:Call ntdll.LdrAccessResource(0040,0040d1c8,0034ed48,) ret=9c26807b 0009:trace:resource:access_resource access resource 0009:trace:resource:access_resource *ptr=0x4219d0 0009:Ret ntdll.LdrAccessResource() retval= ret=9c26807b 0009:Ret kernel32.LoadResource() retval=004219d0 ret=00405ae4 0009:Call ntdll.NtCreateEvent(0034e634,001f0003,0034e8dc,0001,) ret=9c22d14a 0009:Ret ntdll.NtCreateEvent() retval= ret=9c22d14a wine: Unhandled stack overflow at address 0x405b1d (thread 0009), starting debugger... (There was thread two (to 000b and back to 0009) context switches in between, which I filtered out) I single stepped the last instructions before the crash and found that it crashed while trying to write to the memory pointed to by the returned pointer from LoadResource. It loaded the address with some offset into register %esi and crashed at an andw instruction: First chance exception: stack overflow in 32-bit code (0x00405b1d). file_set_error: Bad address file_set_error: Bad address Register dump: CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b EIP:00405b1d ESP:0035ee08 EBP:0035f224 EFLAGS:00010346( - 00 RITZP1) EAX:006c EBX: ECX:0003 EDX: ESI:00421b5e EDI:00421a86 Stack dump: 0x0035ee08: 9c266cc0 0035f954 0035f230 0x0035ee18: 00401df3 9003 0035f224 0035f958 0x0035ee28: 0035f954 9c086a19 9c0da2c0 0x0035ee38: 0035ee78 9c092b72 00120020 0001 0x0035ee48: 9c086957 0035ee34 0x0035ee58: 005ca2c0 9c08b791 00167e10 0200: sel=1007 base=0011 limit=1fff 32-bit rw- Backtrace: =1 0x00405b1d in setup (+0x5b1d) (0x00405b1d) 0x00405b1d: andw$0,0x0(%esi) Wine-dbginfo share Module Address Debug info Name (3 modules) PE 0x9c07-9c0dd000 --none--ntdll PE 0x9c21-9c2f1000 --none--kernel32 PE 0x0040-0042b000 Export setup Can a win32 program expect that it has write access to the memory pointed to by the return value of LoadResource with module 0x0040? Should LoadResource in some cases copy the memory and return a writeable copy of the resource? Jan-Espen Pettersen signature.asc Description: OpenPGP digital signature
Re: Winelib Getting Started 1.3.2. Test Drive
Robert Muller wrote: Dee Ayy wrote: | As a newbie, the statement It can be found in the programs subdirectory. | had me lost. [...] At this point, the sentance that gave you problems could be modified to say: It can be found in the programs subdirectory of the wine source. There is one other part that is out-of-date: the procedure described won't create the 'notepad2' script. It would be better to change that part of section 1.3.2 to suggest you run 'wine notepad2.exe.so' or to run 'ln -s ../../tools/winewrapper notepad2' to create the script. Aside from that, the instructions look good to me. Eric
Re: Winelib Getting Started 1.3.2. Test Drive
Eric Frias [EMAIL PROTECTED] writes: There is one other part that is out-of-date: the procedure described won't create the 'notepad2' script. It would be better to change that part of section 1.3.2 to suggest you run 'wine notepad2.exe.so' or to run 'ln -s ../../tools/winewrapper notepad2' to create the script. Aside from that, the instructions look good to me. winegcc should create the script. If it doesn't it's probably because winemaker is not invoking it correctly. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [WINED3D 3/3] Fix fog in the case of vertex shaders
On 20/06/06, Ivan Gyurdiev [EMAIL PROTECTED] wrote: Is it really necessary to keep track of whether the shader uses fog or not? What happens if you disable this post-processing for a shader that doesn't write to the fog register? Not really necessary, but it does save a couple of GL state changes if fog isn't used in the shader, and it's pretty easy to keep track of.
Re: msi: Fix handling of the no-op identifier in the Directory table [resend]
* On Tue, 20 Jun 2006, Alexandre Julliard wrote: * James Hawkins [EMAIL PROTECTED] writes: Is there anything wrong with this patch? You are assigning a const string to a non-const variable, that causes warnings. Alexandre, maybe we should know what CGLAGS are you using so we can use them too and detect such compiler warnings in future? Would you reveal them, please? :)
Re: msi: Fix handling of the no-op identifier in the Directory table [resend]
Saulius Krasuckas [EMAIL PROTECTED] writes: Alexandre, maybe we should know what CGLAGS are you using so we can use them too and detect such compiler warnings in future? Would you reveal them, please? :) I don't use special flags, just a standard configure. You may need a more recent gcc to see all the warnings. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Winelib Getting Started 1.3.2. Test Drive
Alexandre Julliard wrote:
Eric Frias [EMAIL PROTECTED] writes:
here is one other part that is out-of-date: the procedure described
won't create the 'notepad2' script.
winegcc should create the script. If it doesn't it's probably because
winemaker is not invoking it correctly.
That was the problem. Winemaker was invoking 'winegcc -o foo.exe.so',
which suppresses the wrapper script. If it's invoked as 'winegcc -o
foo.exe' it generates the wrapper script as desired. Something like the
attached patch should fix the problem.
Eric
--- wine-0.9.15/tools/winemaker 2006-06-08 15:06:43.0 +
+++ ../wine-0.9.15/tools/winemaker 2006-06-20 14:17:36.0 +
@@ -1749,7 +1749,11 @@
} else {
print FILEO \t\$(CC);
}
- print FILEO \$(${canon}_LDFLAGS) -o \$\@ \$(${canon}_OBJS)
\$(${canon}_LIBRARY_PATH) \$(DEFLIB) \$(${canon}_DLLS:%=-l%)
\$(${canon}_LIBRARIES:%=-l%)\n;
+
+ # for .EXEs, tell winegcc to generate 'foo.exe', which will cause it
+ # to generate both 'foo.exe.so' and the 'foo' wrapper script.
+ my $output_file = @$target[$T_TYPE] == $TT_DLL ? \$\@ :
\$(${canon}_MODULE);
+ print FILEO \$(${canon}_LDFLAGS) -o $output_file \$(${canon}_OBJS)
\$(${canon}_LIBRARY_PATH) \$(DEFLIB) \$(${canon}_DLLS:%=-l%)
\$(${canon}_LIBRARIES:%=-l%)\n;
print FILEO \n\n;
}
}
Re: lz32: remove dead code from the LZOpenFileW test.
Saulius Krasuckas wrote: + ok(file = 0, LZOpenFileW failed on switching to a compressed file name\n); .. + ok(test.nErrCode == 0, LZOpenFileW set test.nErrCode to %d\n, + test.nErrCode); Did you mean test.nErrCode == ERROR_SUCCESS? You test the Errorcode here, but you did not use SetLastError() before LZOpenFileW. + ok(lstrcmpA(test.szPathName, expected) == 0, + LZOpenFileW returned '%s', but was expected to return '%s'\n, + test.szPathName, expected); This is strange: An ANSI-Compare for an UNICODE-Function. After reading the source and OFSTRUCT, this is correct. I suggest a command before the above ok(). An extra Patch with the WINAPI-Documentation for the Implementation would be nice. This should include a note, that the ANSI-String szPathName in OFSTRUCT is the correct Parameter for the UNICODE-Implementation. cut This part from your previous Patch is already in the tree, but: + /* Delete the file then make sure it doesn't exist anymore. */ + file = LZOpenFileW(filename_W, test, OF_DELETE); + ok(file = 0, LZOpenFileA failed on delete\n); + retval = GetFileAttributesW(filename_W); + ok(retval == INVALID_FILE_ATTRIBUTES, + GetFileAttributesA succeeded on deleted file\n); The Messages in the W-Tests have ANSI Function-Names -- By By ... ... Detlef
ntoskrnl followup
Hi Vitaliy, If I read the thread concerning ntoskrnl insertion into Wine correctly, the patch will have to be divided into several parts to be accepted by AJ. For this, tests need probably be written to make sure each sub-patch is performing as it should. I haven't written C-code for a while, but there are a lot of tests available for me to have a crack at it. As I see it, the following tests/patches are needed (in this order?) 1) Tests for talking to ntoskrnl through wineserver (setting up channel, testing messages both correct and incorrect and closing channel again) in order to test the new way of communication. 2) Tests to try the ioctl structures 3) loading a device driver, talking to it, unloading it (including negatives like unloading a non-loaded driver etc). 4) Open issues like detecting if the driver is actually loaded instead of waiting X ms The questions I have are: a) Is the breakdown correct, or are there more atomic parts (easier to test/get into wine). Do you already have a breakdown idea of the patch into smaller parts so I/we can focus on this? b) Did I miss tests or do you have ideas for more? c) Is the order of the patches correct? If not, please correct me so I can start creating tests. d) Can I somehow access the most recent version of the patch? I have several versions now, but they keep on changing/improving(!). It would be nice if you could publish it somewhere (nightly CVS tarball?), so more people can provide feedback on it too. As you can see, I'm just trying to see if I can contribute on such a big project. Thanks for the feedback, Frans.
Re: lz32: remove dead code from the LZOpenFileW test.
* On Tue, 20 Jun 2006, Detlef Riekenberg wrote: * Saulius Krasuckas wrote: + ok(file = 0, LZOpenFileW failed on switching to a compressed file name\n); .. + ok(test.nErrCode == 0, LZOpenFileW set test.nErrCode to %d\n, + test.nErrCode); Did you mean test.nErrCode == ERROR_SUCCESS? Yes, should I use the constant name in a case of success? You test the Errorcode here, but you did not use SetLastError() before LZOpenFileW. Well, I didn't because I don't test using GetLastError(). But you are right, I was too fast (falling asleep) and removed this needed line tonight: - memset(test, 0xA5, sizeof(test)); Will put that back. An extra Patch with the WINAPI-Documentation for the Implementation would be nice. It was planned to be added as soon as I get on the stuff that LZOpenFile* does :) This should include a note, that the ANSI-String szPathName in OFSTRUCT is the correct Parameter for the UNICODE-Implementation. Uhu, quite confusing, isn't it? I was trying to eliminate LZOpenFileW - LZOpenFileA crosscall and this confusion was a reason to write tests. The Messages in the W-Tests have ANSI Function-Names Aha, copypaste quirks. Thanks, Detlef.
Re: [Bug 5463] ie6 installs now, but doesn't work...
On Mon, 19 Jun 2006, Wine Bugs wrote: [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2006-19-06 14:11 --- Again this is not a bug. There is nothing to fix because there is nothing that broke. I disagree. If IE doesn't run, it's a bug. I would actually say that it's a major bug - IE is one the those core applications that users expects to work. You are incorrect about there is nothing to fix: Perhaps the source code is fine, but the documentation is certainly not. http://appdb.winehq.org/appview.php?versionId=469 even says: (to be continued because then it still doesn\'t run because of ole errors) Anyone is welcome to write up instructions on what to override and place them in appDB. Bugzilla is not the right place for that. Why do you think Bugzilla cannot be used for tracking documentation bugs? There is a wine-documentation component and a WineHQ Apps Database component, if you think that wine-misc is totally wrong. I would very much prefer is this bug could be left open until someone has managed to figure out what needs to be overridden to actually *run* IE. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
riched slowdown
Hi, I just did a +relay log of the ie6setup.exe installation. I had to ctrl-c after the log grew to 3.5gb and the initial screen hadn't been displayed yet. tail -n 1000 relay.log showed call after call to WideCharToMultibyte before I finally killed the install. Here is a sample of one of the calls: WideCharToMultiByte(04e4,,40895ae4 LS\5524,0001,40895ae7,0001,,40895ae8) So the length of the string we're converting is 1. Not exactly efficient. grep'ing the log for WideCharToMultiByte reveals 39426680 calls, and it wasn't even done loading the EULA. I'm pretty sure this is a recent bug in riched, as overriding riched20 and riched32 gets rid of the problem. -- James Hawkins
Re: [Bug 5463] ie6 installs now, but doesn't work...
Try adding wine overrides for iexplore Just my 2 cents, Vijay On 6/20/06, Peter Åstrand [EMAIL PROTECTED] wrote: On Mon, 19 Jun 2006, Wine Bugs wrote: [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2006-19-06 14:11 --- Again this is not a bug. There is nothing to fix because there is nothing that broke. I disagree. If IE doesn't run, it's a bug. I would actually say that it's a major bug - IE is one the those core applications that users expects to work. You are incorrect about there is nothing to fix: Perhaps the source code is fine, but the documentation is certainly not. http://appdb.winehq.org/appview.php?versionId=469 even says: (to be continued because then it still doesn\'t run because of ole errors) Anyone is welcome to write up instructions on what to override and place them in appDB. Bugzilla is not the right place for that. Why do you think Bugzilla cannot be used for tracking documentation bugs? There is a wine-documentation component and a WineHQ Apps Database component, if you think that wine-misc is totally wrong. I would very much prefer is this bug could be left open until someone has managed to figure out what needs to be overridden to actually *run* IE. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 LinköpingPhone: +46-13-21 46 00
solution: IE6 setup says The download location information is damaged
Hey, If you're still having this problem, please make sure you are not on a remote or network-mounted drive. IE6 setup checks if the drive is remote, and will not install if it is, complaining with the completely non-related error that The download location information is damaged. If you're not sure whether you're on a remote drive or not, and the IE6 setup is still not working, please post back and attach a +volume trace. I was frustrated that the setup was not working on my work machine, while it was on my home machine. Reading through a +all log showed that GetDriveTypeW was returning 4 for my work machine, which is DRIVE_REMOTE, and then it would fail with the message box. Hacking GetDriveTypeW to always return DRIVE_FIXED let me install onto my remote drive. Thanks, James Hawkins
Re: [AppDB] - make variables more consistent, fix indenting
Chris Morgan wrote: Make the code more consistent by using the appdb coding standards. Change $result = query_appdb(...) to $hResult = ... etc. Also fix some odd indenting due to spaces vs. tabs. There are still a ton of variables that are integers or strings that should be prefixed with 'i' or 's' if anyone is interested in cleaning some of that up. Chris I am not opposed to doing this but I think that the patch is way too big. At the momment we still have issues with the last big patch that are not cleared up [1]. On the whole unless we cannot avoid it I really do not think that we should be making such large changes in one go like this. Please break up the patch into smaller patches. That way it is easier to find and fix any issues that arise. [1] New versions end up as orphans with current setup. -- Tony Lambregts
Re: [AppDB] - make variables more consistent, fix indenting
Would per-directory patches be easier to read? Like one for /include, one for /admin, one for / ? This patch is a precursor to a patch that will close up a bunch of security holes that could result in the db being destroyed, then on to finding a more appropriate solution to the makeSafe() patch. Chris On Tuesday 20 June 2006 4:12 pm, Tony Lambregts wrote: Chris Morgan wrote: Make the code more consistent by using the appdb coding standards. Change $result = query_appdb(...) to $hResult = ... etc. Also fix some odd indenting due to spaces vs. tabs. There are still a ton of variables that are integers or strings that should be prefixed with 'i' or 's' if anyone is interested in cleaning some of that up. Chris I am not opposed to doing this but I think that the patch is way too big. At the momment we still have issues with the last big patch that are not cleared up [1]. On the whole unless we cannot avoid it I really do not think that we should be making such large changes in one go like this. Please break up the patch into smaller patches. That way it is easier to find and fix any issues that arise. [1] New versions end up as orphans with current setup. -- Tony Lambregts
Re: ntoskrnl status
Thanks for the tutorial Saulius. (I'm new to git) It's all compiled now.
Just to summarize: (with your enhancements)
# (after completing: http://wiki.winehq.org/GitWine )
# rename/extract patch:
$ cd wine-git
$ mv origin_sd1.diff-0001.obj origin_sd1.diff.bz2
$ bunzip2 --keep origin_sd1.diff.bz2
# patch wine:
$ git branch ntoskrnl 1d40bf0141b7f67b1188555962698f5dab631bc3
$ git branch
$ git checkout ntoskrnl
$ git branch
$ cat origin_sd1.diff | patch -p1 | awk '{print $3}' | xargs
git-update-index --add
$ tools/make_requests
$ git commit -a -m ntoskrnl: Experimental implementation.
# recompile Wine:
$ ./configure make depend make tools/wineprefixcreate --use-wine-tree .
# below goes your experiments
$ ...
# and here we go back to the normal tree
$ git checkout master
# recompile Wine
$ ./configure make depend make tools/wineprefixcreate --use-wine-tree .
# and do our stuff
$ ...
I noticed that the typical make install is missing.
I ran ./wine-git/programs/winecfg/winecfg and it seems to work ok.
Found some more info about this in an old Wine newsletter:
http://www.winehq.com/?issue=269#Speeding%20Up%20Builds
Wine developers?
Hello All, My name is Jonathan Clark, and I work with a team on a project that has some similarities with Wine. The project is called Thinstall (http://thinstall.com), and on first glance similarities may not be apparent. Thinstall allows Win32 applications to run (on Windows) from a network share or usb flash drive with zero install. It isn't meant to allow applications to run cross platform like wine, but it is similar in that it replaces the Windows loader for loading EXEs DLLs, doing things like mapping, imports, and thread/process management. It also replaces ~400 Win32 api functions in order to allow applications to run instantly in a sandbox so they don't need to touch the local filesystem or registry. Our approach is all in user mode so that applications can run under any login account without needing admin rights or drivers. Thinstall packages the entire application into a single EXE file and then tacks on it's runtime (300k on disk) so apps can be distributed and run as a single file that doesn't need to decompress to disk. The challenges in creating Thinstall are many of the same ones that Wine faces, achieving a high degree of compatibility in replacement functions means you need to be good at debugging and understanding the internals of Windows. Since most code can be run by multiple threads, it is also important to understand thread safety and have a lot of experience working through these types of issues. Thinstall is now about 6 years old and we are coming up on a version 3.0 release. Thinstall is a commercial product and everyone works full time with funding coming from our customers. Recently we've done fairly well financially and have the opportunity to try to take the product and company to the next level by hiring a couple of senior engineers. This brings me to why I'm posting here.. If you are experienced with Windows internals, have experience reimplementing Win32 APIs, and you are interested in some contract or full-time work please let me know. We are located in San Francisco, California (awesome town) and ideally I'd like to work with people locally. We can help with a move if needed. Otherwise, if you are outside of the USA - we could talk about doing something remotely. I hope to hear from you. Best Regards, Jonathan Clark P.S. As background info, I used to be heavily in the linux space when I co-founded a video game company Crack dot com which made the linux port of Doom Quake as well as developed the original titles Abuse and Golgotha. I have been aware of wine for a long long time and I'm impressed by the quality of work by all the developers and how far it has come. P.S.S. I subscribed in digest mode so if you reply to the list, keep in mind I won't see it until tomorrow.
Re: ntoskrnl status
On 6/20/06, Jaap Stolk [EMAIL PROTECTED] wrote: snip I noticed that the typical make install is missing. I ran ./wine-git/programs/winecfg/winecfg and it seems to work ok. Found some more info about this in an old Wine newsletter: http://www.winehq.com/?issue=269#Speeding%20Up%20Builds And a script to setup the correct wine variables without installing wine. http://wiki.jswindle.com/index.php/General_Developer_Information#Running_Wine_from_its_source_tree
Re: [AppDB] - make variables more consistent, fix indenting
Chris Morgan wrote: On Tuesday 20 June 2006 4:12 pm, Tony Lambregts wrote: Chris Morgan wrote: Make the code more consistent by using the appdb coding standards. Change $result = query_appdb(...) to $hResult = ... etc. Also fix some odd indenting due to spaces vs. tabs. There are still a ton of variables that are integers or strings that should be prefixed with 'i' or 's' if anyone is interested in cleaning some of that up. Chris I am not opposed to doing this but I think that the patch is way too big. At the momment we still have issues with the last big patch that are not cleared up [1]. On the whole unless we cannot avoid it I really do not think that we should be making such large changes in one go like this. Please break up the patch into smaller patches. That way it is easier to find and fix any issues that arise. [1] New versions end up as orphans with current setup. -- Tony Lambregts Would per-directory patches be easier to read? Like one for /include, one for /admin, one for / ? This patch is a precursor to a patch that will close up a bunch of security holes that could result in the db being destroyed, then on to finding a more appropriate solution to the makeSafe() patch. Chris No That is not what I would prefer I would prefer a single patch for each file that is changed (ie one for addcomment.php and one for include/vendor.php. If the changes to one file need changes in other in order for the appdb to continue to function then they should be together in one patch. Now you may think that is overboard but I have seen these big patches break the AppDB too many times. As far as security holes that could result in the db being destroyed we do have backup. I dont want you to think I do not care about security. That is simply not true. I am however very much against breaking the AppDB for regular use. The fact is that so far we have lost more data through bad patches then through security holes. We have preaty good security in place already, We check that id's are numeric and escape date before running it. Right now if you ask me we would be better off making a audit of our querys than what you are advocating. -- Tony Lambregts.
[ntdll patch] Patch dropped?
I saw a patch I posted yesterday (ntdll: server.c, write-strings fix) appear on the wine-cvs page for a while :), and now it has disappeared :(. Did it fall, or was it pushed? ;) -- Andy.
Wine talk in LA june 20th,22nd. Slide check, anyone?
I'm giving a short talk on Wine at lula.org tonight and again at aitp-la.org Thursday night. The audience at aitp-la is IT professionals who don't really know much about Wine or Linux, so I'm trying for a gentle, practical talk. I'll demo a few apps (Office '97, Picasa, Firefox, Kid Pix, and Visual C++) and I'll even run an app that doesn't work too well yet (Visual Basic 6's IDE). The slides, such as they are, are up at kegel.com/wine/wine-2006-june-talk.ppt kegel.com/wine/wine-2006-june-talk.pdf (I usually use magicpoint, but for this talk, I used Office 97's powerpoint on the theory that one should eat one's own dogfood...) Corrections/improvements welcome. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: [AppDB] - make variables more consistent, fix indenting
On Tuesday 20 June 2006 5:03 pm, Tony Lambregts wrote: Chris Morgan wrote: On Tuesday 20 June 2006 4:12 pm, Tony Lambregts wrote: Chris Morgan wrote: Make the code more consistent by using the appdb coding standards. Change $result = query_appdb(...) to $hResult = ... etc. Also fix some odd indenting due to spaces vs. tabs. There are still a ton of variables that are integers or strings that should be prefixed with 'i' or 's' if anyone is interested in cleaning some of that up. Chris I am not opposed to doing this but I think that the patch is way too big. At the momment we still have issues with the last big patch that are not cleared up [1]. On the whole unless we cannot avoid it I really do not think that we should be making such large changes in one go like this. Please break up the patch into smaller patches. That way it is easier to find and fix any issues that arise. [1] New versions end up as orphans with current setup. -- Tony Lambregts Would per-directory patches be easier to read? Like one for /include, one for /admin, one for / ? This patch is a precursor to a patch that will close up a bunch of security holes that could result in the db being destroyed, then on to finding a more appropriate solution to the makeSafe() patch. Chris No That is not what I would prefer I would prefer a single patch for each file that is changed (ie one for addcomment.php and one for include/vendor.php. If the changes to one file need changes in other in order for the appdb to continue to function then they should be together in one patch. There is no way I'm going to send a patch in per-file. Its a huge pain in the ass and doesn't change how the monolithic patch is reviewed since you'll end up reviewing the same code anyway. Breaking the patch up given that its a atomic noop change is also not necessary. Now you may think that is overboard but I have seen these big patches break the AppDB too many times. As far as security holes that could result in the db being destroyed we do have backup. I dont want you to think I do not care about security. That is simply not true. I am however very much against breaking the AppDB for regular use. The fact is that so far we have lost more data through bad patches then through security holes. I agree. I'll fix the existing issues before applying any more patches like this one. We have preaty good security in place already, We check that id's are numeric and escape date before running it. Right now if you ask me we would be better off making a audit of our querys than what you are advocating. Our security is awful. You should really re-read the email sent to the appdb list by Mortiz Naumann and see how bad it is. Chris
Re: wined3d: Bind correct # of samplers for GLSL shaders
On 6/20/06, Jason Green [EMAIL PROTECTED] wrote: - We are only checking against GL_MAX_TEXTURES when binding samplers,when we should be checking against the maximum number of samplers thatthe card supports.Spotted by H. Verbeet.Yes, I'm aware of that...it was done on purpose. This limit is in a lot of other places - stateblock code, drawprim code.Have you checked that it will all interact properly using this higher limit?Specifically, have you tested a sampler 4 with SetTexture()? I think this problem should be solved by a single patch that updates all the necessary places to use the higher texture units value, as opposed to the legacy one (there's some caps code to write for this).
Re: [Bug 5463] ie6 installs now, but doesn't work...
Tuesday, June 20, 2006, 11:27:04 AM, Peter Åstrand wrote: On Mon, 19 Jun 2006, Wine Bugs wrote: [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2006-19-06 14:11 --- Again this is not a bug. There is nothing to fix because there is nothing that broke. I disagree. If IE doesn't run, it's a bug. I would actually say that it's a major bug - IE is one the those core applications that users expects to work. What would you say if I open a bug about Windows doesn't work on Wine? Or better yet, Can not upgrade Wine to winxp. You are incorrect about there is nothing to fix: Perhaps the source code is fine, but the documentation is certainly not. http://appdb.winehq.org/appview.php?versionId=469 even says: (to be continued because then it still doesn\'t run because of ole errors) This is _not_ a documentation. If you are not happy with something on appDB ask app maintainers to change that. Of course suggestions are welcome to what do you want to see there. Anyone is welcome to write up instructions on what to override and place them in appDB. Bugzilla is not the right place for that. Why do you think Bugzilla cannot be used for tracking documentation bugs? There is a wine-documentation component and a WineHQ Apps Database component, if you think that wine-misc is totally wrong. Because that's exactly what appDB is for. I would very much prefer is this bug could be left open until someone has managed to figure out what needs to be overridden to actually *run* IE. I explained in the bug and will repeat here. Wine does not run windows. Wine runs windows applications. That's the main goal. The ultimate goal is to run every windows application without using any native component. That way Wine will be 100% replacement to windows. If you install any part of windows (per m$) you have to have windows licence. I'm not saying that some one can not find a way to run ie on Wine. In fact I spent quite some time putting that magic list of overrides together. Now it's been removed because Wine has it's own replacement for ie whenever app needs that. Vitaliy.
Re: Wine developers?
Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: Hello All, My name is Jonathan Clark, and I work with a team on a project that has I think it's a really really really rude to write to an open source project and offer such a work. Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. Unless of course you want to open source your project and release it under at least GPL licence. Vitaliy.
Re: Wine developers?
It's up to individual developers to decide whether or not to work on a project that precludes them from contributing to particular OSS projects. It might be slightly off topic but there haven't been a lot of job offer emails to wine-devel lately or ever. Chris On Tuesday 20 June 2006 9:32 pm, Vitaliy Margolen wrote: Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: Hello All, My name is Jonathan Clark, and I work with a team on a project that has I think it's a really really really rude to write to an open source project and offer such a work. Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. Unless of course you want to open source your project and release it under at least GPL licence. Vitaliy.
Re: Wine developers?
Lots of open source developers probably still have day jobs. Maybe they're looking for a new one. Vitaliy Margolen wrote: Tuesday, June 20, 2006, 2:59:59 PM, Jonathan Clark wrote: Hello All, My name is Jonathan Clark, and I work with a team on a project that has I think it's a really really really rude to write to an open source project and offer such a work. Basically you are _stealing_ developers from the project. Because with your closed source project such developer will be prohibited from participating in the Wine project. Unless of course you want to open source your project and release it under at least GPL licence. Vitaliy.
Re: [WiKI] Common site menu 4/4
On Thu, 2006-06-15 at 16:49 -0600, Tony Lambregts wrote: Is there anything wrong with this patch? No, I've just been away on vacation, I'll look at it soon. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
wined3d:add an \n to a fixme to fix an overflow
Hi, i get this crash in an application (ftp://ftp.avault.com/demos/puzzleblastsetup.exe) :wine_dbg_vprintf: debugstr buffer overflow (contents: 'fixme:d3d_surface:IWineGDISurfaceImpl_Blt Unsupported flags: 0010 Unsupported flags: 0010 Unsupported flags: 0010 Unsupported flags: 0010 etceteraThis simple patch fixes it.Changelog:add an "\n" to a fixme to fix an overflow
All New Yahoo! Mail Tired of [EMAIL PROTECTED]@! come-ons? Let our SpamGuard protect you.diff --git a/dlls/wined3d/surface_gdi.c b/dlls/wined3d/surface_gdi.c
index ce39090..35c5eed 100644
--- a/dlls/wined3d/surface_gdi.c
+++ b/dlls/wined3d/surface_gdi.c
@@ -1042,7 +1042,7 @@ #undef COPY_COLORKEY_FX
error:
if (Flags FIXME_ON(d3d_surface))
{
-FIXME(\tUnsupported flags: %08lx, Flags);
+FIXME(\tUnsupported flags: %08lx\n, Flags);
}
release:
Re: Wine developers?
Jonathan Clark wrote: replaces the Windows loader for loading EXEs DLLs, doing things like mapping, imports, and thread/process management. It also replaces ~400 Win32 api functions We're currently borrowing code from the Wine project... with funding coming from our customers. Recently we've done fairly well financially and have the opportunity to try to take the product and company to the next level by hiring a couple of senior engineers. This brings me to why I'm posting here.. ...which we're having good commercial success with, so now we'd like to knick a couple of developers from the project, too! Sign-up forms here. Or did I completely misread your posting? :-D
