Firstly a quick note: I have opened a bug for implementation of wintab.dll (Bug No. 1160)
Now the questions:
1: Writing stubs. I'll be taking up Patrik Stridvall's offer to write stubs for anyone new to wine development. One question about stubs: What's the wine policy on stub return values? Should a stub always return an error? Should/Can it return success?
2: Testing wintab.dll in Win98. wintab.dll is quite complex for what it does. Therefore the only practical way to implement it is to work on the functions and communication models that are used by the apps I want it to support.
To do this, I need some tool that can log the function calls and parameters to the DLL, while wunning Win98.The logging must be able to let the programmer choose elements from data stuctures in parameters/retvals to log. Any ideas????
I've attempted to use apis32 and built a wintab.fnl file for wintab.dll. Unfortunately apis32 doen't allow the logging of the contents of data structs.
I would also like to know experinces with Spy++. Wintab can send it's own custom messages, so I'm wondering how good Spy++ is at detecting custom messages?
I've used it many times before, but only to examine standard windows messages.
3: Coding standards. I haven't found any coding standards associated with wine. This is particularly important, as I'll be writing new source files. Can someone point me to the standards?
Hope you guys have the answers -Rob.
Due to Robert's question regarding coding standards, I would like to summarize the discussion from a while back. If someone wants to take this discussion and turn it into a HOWTO.....
These are, to the best of my memory, the conclusions. In the examples, \t means tab (it will be followed by a real tab), ^ means space: 1. Indentations - Hard tabs must be used for indicating indent level. That means that the function definition is at the begning of the line, first level is preceded by one tab, etc. If your convention is that continuation lines are a single indent deeper, use a tab for that as well.
func() { \t for( a=0; b<a; \t \t a-- ) \t { \t \t do something;
2. Tabs should not used for anything other than indicating indent level, as that would create a dependancy on tab size. If your convention is that continuation lines are aligned with constructs from the previous line, use spaces to perform the alignments
... \t for( a=0; b<a; \t ^^^^a-- )
3. Tab size should be around 3 characters. Some prefer 2, some prefer 4, but if the above guidlines are followed this should not change the correctness of rendering. 4. Open curly braces defining a function must come on the following line to the function definition:
int funct( void ) { \t ... }
5. Open curly braces defining an internal block may be either on the following line or at the end of the line triggering the brace:
\t for( i=0; i<50; ++i ) \t { \t \t array[i]=17; \t }
Or:
\t for( i=0; i<50; ++i ) { \t \t array[i]=17; \t }
The most important of all the rules: 6. When changing code written by someone else, follow the existing convention with your new code.
Subjects still missing: - Hungarian notaion - gift of god or a creation of evil? - Non Win32 API functions - names, parameter names, types?
Shachar
On November 25, 2002 02:38 am, Shachar Shemesh wrote:
- Tab size should be around 3 characters. Some prefer 2, some prefer 4,
but if the above guidlines are followed this should not change the correctness of rendering.
Sorry, I think this is just plain wrong. Tab was always defined as being 8. Any other definition will just make code look like shit. We (the Wine ppl) almost never use 8 spaces indentation in the code. And _nobody_ uses just tabs to indent code. So all this tab rules simply has no chance in hell of working. Moreover, even if they do, they require Wine-specific editor settings which is just silly. Many times you edit things in editors you either can not control, or are not on your machine, and don't have the time and inclination to configure.
Just stick to the standard: tab is 8. No mess, no fuss.
- Tab size should be around 3 characters. Some prefer 2, some prefer 4,
but if the above guidlines are followed this should not change the correctness of rendering.
Sorry, I think this is just plain wrong. Tab was always defined as being 8. Any other definition will just make code look like shit. We (the Wine ppl) almost never use 8 spaces indentation in the code. And _nobody_ uses just tabs to indent code. So all this tab rules simply has no chance in hell of working. Moreover, even if they do, they require Wine-specific editor settings which is just silly. Many times you edit things in editors you either can not control, or are not on your machine, and don't have the time and inclination to configure.
Just stick to the standard: tab is 8. No mess, no fuss.
This is more a philosophical topic than a technical so I'm prepared for flames :)
I think you're exagerating. In our company we too have source guidelines and they say quite the same what Shachar mentioned. We use tabs for indenting and the "size" is 4 chars. Tab=8 is maybe standard in text programs for writing letters or whatever but here we're talking of source file editors. Even with a normal text editor you can follow these guidelines. And even if you used spaces there are functions like Space2Tab. "Use the right tool for the right task" (TM, but not mine) :)
bye Fabi
On Mon, 25 Nov 2002, Shachar Shemesh wrote: [...]
These are, to the best of my memory, the conclusions. In the examples, \t means tab (it will be followed by a real tab), ^ means space:
- Indentations - Hard tabs must be used for indicating indent level.
We don't have a standard but the closest thing we have is code written by Alexandre and he is certainly not using tabs. He seems tobe using 4 space indentations instead.
Dosn't this:
\t for( a=0; b<a; \t \t a-- )
^^
contradict this
\t for( a=0; b<a; \t ^^^^a-- )
The extra tab seems wrong in the first example. (Yeah, the rules involving tabs are complex and one is way too likely to get them wrong)
Besides if you leave a space after the '(', isn't it more logical to align 'a--' with 'a=0'? (Solution: don't leave a space after '(', but that's just me)
One rule we do have: No space at the end of lines.
On November 25, 2002 03:50 am, Francois Gouget wrote:
One rule we do have: No space at the end of lines.
No we don't, sorry. Not any more. I mean, sure, don't add whitespace at the end of the line intentionally, but if it's there, it's no big thing.
-
Dimitrie O. Paun -
Fabian Cenedese -
Francois Gouget -
Robert North -
Shachar Shemesh