Re: [PATCH v6 1/7] VFS: Introduce new O_DENY* open flags
On Fri, 26 Apr 2013 16:04:15 +0400
Pavel Shilovsky pias...@etersoft.ru wrote:
This patch adds 3 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename.
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this change can benefit cifs and nfs modules as well as Samba and
NFS file servers that export the same directory for Windows clients,
or Wine applications that access the same files simultaneously.
These flags are only take affect for opens on mounts with new sharelock
option. They are translated to flock's flags:
!O_DENYREAD - LOCK_READ | LOCK_MAND
!O_DENYWRITE - LOCK_WRITE | LOCK_MAND
and set through flock_lock_file on a file. If the file can't be locked
due conflicts with another open with O_DENY* flags, a new -ESHAREDENIED
error code is returned.
Create codepath is slightly changed to prevent data races on
newely created files: when open with O_CREAT can return -ESHAREDENIED
error for successfully created files due to a sharelock set by
another task.
Temporary disable O_DENYDELETE support - will enable it in further patches.
Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
fs/fcntl.c | 5 ++-
fs/locks.c | 97
+---
fs/namei.c | 45 +--
fs/proc_namespace.c | 1 +
include/linux/fs.h | 7 +++
include/uapi/asm-generic/errno.h | 2 +
include/uapi/asm-generic/fcntl.h | 11 +
include/uapi/linux/fs.h | 1 +
8 files changed, 156 insertions(+), 13 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 6599222..a1eee47 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -730,14 +730,15 @@ static int __init fcntl_init(void)
* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
* is defined as O_NONBLOCK on some platforms and not on others.
*/
- BUILD_BUG_ON(19 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
+ BUILD_BUG_ON(22 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
O_RDONLY| O_WRONLY | O_RDWR|
O_CREAT | O_EXCL| O_NOCTTY |
O_TRUNC | O_APPEND | /* O_NONBLOCK | */
__O_SYNC| O_DSYNC | FASYNC|
O_DIRECT| O_LARGEFILE | O_DIRECTORY |
O_NOFOLLOW | O_NOATIME | O_CLOEXEC |
- __FMODE_EXEC| O_PATH
+ __FMODE_EXEC| O_PATH| O_DENYREAD|
+ O_DENYWRITE | O_DENYDELETE
));
fasync_cache = kmem_cache_create(fasync_cache,
diff --git a/fs/locks.c b/fs/locks.c
index cb424a4..dbc5557 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -605,20 +605,73 @@ static int posix_locks_conflict(struct file_lock
*caller_fl, struct file_lock *s
return (locks_conflict(caller_fl, sys_fl));
}
-/* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific
- * checking before calling the locks_conflict().
+static unsigned int
+deny_flags_to_cmd(unsigned int flags)
+{
+ unsigned int cmd = LOCK_MAND;
+
+ if (!(flags O_DENYREAD))
+ cmd |= LOCK_READ;
+ if (!(flags O_DENYWRITE))
+ cmd |= LOCK_WRITE;
+
+ return cmd;
+}
+
+/*
+ * locks_mand_conflict - Determine if there's a share reservation conflict
+ * @caller_fl: lock we're attempting to acquire
+ * @sys_fl: lock already present on system that we're checking against
+ *
+ * Check to see if there's a share_reservation conflict. LOCK_READ/LOCK_WRITE
+ * tell us whether the reservation allows other readers and writers.
+ */
+static int
+locks_mand_conflict(struct file_lock *caller_fl, struct file_lock *sys_fl)
+{
+ unsigned char caller_type = caller_fl-fl_type;
+ unsigned char sys_type = sys_fl-fl_type;
+ fmode_t caller_fmode = caller_fl-fl_file-f_mode;
+ fmode_t sys_fmode = sys_fl-fl_file-f_mode;
+
+ /* they can only conflict if FS is mounted with MS_SHARELOCK */
+ if (!IS_SHARELOCK(caller_fl-fl_file-f_path.dentry-d_inode))
+ return 0;
+
+ /* they can only conflict if they're both LOCK_MAND */
+ if (!(caller_type LOCK_MAND) || !(sys_type LOCK_MAND))
+ return 0;
+
+ if (!(caller_type LOCK_READ) (sys_fmode FMODE_READ))
+ return 1;
+ if (!(caller_type LOCK_WRITE) (sys_fmode FMODE_WRITE))
+ return 1;
+ if (!(sys_type LOCK_READ) (caller_fmode FMODE_READ))
+ return 1;
+ if (!(sys_type LOCK_WRITE) (caller_fmode FMODE_WRITE))
+ return 1;
+
+ return 0;
+}
+
+/*
+ * Determine if lock sys_fl blocks lock caller_fl. FLOCK specific checking
+ * before calling the locks_conflict().
*/
static int flock_locks_conflict(struct
Re: [PATCH v6 2/7] VFS: Add O_DENYDELETE support for VFS
On Fri, 26 Apr 2013 16:04:16 +0400
Pavel Shilovsky pias...@etersoft.ru wrote:
Introduce new LOCK_DELETE flock flag that is suggested to be used
internally only to map O_DENYDELETE open flag:
!O_DENYDELETE - LOCK_DELETE | LOCK_MAND.
Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
fs/locks.c | 53
+---
fs/namei.c | 3 +++
include/linux/fs.h | 6 +
include/uapi/asm-generic/fcntl.h | 1 +
4 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index dbc5557..1cc68a9 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -269,7 +269,7 @@ EXPORT_SYMBOL(locks_copy_lock);
static inline int flock_translate_cmd(int cmd) {
if (cmd LOCK_MAND)
- return cmd (LOCK_MAND | LOCK_RW);
+ return cmd (LOCK_MAND | LOCK_RW | LOCK_DELETE);
switch (cmd) {
case LOCK_SH:
return F_RDLCK;
@@ -614,6 +614,8 @@ deny_flags_to_cmd(unsigned int flags)
cmd |= LOCK_READ;
if (!(flags O_DENYWRITE))
cmd |= LOCK_WRITE;
+ if (!(flags O_DENYDELETE))
+ cmd |= LOCK_DELETE;
return cmd;
}
@@ -836,6 +838,31 @@ out:
return error;
}
+int
+sharelock_may_delete(struct dentry *dentry)
+{
+ struct file_lock **before;
+ int rc = 0;
+
+ if (!IS_SHARELOCK(dentry-d_inode))
+ return rc;
+
+ lock_flocks();
+ for_each_lock(dentry-d_inode, before) {
+ struct file_lock *fl = *before;
+ if (IS_POSIX(fl))
+ break;
+ if (IS_LEASE(fl))
+ continue;
+ if (fl-fl_type LOCK_DELETE)
+ continue;
Are you sure this logic is right? What if I have a normal non-LOCK_MAND
lock on this file. Won't that prevent me from deleting it with this
patch?
+ rc = 1;
+ break;
+ }
+ unlock_flocks();
+ return rc;
+}
+
/*
* Determine if a file is allowed to be opened with specified access and
share
* modes. Lock the file and return 0 if checks passed, otherwise return
@@ -850,10 +877,6 @@ sharelock_lock_file(struct file *filp)
if (!IS_SHARELOCK(filp-f_path.dentry-d_inode))
return error;
- /* Disable O_DENYDELETE support for now */
- if (filp-f_flags O_DENYDELETE)
- return -EINVAL;
-
error = flock_make_lock(filp, lock, deny_flags_to_cmd(filp-f_flags));
if (error)
return error;
@@ -1717,6 +1740,12 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int,
cmd)
if (!f.file)
goto out;
+ /* LOCK_DELETE is defined to be translated from O_DENYDELETE only */
+ if (cmd LOCK_DELETE) {
+ error = -EINVAL;
+ goto out;
+ }
+
can_sleep = !(cmd LOCK_NB);
cmd = ~LOCK_NB;
unlock = (cmd == LOCK_UN);
@@ -2261,10 +2290,16 @@ static void lock_get_status(struct seq_file *f,
struct file_lock *fl,
seq_printf(f, UNKNOWN UNKNOWN );
}
if (fl-fl_type LOCK_MAND) {
- seq_printf(f, %s ,
-(fl-fl_type LOCK_READ)
-? (fl-fl_type LOCK_WRITE) ? RW: READ
-: (fl-fl_type LOCK_WRITE) ? WRITE : NONE
);
+ if (fl-fl_type LOCK_DELETE)
+ seq_printf(f, %s ,
+ (fl-fl_type LOCK_READ) ?
+ (fl-fl_type LOCK_WRITE) ? RWDEL : RDDEL :
+ (fl-fl_type LOCK_WRITE) ? WRDEL : DEL );
+ else
+ seq_printf(f, %s ,
+ (fl-fl_type LOCK_READ) ?
+ (fl-fl_type LOCK_WRITE) ? RW: READ :
+ (fl-fl_type LOCK_WRITE) ? WRITE : NONE );
} else {
seq_printf(f, %s ,
(lease_breaking(fl))
diff --git a/fs/namei.c b/fs/namei.c
index dd236fe..a404f7d 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2220,6 +2220,7 @@ static inline int check_sticky(struct inode *dir,
struct inode *inode)
* 9. We can't remove a root or mountpoint.
* 10. We don't allow removal of NFS sillyrenamed files; it's handled by
* nfs_async_unlink().
+ * 11. We can't do it if victim is locked by O_DENYDELETE sharelock.
*/
static int may_delete(struct inode *dir,struct dentry *victim,int isdir)
{
@@ -2250,6 +2251,8 @@ static int may_delete(struct inode *dir,struct dentry
*victim,int isdir)
return -ENOENT;
if (victim-d_flags DCACHE_NFSFS_RENAMED)
return -EBUSY;
+ if (sharelock_may_delete(victim))
+ return -ESHAREDENIED;
return 0;
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index
Re: comdlg32: Store client GUID with SetClientGuid()
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=25944 Your paranoid android. === TEST64_W7SP1 (32 bit itemdlg) === itemdlg: unhandled exception c005 at 75AF1AC3
Re: [PATCH] d3dx9_36: Set compilation_errors to NULL when no error encountered + tests.
2013/6/11 Rico Schüller kgbric...@web.de On 11.06.2013 22:08, Christian Costa wrote: Fixes bug 26598. --- dlls/d3dx9_36/effect.c |4 dlls/d3dx9_36/tests/effect.c | 17 + 2 files changed, 21 insertions(+) diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c index 1924c07..bab4560 100644 --- a/dlls/d3dx9_36/effect.c +++ b/dlls/d3dx9_36/effect.c @@ -5792,6 +5792,10 @@ HRESULT WINAPI D3DXCreateEffectEx(struct IDirect3DDevice9 *device, const void *s *effect = object-ID3DXEffect_iface; +/* Must be set to NULL if no compilation error */ +if (compilation_errors) +*compilation_errors = NULL; + No, this is wrong! Your test case doesn't cover all cases. Which cases? Ssource effects or possible parsing error of binary ones? Anyway my intention was to fix only this particular case as we don't support source effect yet. I'll use a different approach.
Re: [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests.
2013/6/11 Rico Schüller kgbric...@web.de On 11.06.2013 22:08, Christian Costa wrote: +TRACE(byte_code = %p, semantics = %p, count = %p\n, byte_code, semantics, count); The rest of the file seems to use the trace without the =. Indeed. I made a little confusion. Will fix that. +ok(ret == D3D_OK, Failed with %#xn, ret); +ok(count == 3, Got %u, expected 1\n, count); Should be \n and expected 3. Both several times. Ok thanks. As the return value for semantics is in both tests the same, it might be useful to initialize the semantics first to check that the values are really set in both cases. You're right. I'll to that. What does D3DXGetShaderInputSemantics(**semantics_vs11, NULL, NULL); and D3DXGetShaderInputSemantics(**NULL, NULL, NULL); return? Well both are corner cases without much meaning. I'll add them as well. You may check for the semantics where the count is NULL like D3DXGetShaderInputSemantics(**semantics_vs11, semantics, NULL); Make sense. I'll do that. Thanks Christian
Re: Possible wine bug concerning the case of the DbgHelp.h header filename
On 12 June 2013 01:49, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: I successfully built the ultra-fast ninja build tool on Wine using the MinGW g++ compiler. To achieve that success I had to deal with a small number of issues including one wine/ninja header name inconsistency which is that DbgHelp.h (#included by the ninja code) has a lower-case name (dbghelp.h) on wine, and the MinGW suite of compilers is sensitive to the case of header file names. I worked around this issue with the following symlink /home/wine/wine_build/install-git/include/wine/windows/DbgHelp.h - dbghelp.h where /home/wine/wine_build/install-git is my install prefix for my wine-git build. Is Wine following the correct Windows naming convention for this header? There's no such thing, at least wrt. case; Windows is case insensitive. Wine just uses lower case, and for the most part that's also the C / Unix convention, although there are certainly exceptions. Typically you'd just change your source (Ninja in this case) to consistently use lower case, instead of creating symlinks.
Re: [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests.
+HRESULT WINAPI D3DXGetShaderInputSemantics(const DWORD *byte_code,
D3DXSEMANTIC *semantics, UINT *count)
+{
+const DWORD *ptr = byte_code;
+UINT i = 0;
+
+TRACE(byte_code = %p, semantics = %p, count = %p\n, byte_code,
semantics, count);
+
+if (!byte_code)
+return D3DERR_INVALIDCALL;
+
+TRACE(Shader version: %#x\n, *ptr);
+
+/* Look for the END token, skipping the VERSION token */
+while (*++ptr != D3DSIO_END)
I think you should be a bit more careful in skipping non-opcode
DWORDs, otherwise you could e.g. potentially match with constants from
DEF instructions - very unlikely to happen in practice, sure, but
since it can be easily avoided, why not?
Take a look at shader_skip_opcode() from wined3d/shader_sm1.c. You can
probably get away without having to write a table with the parameters
count for each SM1 opcode by just skipping DWORDs with the most
significant bit set (see shader_skip_unrecognized() from the same
file). Of course you still have to special case DEF but that should be
it.
I was thinking about this kind of problem but followed what
D3DXGetShaderSize does.
So D3DXGetShaderSize will have to be fixed as well.
So if I summarize:
if (sm 2) handle instruction length
else if (comment or def instruction) special handling for them
else skip DWORD with bit 31 set
Is this correct?
+{
+/* Skip comments */
+if ((*ptr D3DSI_OPCODE_MASK) == D3DSIO_COMMENT)
+{
+ptr += ((*ptr D3DSI_COMMENTSIZE_MASK)
D3DSI_COMMENTSIZE_SHIFT);
+}
+else if ((*ptr D3DSI_OPCODE_MASK) == D3DSIO_DCL)
+{
+DWORD param1 = *++ptr;
+DWORD param2 = *++ptr;
+DWORD usage = param1 0x1f;
+DWORD usage_index = (param1 16) 0xf;
+DWORD reg_type = (((param2 11) 0x3) 3) | ((param2
28) 0x7);
+
+TRACE(D3DSIO_DCL param1: %#x, param2: %#x, usage: %u,
usage_index: %u, reg_type: %u\n,
+ param1, param2, usage, usage_index, reg_type);
+
+if (reg_type == D3DSPR_INPUT)
+{
+if (semantics)
+{
+semantics[i].Usage = usage;
+semantics[i].UsageIndex = usage_index;
+}
+i++;
+}
+}
+}
+
+if (count)
+*count = i;
+
+return D3D_OK;
+}
Have you tried to implement D3DXGetShaderOutputSemantics too? I
suspect most of the code will be pretty much the same, in that case
you could move the common code to a helper function and use it from
both.
You don't necessarily need to do this right now, just mentioning a
potential follow-up.
I tought about it too. There are indeed similar. I planned to do it later
but I will do it in this patch since I have to update it anyway.
Thanks
Christian
Re: wininet/tests: Avoid proxy test failures on old wininet.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=25946 Your paranoid android. === WXPX64 (32 bit http) === http.c:4459: Test failed: 4630: expected status 100 got 10 http.c:4459: Test failed: 4674: expected status 100 got 40 http.c:4432: Test failed: ar-dwResult = 0, expected 1 http.c:4459: Test failed: 4683: expected status 70 got 100 http: unhandled exception c005 at 7722EDEA
Re: Possible wine bug concerning the case of the DbgHelp.h header filename
On Wednesday 12 June 2013 02:49:26 am Alan W. Irwin wrote: I successfully built the ultra-fast ninja build tool on Wine using the MinGW g++ compiler. To achieve that success I had to deal with a small number of issues including one wine/ninja header name inconsistency which is that DbgHelp.h (#included by the ninja code) has a lower-case name (dbghelp.h) on wine, and the MinGW suite of compilers is sensitive to the case of header file names. I worked around this issue with the following symlink /home/wine/wine_build/install-git/include/wine/windows/DbgHelp.h - dbghelp.h where /home/wine/wine_build/install-git is my install prefix for my wine-git build. Is Wine following the correct Windows naming convention for this header? For what it is worth, I did a google search for windows dbghelp.h and most of the hits were for DbgHelp.h rather than dbghelp.h so I can understand why the ninja developers used #includeDbgHelp.h rather than the lower-case version of that name. If the wine developers here decide this is definitely a wine issue, I am willing to write up the bug report on your bugtracker so this issue doesn't get lost. A search there for header case filename did not turn up anything relevant. Alan Hi! The Platform SDK creates DbgHelp.h however it shouldn't matter for Windows programs as they are case insensitive. The problem here is that MinGW somehow operates case sensitive so raise a bug for that. Paul
Re: [PATCH] d3dx9_36: Set compilation_errors to NULL when no error encountered + tests.
On 12.06.2013 10:31, Christian Costa wrote:
2013/6/11 Rico Schüller kgbric...@web.de
On 11.06.2013 22:08, Christian Costa wrote:
Fixes bug 26598.
---
dlls/d3dx9_36/effect.c |4
dlls/d3dx9_36/tests/effect.c | 17 +
2 files changed, 21 insertions(+)
diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c
index 1924c07..bab4560 100644
--- a/dlls/d3dx9_36/effect.c
+++ b/dlls/d3dx9_36/effect.c
@@ -5792,6 +5792,10 @@ HRESULT WINAPI D3DXCreateEffectEx(struct
IDirect3DDevice9 *device, const void *s
*effect = object-ID3DXEffect_iface;
+/* Must be set to NULL if no compilation error */
+if (compilation_errors)
+*compilation_errors = NULL;
+
No, this is wrong! Your test case doesn't cover all cases.
Which cases? Ssource effects or possible parsing error of binary ones?
Anyway my intention was to fix only this particular case as we don't
support source effect yet.
I'll use a different approach.
The position of setting the compilation_errors is wrong. It should be
before all other sanity checks. The intention is fine. See the attached
patch...
Yes this should only fix this particular case. I don't think the
compiler is ready to get called, yet.
Cheers
Rico
commit 04974b07438954ef28578b9527beff413ba9a16e
Author: Rico Schüller kgbric...@web.de
Date: Wed Jun 12 11:54:46 2013 +0200
d3dx9: Set compilation_errors to NULL in D3DXCreateEffectEx().
diff --git a/dlls/d3dx9_36/effect.c b/dlls/d3dx9_36/effect.c
index 464124d..b7d22fa 100644
--- a/dlls/d3dx9_36/effect.c
+++ b/dlls/d3dx9_36/effect.c
@@ -5789,6 +5789,9 @@ HRESULT WINAPI D3DXCreateEffectEx(struct IDirect3DDevice9 *device, const void *s
FIXME((%p, %p, %u, %p, %p, %p, %#x, %p, %p, %p): semi-stub\n, device, srcdata, srcdatalen, defines, include,
skip_constants, flags, pool, effect, compilation_errors);
+if (compilation_errors)
+*compilation_errors = NULL;
+
if (!device || !srcdata)
return D3DERR_INVALIDCALL;
diff --git a/dlls/d3dx9_36/tests/effect.c b/dlls/d3dx9_36/tests/effect.c
index 7f238be..6626aa8 100644
--- a/dlls/d3dx9_36/tests/effect.c
+++ b/dlls/d3dx9_36/tests/effect.c
@@ -2662,6 +2662,26 @@ static void test_effect_variable_names(IDirect3DDevice9 *device)
ok(!count, Release failed %u\n, count);
}
+static void test_effect_compilation_errors(IDirect3DDevice9 *device)
+{
+ID3DXEffect *effect;
+ID3DXBuffer *compilation_errors;
+HRESULT hr;
+
+/* Test binary effect */
+compilation_errors = (ID3DXBuffer *)0xdeadbeef;
+hr = D3DXCreateEffect(device, test_effect_variable_names_blob,
+sizeof(test_effect_variable_names_blob), NULL, NULL, 0, NULL, effect, compilation_errors);
+ok(hr == D3D_OK, D3DXCreateEffect failed, got %#x, expected %#x\n, hr, D3D_OK);
+ok(!compilation_errors, Returned %p\n, compilation_errors);
+effect-lpVtbl-Release(effect);
+
+compilation_errors = (ID3DXBuffer *)0xdeadbeef;
+hr = D3DXCreateEffect(NULL, NULL, 0, NULL, NULL, 0, NULL, NULL, compilation_errors);
+ok(hr == D3DERR_INVALIDCALL, D3DXCreateEffect failed, got %#x, expected %#x\n, hr, D3DERR_INVALIDCALL);
+ok(!compilation_errors, Returned %p\n, compilation_errors);
+}
+
START_TEST(effect)
{
HWND wnd;
@@ -2698,6 +2718,7 @@ START_TEST(effect)
test_create_effect_compiler();
test_effect_parameter_value(device);
test_effect_variable_names(device);
+test_effect_compilation_errors(device);
count = IDirect3DDevice9_Release(device);
ok(count == 0, The device was not properly freed: refcount %u\n, count);
Re: [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests.
On 12 June 2013 00:17, Matteo Bruni matteo.myst...@gmail.com wrote: I think you should be a bit more careful in skipping non-opcode DWORDs, otherwise you could e.g. potentially match with constants from DEF instructions - very unlikely to happen in practice, sure, but since it can be easily avoided, why not? Take a look at shader_skip_opcode() from wined3d/shader_sm1.c. You can probably get away without having to write a table with the parameters count for each SM1 opcode by just skipping DWORDs with the most significant bit set (see shader_skip_unrecognized() from the same file). Of course you still have to special case DEF but that should be it. Ideally we'd have some more test shaders in dlls/d3dx9_36/tests/shader.c that would trigger these, and also run the various other shader processing functions against those.
Re: [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests.
2013/6/12 Christian Costa titan.co...@gmail.com:
+HRESULT WINAPI D3DXGetShaderInputSemantics(const DWORD *byte_code,
D3DXSEMANTIC *semantics, UINT *count)
+{
+const DWORD *ptr = byte_code;
+UINT i = 0;
+
+TRACE(byte_code = %p, semantics = %p, count = %p\n, byte_code,
semantics, count);
+
+if (!byte_code)
+return D3DERR_INVALIDCALL;
+
+TRACE(Shader version: %#x\n, *ptr);
+
+/* Look for the END token, skipping the VERSION token */
+while (*++ptr != D3DSIO_END)
I think you should be a bit more careful in skipping non-opcode
DWORDs, otherwise you could e.g. potentially match with constants from
DEF instructions - very unlikely to happen in practice, sure, but
since it can be easily avoided, why not?
Take a look at shader_skip_opcode() from wined3d/shader_sm1.c. You can
probably get away without having to write a table with the parameters
count for each SM1 opcode by just skipping DWORDs with the most
significant bit set (see shader_skip_unrecognized() from the same
file). Of course you still have to special case DEF but that should be
it.
I was thinking about this kind of problem but followed what
D3DXGetShaderSize does.
So D3DXGetShaderSize will have to be fixed as well.
So if I summarize:
if (sm 2) handle instruction length
else if (comment or def instruction) special handling for them
else skip DWORD with bit 31 set
Is this correct?
SM = 2 for the instruction length case, but apart from that it should be good.
Ideally we'd use some tests, as Henri suggested, but that's not
blocking this patch I think.
+{
+/* Skip comments */
+if ((*ptr D3DSI_OPCODE_MASK) == D3DSIO_COMMENT)
+{
+ptr += ((*ptr D3DSI_COMMENTSIZE_MASK)
D3DSI_COMMENTSIZE_SHIFT);
+}
+else if ((*ptr D3DSI_OPCODE_MASK) == D3DSIO_DCL)
+{
+DWORD param1 = *++ptr;
+DWORD param2 = *++ptr;
+DWORD usage = param1 0x1f;
+DWORD usage_index = (param1 16) 0xf;
+DWORD reg_type = (((param2 11) 0x3) 3) | ((param2
28) 0x7);
+
+TRACE(D3DSIO_DCL param1: %#x, param2: %#x, usage: %u,
usage_index: %u, reg_type: %u\n,
+ param1, param2, usage, usage_index, reg_type);
+
+if (reg_type == D3DSPR_INPUT)
+{
+if (semantics)
+{
+semantics[i].Usage = usage;
+semantics[i].UsageIndex = usage_index;
+}
+i++;
+}
+}
+}
+
+if (count)
+*count = i;
+
+return D3D_OK;
+}
Have you tried to implement D3DXGetShaderOutputSemantics too? I
suspect most of the code will be pretty much the same, in that case
you could move the common code to a helper function and use it from
both.
You don't necessarily need to do this right now, just mentioning a
potential follow-up.
I tought about it too. There are indeed similar. I planned to do it later
but I will do it in this patch since I have to update it anyway.
Thanks
Christian
Re: [PATCH] d3dx9_36: Implement D3DXGetShaderInputSemantics + tests.
if (sm 2) handle instruction length else if (comment or def instruction) special handling for them else skip DWORD with bit 31 set Is this correct? SM = 2 for the instruction length case, but apart from that it should be good. Oups. Tipo. It's what I meant. Ideally we'd use some tests, as Henri suggested, but that's not blocking this patch I think. I'll try to add some of them for that case.
Wine's Tahoma...
Hi, So working on Arabic font issues I have started really looking at wine's Tahoma font. Windows Tahoma covers glyphs in quite a few ranges, Latin, Cyrillic, Hebrew, Arabic, Thai to name a few. Wine's Tahoma has bit a fraction of this coverage. Looking to improve our Arabic support, I found that our Tahoma heavily uses glyphs from DejaVu fonts already, which are public domain. I was wondering if we wanted to take the leap and just replace our Tahoma completely with DejaVu Sans? We can generate a fontforge sfd file for the file and adjust the family names as required. We would retain the copyrights so that we honer the source. But it would give us the glyphs we need to have a fully functional Tahoma. What is the thought on this? If there is strong opposition then I have a patch to include Arabic in our font, but it really seems like many users in other scripts would benefit greatly from having a more fully fleshed out tahoma. -aric
Using of mac driver completely breaks tablets support?
Hi All! I've installed a Wine 1.5.31 instead of 1.4.smthng and found that tablets support is broken. Some research gives me that wintab32 DLL fails to init because winemac driver doesn't implement tablet related functions (LoadTabletInfo etc) unlike x11 driver. I'm a Wine newcomer so probably I get something wrong about it... How can I switch back to x11 driver? BR, Andrey Upadyshev
Re: Wine's Tahoma...
Aric Stewart a...@codeweavers.com wrote: Looking to improve our Arabic support, I found that our Tahoma heavily uses glyphs from DejaVu fonts already, which are public domain. Before making such claims I'd suggest to investigate first history behind creation of Tahoma font replacement in Wine, and at least read its copyright statement. Then you may try to investigate the reasons of bitmap glyph sets, and what happens without them. Once the investigation step is done you may try to add glyphs one by one which cover all the discovered issues. -- Dmitry.
Re: Using of mac driver completely breaks tablets support?
Hi, On Jun 12, 2013, at 10:47 AM, Andrey Upadyshev wrote: I've installed a Wine 1.5.31 instead of 1.4.smthng and found that tablets support is broken. Some research gives me that wintab32 DLL fails to init because winemac driver doesn't implement tablet related functions (LoadTabletInfo etc) unlike x11 driver. I'm a Wine newcomer so probably I get something wrong about it... No, you're correct. The Mac driver does not yet support tablet input devices. How can I switch back to x11 driver? In the registry, set the following: [HKEY_CURRENT_USER\Software\Wine\Drivers] Graphics=x11 Some of the basics of how to do that (although not this specific thing) are documented at http://wiki.winehq.org/UsefulRegistryKeys. Regards, Ken
Re: Possible wine bug concerning the case of the DbgHelp.h header filename
On 2013-06-12 12:37+0300 Paul Chitescu wrote: Hi! The Platform SDK creates DbgHelp.h however it shouldn't matter for Windows programs as they are case insensitive. The problem here is that MinGW somehow operates case sensitive so raise a bug for that. You are right. So I put together a simple example demonstrating this MinGW issue and it worked fine indicating that MinGW has no such bug and can deal with these case issues with no problem. There must have been some other issue with my complicated example, and my apologies to you and Henri for the noise I generated about this issue, but also my thanks to you guys for clarifying the issue. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: gdiplus: fix a clipping regression in GdipDrawString (try 2)
What if rect.Width is 0.25? Shouldn't we still clip then?
Re: Using of mac driver completely breaks tablets support?
Thank you Ken! On Wed, Jun 12, 2013 at 8:35 PM, Ken Thomases k...@codeweavers.com wrote: Hi, On Jun 12, 2013, at 10:47 AM, Andrey Upadyshev wrote: I've installed a Wine 1.5.31 instead of 1.4.smthng and found that tablets support is broken. Some research gives me that wintab32 DLL fails to init because winemac driver doesn't implement tablet related functions (LoadTabletInfo etc) unlike x11 driver. I'm a Wine newcomer so probably I get something wrong about it... No, you're correct. The Mac driver does not yet support tablet input devices. How can I switch back to x11 driver? In the registry, set the following: [HKEY_CURRENT_USER\Software\Wine\Drivers] Graphics=x11 Some of the basics of how to do that (although not this specific thing) are documented at http://wiki.winehq.org/UsefulRegistryKeys. Regards, Ken
