Re: Very large files
--- John Willis [EMAIL PROTECTED] wrote: Howdy, I have a large VS 6.0 C++ program and I'm running it under WINE under Redhat Linux. Everything works fine, but it doesn't handle file sizes greater than 4gb like it can running directly under Windows XP. I've tweaked everything that I can find that seems to deal with file sizes. How do you access the file? With stdio streams (fopen(), fread(), ...), MSVCRT's open()/read(), or with KERNEL32's CreateFile(), ReadFile(), ... ? Is there a problem with WINE itself handling very large file sizes? Which version of the Linux kernel and which filesystem are you using? I'll run some tests at home and see whether it works for me. Thanks in advance, John __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: winspool.drv: Write-strings warnings fix
Mike McCormack wrote: These strings should really be const. IMO, a better fix would be to add a cast to cast them back to (char*) than to change their storage class. The trouble is, if you leave them as they were, you get a write-strings warning, since you are pointing a writeable pointer at a read-only string). But if you cast, thus: CHAR *dtype = (LPSTR) RAW; ... then you swap the write-strings warning for a cast-qual one. In general, it's a solution that Alexandre has accepted. -- Andy.
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
I think you missed my point. I know people are working on it. The problem is a few people, including Codeweavers, are working on it, which is just about the sum-total of the information out there, is not enough. There is very little information out there for potential developers to know what's going on with wine and intel macos x. For instance, a status page describing to-do items would be a start (I'm going to add it to the wine wiki when I figure out what the status is). It should be mentioned on winehq, so macos x developers know to investigate further when they check wine out. Expecting people to dig through the code or the mailing list is unreasonable. Is this really only obvious to me? I don't mean to be rude; I just see some easy ways to attract mac people to wine. Wine is likely to be an important addition to mac users' software base in the future. So many people want the mac experience, but have to run windows software. Many more people, I'd say, than those who wanted the mac experience and the unix software suite, and look at how popular fink is. It's a disservice to both parties to not properly advertise. On 6/25/06, Dan Kegel [EMAIL PROTECTED] wrote: William Knop writes: What's the story with wine on intel os x? A few people, including Codeweavers, are working on it. More would be welcome. There is no politics keeping people away, as far as I know. If you run into any developer who says that politics is keeping him or her from submitting patches to wine-patches, please let me know. - Dan
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/26/06, William Knop [EMAIL PROTECTED] wrote: I think you missed my point. I know people are working on it. The problem is a few people, including Codeweavers, are working on it, which is just about the sum-total of the information out there, is not enough. There is very little information out there for potential developers to know what's going on with wine and intel macos x. For instance, a status page describing to-do items would be a start (I'm going to add it to the wine wiki when I figure out what the status is). It should be mentioned on winehq, so macos x developers know to investigate further when they check wine out. Expecting people to dig through the code or the mailing list is unreasonable. Is this really only obvious to me? You could just ask, Hey, what's the status of Wine on Intel Max OS X?. No one has really stepped up to work on that aspect of Wine, outside of Codeweavers, so there's not a whole lot of incentive to put this information up. So if you're wanting to work on this, step up to the plate, and I'm sure we'll be more than willing to help. -- James Hawkins
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/26/06, James Hawkins [EMAIL PROTECTED] wrote: You could just ask, Hey, what's the status of Wine on Intel Max OS X?. No one has really stepped up to work on that aspect of Wine, outside of Codeweavers, so there's not a whole lot of incentive to put this information up. So if you're wanting to work on this, step up to the plate, and I'm sure we'll be more than willing to help. You pretty much directly quoted the first line of his first email. He's also offered to add the status to the wiki once it becomes public knowledge (e.g. when someone from within codeweavers sends an email to the list with a little information). --tim
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/26/06, Tim Schmidt [EMAIL PROTECTED] wrote: On 6/26/06, James Hawkins [EMAIL PROTECTED] wrote: You could just ask, Hey, what's the status of Wine on Intel Max OS X?. No one has really stepped up to work on that aspect of Wine, outside of Codeweavers, so there's not a whole lot of incentive to put this information up. So if you're wanting to work on this, step up to the plate, and I'm sure we'll be more than willing to help. You pretty much directly quoted the first line of his first email. He's also offered to add the status to the wiki once it becomes public knowledge (e.g. when someone from within codeweavers sends an email to the list with a little information). Well, I was trying to be nice by not saying that his attitude in his emails tends to put devels off, and emails like that usually get ignored. That's why I said *just*, meaning, only ask that question. -- James Hawkins
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
Er... I did ask that, and I have stepped up to the plate. :) Well, I said I'd update the wine wiki with the status, anyway. I also think it'd be a good idea to add to the winehq main page, but I wasn't sure who to talk to: Wine provides both a development toolkit for porting Windows source code to Unix as well as a program loader, allowing many unmodified Windows programs to run on x86-based Unixes, including Linux, FreeBSD, Darwin (MacOS X), and Solaris. Will On 6/26/06, James Hawkins [EMAIL PROTECTED] wrote: You could just ask, Hey, what's the status of Wine on Intel Max OS X?. No one has really stepped up to work on that aspect of Wine, outside of Codeweavers, so there's not a whole lot of incentive to put this information up. So if you're wanting to work on this, step up to the plate, and I'm sure we'll be more than willing to help. -- James Hawkins
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/26/06, William Knop [EMAIL PROTECTED] wrote: Er... I did ask that, and I have stepped up to the plate. :) Well, I said I'd update the wine wiki with the status, anyway. I also think it'd be a good idea to add to the winehq main page, but I wasn't sure who to talk to: Good to hear, we can always use more active help. If you want to change the winehq main page, just make a patch and send it to [EMAIL PROTECTED] I think the best that you can do about a status update is wait to see if anyone responds to this thread. Unfortunately, most of the work that is needed to get Wine running on Intel Macs can only be done by Alexandre Julliard, unless I'm mistaken. You can send him a line at [EMAIL PROTECTED], or see if he replies to this thread. -- James Hawkins
Re: riched20: (updated) EM_GETLINE implementation and test
Krzysztof Foltman [EMAIL PROTECTED] writes: This is the EM_GETLINE patch from Thomas Kho, updated to current git and with L replaced by proper WCHAR array. There are many more problems with that patch. For instance, it shouldn't call IsWindowUnicode all the time, once is enough. Also casting pointers to int is a bad idea (and not needed), it should use sizeof(WCHAR) instead of hardcoding 2, and preferably use proper data types instead of the nBPC hack. -- Alexandre Julliard [EMAIL PROTECTED]
Re: mshtml 8: Added beginning IDM_BROWSEMODE implementation.
This one breaks the tests: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so htmldoc.c touch htmldoc.ok htmldoc.c:1703: Test failed: expected Invoke_AMBIENT_USERMODE htmldoc.c:1703: Test failed: expected Invoke_AMBIENT_USERMODE htmldoc.c:1703: Test failed: expected Invoke_AMBIENT_USERMODE htmldoc.c:1703: Test failed: expected Invoke_AMBIENT_USERMODE -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
William Knop [EMAIL PROTECTED] writes: Just from keeping up with the mailing list, I've gleaned that Quartz and Core Audio are being worked on, in addition to a stack alignment patch. They seem to be pretty far along, but I don't really know. Are there any other intel/darwin areas that require attention or are being worked on? At this point, many simple apps should probably work OK. The main problems areas that need work are exception handling (mainly because of kernel bugs) and the debugger support that essentially doesn't work at all. You'll also need to disable optimizations when building because of the gcc stack-realign bug (we need to come up with a configure check for it), and you most likely have to use an x.org X server because the Apple one has some serious bugs in rootless mode. So it's not quite ready for prime time yet. We are hoping to have binary packages on WineHQ in the near future, that should make it somewhat easier to get things going. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Autocad 2004 STATUS_INVALID_LDT_OFFSET
Thanks Ivan. I did some IRC with Vitaliy, and he came to the conclusion that the outport() code was probably the result of messed up code/stack, since the program doesn't use any hardware or locks. I will look into it tomorrow. As one other possibility, and I'm not trying to suggest that it's necessarily the case: could the driver want to check if it's indeed running in ring 0 by trying to poke some safe port? I know it'd be weird, but since copy protection is insane in itself, who knows . . . Cheers, Kuba
Re: How do I get the unix filename for a wine handle?
On Saturday 24 June 2006 07:06, Christoph Probst wrote: Hi. Alexandre Julliard wrote: You can't do that in general. In Unix a file can have multiple names, or even none at all, there's simply no way to get a filename from a handle. On Linux you can use /proc/self/fd but that's not very portable. So what do you think about the solution that the wineserver stores the filename in the file object when the object is created? Just like wine_server_handle_to_fd() there would be a wine_server_handle_to_filename() that returns the filename. A way to possibly do what you want to do is to duplicate the file handle, and to hack on ClamAV to scan a file given a handle to it. On unices you can open a file, hold a handle to it, and then remove the directory entry (rm file) -- the file will exist on the disk without a directory entry, for as long as the file handle is open. I don't think you could do that under e.g. Windows, so Unix is different here. In general the only way to get at a file knowing its handle is to use a duplicate handle. That'd be the only robust way AFAIK. Cheers, Kuba
Re: How do I get the unix filename for a wine handle?
just for sake of completeness: how about enhancing ClamAV so that it takes a fd (instead of a filename) as its input ? It looks like as if fd are already supported somehow. Need to have a closer look at that ... But I found an even better alternative: ClamAV supports a STREAM command which allows a client to send a string to the scanner. This allows to scan a string even before it is written to disk. I think that this will totally kill performance. Many programs can create temporary files that later get deleted. There's no point in monitoring writes to those. The only way to tell is to wait until the handle gets closed by wine. Then I imagine you'd use fstat on a copy of the handle and see if there are any hard links (i.e. directory entries) pointing to that inode, and if there are (i.e. if the file is still acessible), only then you'd scan it. You'd also need to keep track of any handle copies that wine holds, if there are any -- I don't know offhand if wine itself duplicates user file handles, nor whether there's a windows API to do so. Similarly, programs such as databases may reorganize huge swaths of file(s), writing a lot of stuff that has no relevance to a virus scanner. I think that no-brainer approaches will result in exactly the same performance-robbing solution as McAffe and Symantec products evolved to. I think there needs to be some more serious thinking done before implementing your project. Cheers, Kuba
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/26/06, Alexandre Julliard [EMAIL PROTECTED] wrote: At this point, many simple apps should probably work OK. The main problems areas that need work are exception handling (mainly because of kernel bugs) and the debugger support that essentially doesn't work at all. You'll also need to disable optimizations when building because of the gcc stack-realign bug (we need to come up with a configure check for it), and you most likely have to use an x.org X server because the Apple one has some serious bugs in rootless mode. Alright, so this is what I've got so far: Overall Status: Simple applications should work. Notes: Make sure to disable gcc optimizations when building since gcc has a stack realignment bug. Also, Apple's X11 has serious bugs in rootless mode, so x.org's X11 may be necessary. Tasks: Quartz Driver: works Core Audio Driver: works 16 Byte Stack Alignment: work in progress Mach Kernel Workarounds and Exception Handling: needs a lot of work Debugger: does not work Anything to add or correct? Thanks, Will
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
On 6/26/06, Alexandre Julliard [EMAIL PROTECTED] wrote: There's no quartz driver in WineHQ. There are some patches floating around but it's very far from working. Oops, I realized that just after I hit send. I'll make sure to state that it has rudimentary support.
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
I'm personally a relative Noop to Wine on Mac intel development. My goal has been to conquer the threading issues that keep it from running most modern-day apps, but I haven't really found the support (at least from the darwine email lists) necessary to write this component. About the only place there I've contributed was on the have a separate vs don't have a separate email list, which IMHO if they have one PPC should be mentioned as when I see the Darwine project I see it as one aimed at Intel macs, not PPC. That may be the reason that my responses have gone quiet over there -- intel isn't a goal. Dave --- James Hawkins [EMAIL PROTECTED] wrote: On 6/26/06, William Knop [EMAIL PROTECTED] wrote: I think you missed my point. I know people are working on it. The problem is a few people, including Codeweavers, are working on it, which is just about the sum-total of the information out there, is not enough. There is very little information out there for potential developers to know what's going on with wine and intel macos x. For instance, a status page describing to-do items would be a start (I'm going to add it to the wine wiki when I figure out what the status is). It should be mentioned on winehq, so macos x developers know to investigate further when they check wine out. Expecting people to dig through the code or the mailing list is unreasonable. Is this really only obvious to me? You could just ask, Hey, what's the status of Wine on Intel Max OS X?. No one has really stepped up to work on that aspect of Wine, outside of Codeweavers, so there's not a whole lot of incentive to put this information up. So if you're wanting to work on this, step up to the plate, and I'm sure we'll be more than willing to help. -- James Hawkins -- David Bialac [EMAIL PROTECTED]
Re: How do I get the unix filename for a wine handle?
Eric Pouech [EMAIL PROTECTED] writes: Christoph Probst wrote: Hi. Alexandre Julliard wrote: You can't do that in general. In Unix a file can have multiple names, or even none at all, there's simply no way to get a filename from a handle. On Linux you can use /proc/self/fd but that's not very portable. So what do you think about the solution that the wineserver stores the filename in the file object when the object is created? Just like wine_server_handle_to_fd() there would be a wine_server_handle_to_filename() that returns the filename. Any objections to this? just for sake of completeness: how about enhancing ClamAV so that it takes a fd (instead of a filename) as its input ? A+ It does http://www.clamav.net/doc/0.88.2/html/node24.html | The daemon is fully configurable via the clamd.conf file 5. clamd recognizes the following commands: ... | STREAM Scan stream: clamd will return a new port number you should connect to and send data to scan. You not need to use following command: | SCAN file/directory Scan file or directory (recursively) with archive support enabled (a full path is required).
How are we doing?[EMAIL PROTECTED]
On Friday, June 02, 2006 07:25, Mike McCormack wrote:
lack of comments in the code
+1, I think it's horrifying.
void the_function_that_adds_one_to_i(int i)
{
/* this adds one to i */
i = i + 1;
/* this returns i to the caller */
return i;
}
Horrifying, yes :)
Mike
I'm not opposed to having bug number in the comments ;)
This message was sent using IMP, the Internet Messaging Program.
Re: [AppDb] [2/3] safe functions
On Monday 26 June 2006 1:50 am, Jonathan Ernst wrote: Le dimanche 25 juin 2006 à 20:00 -0400, Chris Morgan a écrit : Hi Jonathan. You'll want to talk to EA about the filtering changes. The plan is to filter using the same syntax and flags that the php filter extension is going to use so we can easily switch over to this extension in the future. I know we could use PEAR and we could also use a database abstraction layer, I just thought my solution was better because it has proven to work well on several projects I worked recently and is recommanded by the php manual (and it makes queries more readable than using other syntaxes). The most effective solution involves both filtering and sql protection. The first layer of protection is to filter each input variable down to the most restrictive data we can accept. The next step is to ensure that each query, independent of the data passed in, is safe because of the appropriate quoting. With both of these layers in place we can be pretty sure that injection and other attacks on the code will be much less effective. We could probably be secure with only the sql protection in place but the filtering raises the bar greatly for any potential exploits of sql or any other logic in the appdb. Also, I've submitted a patch for review to [EMAIL PROTECTED] and [EMAIL PROTECTED] that removes all of our get_magic_quotes_gpc() use and adds a check in include/incl.php that warns and prevents appdb from running if magic quotes is enabled. So you shouldn't need to have any get_magic_quotes_gpc() checks anymore. Isn't it better to support both configurations ? My solution works with or without magic quotes. I don't believe so. If you read the patch that I submitted or look in include/incl.php you'll see the reasoning behind not bothering with magic quotes. I also noticed your quote_smart_sql() call. This call isn't used anywhere, we shouldn't add calls to functions that aren't called. We It is used in 3/3. also already have a function that will make sql calls safe called query_paramters() in include/db.php. Also, do we want to strip tags from sql? Won't that remove all tags from things like app/version descriptions, comments and notes? No, there is a parameter in this function (quote_smart_sql). By default we don't remove html, but for some fields we might want to filter out html (comment titles, etc.) Ahh I see. Chris
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
Hi William, On 6/26/06, William Knop [EMAIL PROTECTED] wrote: Quartz Driver: works Starting a wiki page just about this would be nice if one does not already exist. I am really interested in the Quartz driver but have not had the time to focus on it. It would be cool if someone could cleanup the diff and or poke at Julliard for his comments on it before too much time is invested in developing it futher. As far as I have seen simple win32 apps work with it which is a good start but it would be nice to have a patch that he could review and advise what more is needed before it can go in winehq. Being able to run Wine without needing the damn X server would be wonderful but its never going to get past the solitare stage unless we can get it in winehq. The last time I spoke with him about it, he said the Quartz driver did not have to be 100% just enough to prove a valid framework which I think the current one does. Namely running solitare without the X. The major infrastructure issue with it the last time I looked was the problem of conflicting functions in the C namespace. The quartzdrv imported and used Mac functions that had the same name as win32 functions and led to all sorts of problems requiring a hack to winebuild. Julliard suggested some linker magic could be done to not require needing to hack winebuild and or making some sort of wrapper library. I am sure there are other issues with design he will want resolved also -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: [AppDb] [2/3] safe functions
Le lundi 26 juin 2006 à 11:54 -0400, Chris Morgan a écrit : [...] The most effective solution involves both filtering and sql protection. The first layer of protection is to filter each input variable down to the most restrictive data we can accept. The next step is to ensure that each query, independent of the data passed in, is safe because of the appropriate quoting. With both of these layers in place we can be pretty sure that injection and other attacks on the code will be much less effective. We could probably be secure with only the sql protection in place but the filtering raises the bar greatly for any potential exploits of sql or any other logic in the appdb. IMHO SQL protection (mysql_real_escape_string()) and correct database design (ex. if we want integer make the field integer, an sql query with something else will fail), along with data filtering when we display user submitted data that doesn't come from database gives the same protection (both SQL and HTML injection) without making the code unreadable and having to copy strings everywhere and have is_integer(), is_empty(), whatever checks everywhere. Also, I've submitted a patch for review to [EMAIL PROTECTED] and [EMAIL PROTECTED] that removes all of our get_magic_quotes_gpc() use and adds a check in include/incl.php that warns and prevents appdb from running if magic quotes is enabled. So you shouldn't need to have any get_magic_quotes_gpc() checks anymore. Isn't it better to support both configurations ? My solution works with or without magic quotes. I don't believe so. If you read the patch that I submitted or look in include/incl.php you'll see the reasoning behind not bothering with magic quotes. echo No! baddslashes()/b isn't adequate. You should use bmysql_real_escape_string()/b or some other function; echo that will handle multi-byte characters. See a href=\http://shiflett.org/archive/184\;this article/a; echo for a way to exploit baddslash()/bed parameters.br/br/; My function does just that. echo A second reason is that with magic quotes enabled, due to the use of bmysql_real_escape_string()/b to; echo protect from sql injection attacks we'll end up with variables that have been addslash()ed and; echo bmysql_real_escape_string()/bed. So you end up having to call stripslashes() on EVERY variable. ; No big deal, my function stripslashes only when magic quotes are enabled so the only drawback of having magic_quotes enabled is that the AppDB is theoretically a bit slower because we have to make a stripslashes before applying mysql_real_escape_string if someone wishes to let magic_quotes enabled. I also noticed your quote_smart_sql() call. This call isn't used anywhere, we shouldn't add calls to functions that aren't called. We It is used in 3/3. also already have a function that will make sql calls safe called query_paramters() in include/db.php. Also, do we want to strip tags from sql? Won't that remove all tags from things like app/version descriptions, comments and notes? No, there is a parameter in this function (quote_smart_sql). By default we don't remove html, but for some fields we might want to filter out html (comment titles, etc.) Ahh I see. Some questions : - Will you apply my coding_standards patch ? - Will you apply my show_error_page patch ? - Will you refuse my proposed way of securing the AppDB ? (I need to know because I'm willing to cleanup the rest of the AppDB regarding this issue (and others) but I don't want to send more patches if they will be discarded) Thanks signature.asc Description: Ceci est une partie de message numériquement signée
Re: indented relay traces
James Hawkins wrote: On 6/24/06, Eric Pouech [EMAIL PROTECTED] wrote: this won't work for a multithreaded program tools/examine_relay does what you want, plus some other goodies (calls that didn't return...) Ah, didn't know about that tool. You learn something new every day. It is also not immediately obvious that it will indent in two slightly different formats. Add a flag to the end of the command line to get different formatting: tools/examine_relay wine.log -f
Re: [AppDb] [2/3] safe functions
On Monday 26 June 2006 12:29 pm, Jonathan Ernst wrote: Le lundi 26 juin 2006 à 11:54 -0400, Chris Morgan a écrit : [...] The most effective solution involves both filtering and sql protection. The first layer of protection is to filter each input variable down to the most restrictive data we can accept. The next step is to ensure that each query, independent of the data passed in, is safe because of the appropriate quoting. With both of these layers in place we can be pretty sure that injection and other attacks on the code will be much less effective. We could probably be secure with only the sql protection in place but the filtering raises the bar greatly for any potential exploits of sql or any other logic in the appdb. IMHO SQL protection (mysql_real_escape_string()) and correct database design (ex. if we want integer make the field integer, an sql query with something else will fail), along with data filtering when we display user submitted data that doesn't come from database gives the same protection (both SQL and HTML injection) without making the code unreadable and having to copy strings everywhere and have is_integer(), is_empty(), whatever checks everywhere. People who write books about php security disagree: http://shiflett.org/articles/security-corner-apr2004 Also, I've submitted a patch for review to [EMAIL PROTECTED] and [EMAIL PROTECTED] that removes all of our get_magic_quotes_gpc() use and adds a check in include/incl.php that warns and prevents appdb from running if magic quotes is enabled. So you shouldn't need to have any get_magic_quotes_gpc() checks anymore. Isn't it better to support both configurations ? My solution works with or without magic quotes. I don't believe so. If you read the patch that I submitted or look in include/incl.php you'll see the reasoning behind not bothering with magic quotes. echo No! baddslashes()/b isn't adequate. You should use bmysql_real_escape_string()/b or some other function; echo that will handle multi-byte characters. See a href=\http://shiflett.org/archive/184\;this article/a; echo for a way to exploit baddslash()/bed parameters.br/br/; My function does just that. Ahh I see, you were addslash()ing the html stuff. echo A second reason is that with magic quotes enabled, due to the use of bmysql_real_escape_string()/b to; echo protect from sql injection attacks we'll end up with variables that have been addslash()ed and; echo bmysql_real_escape_string()/bed. So you end up having to call stripslashes() on EVERY variable. ; No big deal, my function stripslashes only when magic quotes are enabled so the only drawback of having magic_quotes enabled is that the AppDB is theoretically a bit slower because we have to make a stripslashes before applying mysql_real_escape_string if someone wishes to let magic_quotes enabled. I also noticed your quote_smart_sql() call. This call isn't used anywhere, we shouldn't add calls to functions that aren't called. We It is used in 3/3. also already have a function that will make sql calls safe called query_paramters() in include/db.php. Also, do we want to strip tags from sql? Won't that remove all tags from things like app/version descriptions, comments and notes? No, there is a parameter in this function (quote_smart_sql). By default we don't remove html, but for some fields we might want to filter out html (comment titles, etc.) Ahh I see. Some questions : - Will you apply my coding_standards patch ? - Will you apply my show_error_page patch ? - Will you refuse my proposed way of securing the AppDB ? (I need to know because I'm willing to cleanup the rest of the AppDB regarding this issue (and others) but I don't want to send more patches if they will be discarded) coding standard patch has been applied. It was in the queue to be but was busy with other appdb things. show_error_page patch is behind the sql injection patches that are higher priority. Securing the appdb is going to be done in two layers like current experts in the field such as Chris Shiflett and others recommend. The first layer is proper filtering of data, see php.net/filter. Filtering data should ensure that only appropriately typed and valued data can even get into use If we can't get this extension on the server, and I've emailed Jeremy Newman a few times about this without any response, then we should implement our own class that implements just what we need but uses the same syntax and parameter values. This way if we upgrade to php = 5.2 we'll be able to switch over without much trouble. The second layer is the use of query_parameters() for all sql queries. This encapsulates the function we will use to protect each parameter and matches the formatting used in pear db. Making the user call sprintf() and quote_smart_sql() breaks
cvs compile broken
Hey, CVS compile is broken on my machine: make[2]: Entering directory `/home/jhawkins/wine/dlls/wined3d' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o arb_program_shader.o arb_program_shader.c gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o baseshader.o baseshader.c gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o basetexture.o basetexture.c gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o cubetexture.o cubetexture.c gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o device.o device.c device.c: In function `process_vertices_strided': device.c:5015: `GL_READ_ONLY' undeclared (first use in this function) device.c:5015: (Each undeclared identifier is reported only once device.c:5015: for each function it appears in.) device.c:5033: `GL_WRITE_ONLY' undeclared (first use in this function) device.c: In function `IWineD3DDeviceImpl_ProcessVertices': device.c:5352: `GL_READ_ONLY' undeclared (first use in this function) make[2]: *** [device.o] Error 1 make[2]: Leaving directory `/home/jhawkins/wine/dlls/wined3d' make[1]: *** [wined3d] Error 2 make[1]: Leaving directory `/home/jhawkins/wine/dlls' make: *** [dlls] Error 2 -- James Hawkins
Re: cvs compile broken
On 6/26/06, James Hawkins [EMAIL PROTECTED] wrote: Hey, CVS compile is broken on my machine: Part two: vertexbuffer.c: In function `IWineD3DVertexBufferImpl_PreLoad': vertexbuffer.c:145: `GL_ARRAY_BUFFER' undeclared (first use in this function) vertexbuffer.c:145: (Each undeclared identifier is reported only once vertexbuffer.c:145: for each function it appears in.) vertexbuffer.c: In function `IWineD3DVertexBufferImpl_Lock': vertexbuffer.c:349: `GL_READ_WRITE' undeclared (first use in this function) vertexbuffer.c:355: `GL_WRITE_ONLY' undeclared (first use in this function) vertexbuffer.c:357: `GL_READ_ONLY' undeclared (first use in this function) vertexbuffer.c:361: `GL_ARRAY_BUFFER' undeclared (first use in this function) vertexbuffer.c: In function `IWineD3DVertexBufferImpl_Unlock': vertexbuffer.c:381: `GL_ARRAY_BUFFER' undeclared (first use in this function) make[2]: *** [vertexbuffer.o] Error 1 make[2]: Leaving directory `/home/jhawkins/wine/dlls/wined3d' -- James Hawkins
Re: cvs compile broken
James Hawkins wrote: On 6/26/06, James Hawkins [EMAIL PROTECTED] wrote: Hey, CVS compile is broken on my machine: It sounds like gcc is not finding your GL headers. I gained mine by installing Mesa. On my SUSE 10.1 system, they got installed under /usr/include/GL/. -- Andy.
Re: cvs compile broken
On 6/26/06, Andrew Talbot [EMAIL PROTECTED] wrote: James Hawkins wrote: On 6/26/06, James Hawkins [EMAIL PROTECTED] wrote: Hey, CVS compile is broken on my machine: It sounds like gcc is not finding your GL headers. I gained mine by installing Mesa. On my SUSE 10.1 system, they got installed under /usr/include/GL/. hmm I don't think so. Even if that were the case, we should still handle it without user intervention. I'm pretty sure it's a versioning problem, because this has happened before (recently). I'm on a modified Red Hat 9 system. -- James Hawkins
WoW broken for wine 0.9.16 Nvidia cards
Hi, Just a quick question, WoW ( World of Warcraft ) was broken (for Nvidia cards) with there latest software update. Is anybody working on fixing Wow (with Nvidia Cards) ( working fine with ATI ). I just wondered if there was an opengl guru working on fixing this broken application ?. Or whether I should invest some time in learning more about the intricacies of wine and openg and NVidia !.. and fix it myself ( my background is C and assembler (not Intel, but RT11 Perkin Elmer) ? One of the users was asking about progress on fixing this app. I would like to respond back with some progress but suspect nobody is working on it :-( Regards Nick Law * Now where's that Learn opengl/wine/graphics in 21 days book ..*
Re: cvs compile broken
CVS compile is broken on my machine: I've got a patch for this, will send later.
keyboard keypress codepath
Hi, Recently I've been trying to make MS Word work on my box, and just now I've finally managed to do that without resorting to winetools etc. (thanks to the work of msi.dll people). Now the problem is that I use Lithuanian keyboard layout on my gnome desktop and it doesn't properly translate some of the non-latin letters (like 'ąčęėįųū'). When I press one of those MS Word shows 'a/A' instead of 'ą/Ą', 'c/C' instead of 'č/Č', etc. Letter 'š/Š', though is mapped correctly. Same things happen for capital letters too. [This mail is supposed to be unicode one, sorry for those incapable of seeing those letters] It appears to be some mapping issue for letters that didn't have their canonical mappings previously (or something, I'm not an expert on codepages). Would anyone guide me with several sentences on where to look for those mapping tables (or code) in wine source tree? Thanks.
Re: New dlls/ddraw/device.c warnings
Am Montag 26 Juni 2006 19:13 schrieben Sie: After the recent sets of changes, I found that GCC 3.4 issues the following warnings (on FreeBSD 5.4. I checked and depending on how a compiler implements assert(), the warnings are valid, insofar as the compiler doesn't have a way to automatically determine that all code paths are covered: device.c: In function `Thunk_IDirect3DDeviceImpl_2_Begin': device.c:1826: warning: 'FVF' might be used uninitialized in this function device.c: In function `Thunk_IDirect3DDeviceImpl_2_BeginIndexed': device.c:1886: warning: 'FVF' might be used uninitialized in this function device.c: In function `Thunk_IDirect3DDeviceImpl_2_DrawPrimitive': device.c:2752: warning: 'FVF' might be used uninitialized in this function device.c: In function `Thunk_IDirect3DDeviceImpl_2_DrawIndexedPrimitive': device.c:2891: warning: 'FVF' might be used uninitialized in this function Could you have a look into this, Stefan? If someone has a hint on the preferred approach to address this, I can give it a try as well. This seems to be a clear case of 'stupid compiler'. The assert(0) in the default case of the switch statement will terminate the app, but it the compiler thinks that the call below will be called. I sent a fix which replaces the assertions by an ERR log and an error return to wine-patches Thanks for the hint Stefan pgpgWt1poompr.pgp Description: PGP signature
Re: [AppDB] - user class cleanup and implement user class unit test
Le lundi 26 juin 2006 à 15:33 -0400, Chris Morgan a écrit : [...] Comments? Questions? Index: index.php === RCS file: /opt/cvs-commit/appdb/index.php,v retrieving revision 1.33 diff -u -r1.33 index.php --- index.php 21 Jun 2006 01:04:12 - 1.33 +++ index.php 26 Jun 2006 19:26:39 - @@ -7,7 +7,7 @@ * application environment */ include(path.php); -require(BASE.include/incl.php); +require_once(BASE.include/incl.php); Why use require_once ? It is slower and is bad unless you intend to include index.php in another file where incl.php is also included... Index: include/image.php === RCS file: /opt/cvs-commit/appdb/include/image.php,v retrieving revision 1.5 diff -u -r1.5 image.php --- include/image.php 21 Sep 2005 14:16:40 - 1.5 +++ include/image.php 26 Jun 2006 19:26:40 - @@ -3,6 +3,8 @@ /* image and image_resource classes */ /*/ +include_once(BASE.include/incl.php); + This time you use include once, we should use require everywhere if incl.php is required (and including a file in another include is not so pretty IMHO). +/* NOTE: we can't update the users password like we can update other */ +/* fields such as their email or username because the password is hashed */ +/* in the database so we can't keep the users password in a class member variable */ +/* and use update() because we can't check if the password changed without hashing */ +/* the newly supplied one */ +function update_password($sPassword) Should updatePassword according to our coding standards (method names). signature.asc Description: Ceci est une partie de message numériquement signée
Re: How are we doing?[EMAIL PROTECTED]
notNeeded=0;
if (Ishack())
{
/*(hacks are not accepted)*/
notNeeded=1;
}
else if(IsFeature())
{
notNeeded=0;
}
PS
:P for the if - then constructs
On 6/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Friday, June 02, 2006 07:25, Mike McCormack wrote:
lack of comments in the code
+1, I think it's horrifying.
void the_function_that_adds_one_to_i(int i)
{
/* this adds one to i */
i = i + 1;
/* this returns i to the caller */
return i;
}
Horrifying, yes :)
Mike
I'm not opposed to having bug number in the comments ;)
This message was sent using IMP, the Internet Messaging Program.
Re: WoW broken for wine 0.9.16 Nvidia cards
Nick wrote: Hi, Just a quick question, WoW ( World of Warcraft ) was broken (for Nvidia cards) with there latest software update. Is anybody working on fixing Wow (with Nvidia Cards) ( working fine with ATI ). I just wondered if there was an opengl guru working on fixing this broken application ?. Or whether I should invest some time in learning more about the intricacies of wine and openg and NVidia !.. and fix it myself ( my background is C and assembler (not Intel, but RT11 Perkin Elmer) ? One of the users was asking about progress on fixing this app. I would like to respond back with some progress but suspect nobody is working on it :-( Regards Nick Law * Now where's that Learn opengl/wine/graphics in 21 days book ..* maybe I spoke too soon, a fix may have just become available ( we'll see after more tests ) :-)
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
Yeah, a wiki page for the Quartz driver would be nice. There are a couple implementations floating around, some using QuickDraw and some using CoreGraphics. Most have endian bugs, since they were written with Darwine/PPC in mind. As far as which is best, it seems to be that QD is easiest, but it's a deprecated API. I think I'd use CG if I decided to sit down and write it, which I might do. I've got some free time, and in a week or so I'll have access to an intel mac for development. Thoughts on CG? Alexandre? Will On 6/26/06, Steven Edwards [EMAIL PROTECTED] wrote: Hi William, On 6/26/06, William Knop [EMAIL PROTECTED] wrote: Quartz Driver: works Starting a wiki page just about this would be nice if one does not already exist. I am really interested in the Quartz driver but have not had the time to focus on it. It would be cool if someone could cleanup the diff and or poke at Julliard for his comments on it before too much time is invested in developing it futher. As far as I have seen simple win32 apps work with it which is a good start but it would be nice to have a patch that he could review and advise what more is needed before it can go in winehq. Being able to run Wine without needing the damn X server would be wonderful but its never going to get past the solitare stage unless we can get it in winehq. The last time I spoke with him about it, he said the Quartz driver did not have to be 100% just enough to prove a valid framework which I think the current one does. Namely running solitare without the X. The major infrastructure issue with it the last time I looked was the problem of conflicting functions in the C namespace. The quartzdrv imported and used Mac functions that had the same name as win32 functions and led to all sorts of problems requiring a hack to winebuild. Julliard suggested some linker magic could be done to not require needing to hack winebuild and or making some sort of wrapper library. I am sure there are other issues with design he will want resolved also -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: [AppDB] - user class cleanup and implement user class unit test
On Monday 26 June 2006 6:06 pm, Jonathan Ernst wrote: Le lundi 26 juin 2006 à 15:33 -0400, Chris Morgan a écrit : [...] Comments? Questions? Index: index.php === RCS file: /opt/cvs-commit/appdb/index.php,v retrieving revision 1.33 diff -u -r1.33 index.php --- index.php 21 Jun 2006 01:04:12 - 1.33 +++ index.php 26 Jun 2006 19:26:39 - @@ -7,7 +7,7 @@ * application environment */ include(path.php); -require(BASE.include/incl.php); +require_once(BASE.include/incl.php); Why use require_once ? It is slower and is bad unless you intend to include index.php in another file where incl.php is also included... I can't recall why anymore. I've reverted this change and everything still seems to work. Index: include/image.php === RCS file: /opt/cvs-commit/appdb/include/image.php,v retrieving revision 1.5 diff -u -r1.5 image.php --- include/image.php 21 Sep 2005 14:16:40 - 1.5 +++ include/image.php 26 Jun 2006 19:26:40 - @@ -3,6 +3,8 @@ /* image and image_resource classes */ /*/ +include_once(BASE.include/incl.php); + This time you use include once, we should use require everywhere if incl.php is required (and including a file in another include is not so pretty IMHO). Reverted this change too since I can't recall why I made this change either. +/* NOTE: we can't update the users password like we can update other */ +/* fields such as their email or username because the password is hashed */ +/* in the database so we can't keep the users password in a class member variable */ +/* and use update() because we can't check if the password changed without hashing */ +/* the newly supplied one */ +function update_password($sPassword) Should updatePassword according to our coding standards (method names). Updated. Chris
Re: Wine, Darwine, CodeWeavers-- Intel MacOS X
After looking at Darwine's quartzdrv, it looks like it uses CoreGraphics. On 6/26/06, William Knop [EMAIL PROTECTED] wrote: Yeah, a wiki page for the Quartz driver would be nice. There are a couple implementations floating around, some using QuickDraw and some using CoreGraphics. Most have endian bugs, since they were written with Darwine/PPC in mind. As far as which is best, it seems to be that QD is easiest, but it's a deprecated API. I think I'd use CG if I decided to sit down and write it, which I might do. I've got some free time, and in a week or so I'll have access to an intel mac for development. Thoughts on CG? Alexandre? Will On 6/26/06, Steven Edwards [EMAIL PROTECTED] wrote: Hi William, On 6/26/06, William Knop [EMAIL PROTECTED] wrote: Quartz Driver: works Starting a wiki page just about this would be nice if one does not already exist. I am really interested in the Quartz driver but have not had the time to focus on it. It would be cool if someone could cleanup the diff and or poke at Julliard for his comments on it before too much time is invested in developing it futher. As far as I have seen simple win32 apps work with it which is a good start but it would be nice to have a patch that he could review and advise what more is needed before it can go in winehq. Being able to run Wine without needing the damn X server would be wonderful but its never going to get past the solitare stage unless we can get it in winehq. The last time I spoke with him about it, he said the Quartz driver did not have to be 100% just enough to prove a valid framework which I think the current one does. Namely running solitare without the X. The major infrastructure issue with it the last time I looked was the problem of conflicting functions in the C namespace. The quartzdrv imported and used Mac functions that had the same name as win32 functions and led to all sorts of problems requiring a hack to winebuild. Julliard suggested some linker magic could be done to not require needing to hack winebuild and or making some sort of wrapper library. I am sure there are other issues with design he will want resolved also -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
wined3d: Regression in DX8 SDK samples with VBO patch
http://source.winehq.org/git/?p=wine.git;a=commit;h=2122026713baa318093181607db79d7577f728e9 This patch breaks most of the DirectX 8 SDK Direct3D samples (Billboard, ClipMirror, Cull, etc.). It seems like most of the samples that use Shaders work fine, but those that don't are broken (misplaced vertices, etc.).
Re: Opengl states in wined3d
On 6/25/06, Stefan Dösinger [EMAIL PROTECTED] wrote: The way opengl states are managed in wined3d at the moment is a bit messy and inefficient. Agreed. :-) * Brute force applying opengl states is likely to re-set the old state unnecessarily. Opengl does not assure that redundant calls are cheap. * if an application sets and resets a state for some reason between 2 drawprim calls that involves 2 not really necessary opengl state switches I have this problem with Fog settings in the case of shaders. If I set restore the fog states on each drawPrimitive, it will drop the fps from 1250 to about 1000 in the Dolphin demo compared to just setting it once and leaving it. I've been holding off on a patch (pretty much taken from Roderick Colenbrander) for this reason. At the moment in current git, fog is broken when used with shaders (Dolphin demo and Tomb Raider Legend are affected). I can think of a few ways to solve this: * Do not do any opengl changes in SetRenderState, and apply all states in drawprim. This way UnlockRect and Blt don't have to care for resetting the things they changed and redundant changes can be catched nicely This style is probably the best, since we (hopefully) don't have to change much between drawPrim calls. Just have a function which compares the current GL state to the desired (cached) state, and change only what's necessary. However, some things (as you mentioned) can be changed safely during SetRenderState, and that's outside of the drawPrim loop, so hopefully it's just once per scene. Though, every game acts a bit differently, so it's tough to say how one method will work over another. But the caching method seems the cleanest to me. To avoid re-setting an old setting again the current opengl state could be stored in the d3ddevice. I think this should be done in any case, and depending on the nature of some parameters the opengl state or the d3d state should be kept in there(or both). Agreed. I also think we should try to get rid of as much things as possible in drawprim. I do not mean entirely removing it, but having a simple flag which tells if a bigger number of states needs attention, like last_was_rhw does. I think about adding a last_was_blit flag which is set in BltOverride and UnlockRect. Yep. So, let's get a final game plan together and I can start the process with the fog patch, then we can start cleaning up everything else (which will be a fairly large undertaking but can be done in small chunks). Jason
Re: [AppDB] Make screen shots safe from SQL injection
Chris Morgan wrote: Yes, having quotes around limit values breaks sql queries. I'll incorporate this into the injection change patch. I'm curious as to why the rest of the patch is the same though. It will conflict when the other sql patch is applied. What other sql patch? How will it conflict? I have broken your large patch up in order to test it, since you refused to do it yourself. This is the portion of the patch that I tested. I had to modify it a bit like I said but the rest is yours and you get the credit. What do you plan on doing with this patch? Are you planning to wait until I have tested all various parts of your big patch and then apply it all at once? -- Tony Lambregts
Re: [AppDB] Make screen shots safe from SQL injection
On Monday 26 June 2006 11:38 pm, Tony Lambregts wrote: Chris Morgan wrote: Yes, having quotes around limit values breaks sql queries. I'll incorporate this into the injection change patch. I'm curious as to why the rest of the patch is the same though. It will conflict when the other sql patch is applied. What other sql patch? How will it conflict? I have broken your large patch up in order to test it, since you refused to do it yourself. This is the portion of the patch that I tested. I had to modify it a bit like I said but the rest is yours and you get the credit. What do you plan on doing with this patch? Are you planning to wait until I have tested all various parts of your big patch and then apply it all at once? -- Tony Lambregts As we've discussed before I'd rather we did a single full pass of manual testing than several full passes. It saves us time in that we don't have to test the same things repeatedly like we would have to do when making changes to things like classes that are used all over the code. In any case I'm implementing unit tests for nearly every bug I find. I haven't thought of a good way to unit test page actions yet though. Chris
Re: [AppDb] html cleanup
What is the justification for making this change? I can't find anything on w3.org that suggests that these values should be lowercase and the documentation seems to suggest that for the 'type' attribute the values should all be upper case, http://www.w3.org/TR/html4/sgml/dtd.html#InputType Chris On Monday 26 June 2006 6:18 pm, Jonathan Ernst wrote: Changelog: - html attributes and values are lowercase
