Hello, I am making slow progress with this thing. It grew sort of usable: can be cross compiled and run to produce sensible output (tested on XP only). Present questions: 1. How to integrate cross compilation into the Makefile? 2. It is possible to compile this as a Winelib application, but the spawn call must be modified to invoke Wine instead of the test itself. Gives better results for the comctl32 tests (DPA import et al.), but is it worth it? Do we need is_elf and friends? 3. How to derive/give the cleaning rules? 4. Did Jon Bright contribute his SMTP client in the end? We could as well use it... Or would it be better (more reliable) to POST it through HTTP? 5. The #include section at the top of main.c looks weird. (It is the minimum to compile without warnings.) Maybe mkdir() should be moved into port.h? 6. EXTRADEFS = -DWINELIB is probably the wrong way. 7. Is there a way to get this into CVS after all? Feri.
On November 10, 2003 10:18 pm, Ferenc Wagner wrote:
I am making slow progress with this thing. It grew sort of usable: can be cross compiled and run to produce sensible output (tested on XP only). Present questions:
Looks good, but why did you change it from a cui to a gui? I guess it's fine, we will want to go down that path eventually...
1. How to integrate cross compilation into the Makefile?
That's an interesting question. I suggest we create two .rc files: winetests-elf.rc and winetests-pe.rc, and we link it with the other stuff in two executables: winetests and winetests.exe respectively. Any other ideas?
2. It is possible to compile this as a Winelib application, but the spawn call must be modified to invoke Wine instead of the test itself. Gives better results for the comctl32 tests (DPA import et al.), but is it worth it? Do we need is_elf and friends?
Well, I was hoping that we can have one executable that just links in with different .rc. In other words, when we compile main.c (to get main.o) we don't know if we're going to run a PE or ELF tests.
3. How to derive/give the cleaning rules?
What cleaning rules?
4. Did Jon Bright contribute his SMTP client in the end? We could as well use it... Or would it be better (more reliable) to POST it through HTTP?
Yes, he did send it to me some time ago. What happens now with the output? We don't seem to be sending it anywhere... I'll forward it to you in a few moments.
5. The #include section at the top of main.c looks weird. (It is the minimum to compile without warnings.) Maybe mkdir() should be moved into port.h?
Yes, it does. I'm not sure how to cleanly solve the mkdir problem, they just have conflicting prototypes between OSes...
7. Is there a way to get this into CVS after all?
Create a patch and submit it. Let's try to get it into the tree, so we can close this sucker, otherwise we'll lose steam and who knows when it will happen. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Looks good, but why did you change it from a cui to a gui? I guess it's fine, we will want to go down that path eventually...
Er, I did not. I think it has been a gui ever since its birth...
1. How to integrate cross compilation into the Makefile?
That's an interesting question. I suggest we create two .rc files: winetests-elf.rc and winetests-pe.rc, and we link it with the other stuff in two executables: winetests and winetests.exe respectively. Any other ideas?
Sounds good enough. The question was about the Makefile, though. I don't know the build system, unfortunately, so I don't even know if it has the necessary basis for this.
Well, I was hoping that we can have one executable that just links in with different .rc. In other words, when we compile main.c (to get main.o) we don't know if we're going to run a PE or ELF tests.
Ok, that will be done.
3. How to derive/give the cleaning rules?
What cleaning rules?
In the Makefile, again. That's why I added the PROGRAMS = winetests.c winetests.rc ... hack to the Makefile.
4. Did Jon Bright contribute his SMTP client in the end? We could as well use it... Or would it be better (more reliable) to POST it through HTTP?
Yes, he did send it to me some time ago. What happens now with the output? We don't seem to be sending it anywhere... I'll forward it to you in a few moments.
Thanks, got it. Not sure... Presently, the output simply stays in the log file (it's not deleted). It got rid of the shell dependencies for now. Feri.
On November 11, 2003 05:53 am, Ferenc Wagner wrote:
Sounds good enough. The question was about the Makefile, though. I don't know the build system, unfortunately, so I don't even know if it has the necessary basis for this.
It has no basis for it, I guess we'll just need to create different targets in the Makefile.in. Maybe by default we should build the Winelib app, and be build the PE one only when invoked explicitly: make winetests.exe
3. How to derive/give the cleaning rules?
What cleaning rules?
In the Makefile, again. That's why I added the PROGRAMS = winetests.c winetests.rc ... hack to the Makefile.
What about just addding a new clean:: target.
Thanks, got it. Not sure... Presently, the output simply stays in the log file (it's not deleted). It got rid of the shell dependencies for now.
Yes, but I'm not that sure it's a good trade. I think the shell idea was a good first-order approximation. I'd rather get winetests in the tree with the shell dependency, get your scripts integrated into WineHQ, get people to test, etc. (that is, there is a lot more work to be done to have the full circle completed), and worry about getting rid of it only after that. The advantage is that by the time people will be using the program, and we'll have a much better idea what they want, so we don't waste time coding on theoretical ideas only. Time to market is of the essence (and it's not a bad idea to begin with). -- Dimi.
On Tue, Nov 11, 2003 at 04:18:20AM +0100, Ferenc Wagner wrote:
Hello,
I am making slow progress with this thing. It grew sort of usable: can be cross compiled and run to produce sensible output (tested on XP only). Present questions:
Ahh! Progress, sweet! :-)
4. Did Jon Bright contribute his SMTP client in the end? We could as well use it... Or would it be better (more reliable) to POST it through HTTP?
I think he did but... SMTP is a horrible protocol. HTTP is sweet. :-) -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News
Jakob Eriksson <jakob(a)vmlinux.org> writes:
On Tue, Nov 11, 2003 at 04:18:20AM +0100, Ferenc Wagner wrote:
4. Did Jon Bright contribute his SMTP client in the end? We could as well use it... Or would it be better (more reliable) to POST it through HTTP?
I think he did but... SMTP is a horrible protocol. HTTP is sweet. :-)
They got complicated the same way when the machine is behind a firewall or proxy, I am afraid. It's a pity Windows does not have a standard mailer... Feri.
On Tue, 11 Nov 2003 11:56:56 +0100, Sir Ferenc Wagner scribed thus:
I think he did but... SMTP is a horrible protocol. HTTP is sweet. :-)
They got complicated the same way when the machine is behind a firewall or proxy, I am afraid. It's a pity Windows does not have a standard mailer...
MAPI? For HTTP wininet is the standard service provider.
Hello, I'm currently porting a Windows application to the Mac and Linux. I've got many details worked out but the one that I am still researching is how to load resources like strings and bitmaps. What I would like to do is distribute the resources the application uses as a .RES file that I would then manipulate with something like the LoadResource function. I have read that work has been done in the Wine project to make it able to be used by other projects like ReactOS and Cygwin. Is the Wine source-code structured in such a way that it would be possible to extract the LoadResource function and do this? Is there a simpler way? I'm open to suggestions. Thank you.
Jean-Claude Gervais wrote:
Hello,
I'm currently porting a Windows application to the Mac and Linux.
I've got many details worked out but the one that I am still researching is how to load resources like strings and bitmaps.
What I would like to do is distribute the resources the application uses as a .RES file that I would then manipulate with something like the LoadResource function.
I have read that work has been done in the Wine project to make it able to be used by other projects like ReactOS and Cygwin.
Is the Wine source-code structured in such a way that it would be possible to extract the LoadResource function and do this?
Is there a simpler way? if you want your app to be a winelib app, then this is not an issue, you'll be able to directly use any win32 api you want (starting with LoadResource & LoadString), as well as putting the resource itself into the executable. See the doc for the details to build a winelib app. A+
-- Eric Pouech
Thank you very much, Eric, For taking the time to help me. I'm afraid I may not have explained my problem very clearly: First, if I use Winelib, must I bind the resources to my executable? The reason I ask is because since I am developing an application for the Mac, can I bind resources to the Macintosh exectable? I thought that that might be a problem. I understand that Wine has components in it that are like a system loader, meaning that it is able to bring the executable image into memory and then resolve the .DLL entry points it needs. This is more than what I need, actually. Also, I don't expect that it can do this with a Macintosh executable, or can it? That's why I was wondering if the resource-manipulation routines can read .RES files, which should (in theory) be platform independant. OK, so in essence, what I am looking for is portable code that will be able to walk a .RES file and load things from it. I'm not as familiar as many people on this list with the internals of Wine, so that's why I am asking. Thanks. On Tue, 2003-11-11 at 15:08, Eric Pouech wrote:
Jean-Claude Gervais wrote:
Hello,
I'm currently porting a Windows application to the Mac and Linux.
I've got many details worked out but the one that I am still researching is how to load resources like strings and bitmaps.
What I would like to do is distribute the resources the application uses as a .RES file that I would then manipulate with something like the LoadResource function.
I have read that work has been done in the Wine project to make it able to be used by other projects like ReactOS and Cygwin.
Is the Wine source-code structured in such a way that it would be possible to extract the LoadResource function and do this?
Is there a simpler way? if you want your app to be a winelib app, then this is not an issue, you'll be able to directly use any win32 api you want (starting with LoadResource & LoadString), as well as putting the resource itself into the executable. See the doc for the details to build a winelib app. A+
Jean-Claude Gervais <jc.gervais(a)videotron.ca> writes:
That's why I was wondering if the resource-manipulation routines can read .RES files, which should (in theory) be platform independant.
OK, so in essence, what I am looking for is portable code that will be able to walk a .RES file and load things from it.
The code to parse a resource structure is in dlls/ntdll/resource.c. You can also look at tools/winebuild/res32.c if you need to check the .res file header. -- Alexandre Julliard julliard(a)winehq.com
Jean-Claude Gervais wrote:
Thank you very much, Eric,
For taking the time to help me. I'm afraid I may not have explained my problem very clearly:
First, if I use Winelib, must I bind the resources to my executable? The reason I ask is because since I am developing an application for the Mac, can I bind resources to the Macintosh exectable? I thought that that might be a problem. that's supported. resources are compiled as a big byte array (as a C file), and then included in the exec.
I understand that Wine has components in it that are like a system loader, meaning that it is able to bring the executable image into memory and then resolve the .DLL entry points it needs. This is more than what I need, actually. yes
Also, I don't expect that it can do this with a Macintosh executable, or can it? as of today, winelib programs are system shareable libraries, loaded by a system executable called wine. (replace here system by mac, linux...).
That's why I was wondering if the resource-manipulation routines can read .RES files, which should (in theory) be platform independant. they are partly portable (except for typedefs, remaining calls...)
OK, so in essence, what I am looking for is portable code that will be able to walk a .RES file and load things from it. then do as Alexandre suggested. A+ -- Eric Pouech
Mike Hearn <mike(a)theoretic.com> writes:
On Tue, 11 Nov 2003 11:56:56 +0100, Sir Ferenc Wagner scribed thus:
I think he did but... SMTP is a horrible protocol. HTTP is sweet. :-)
They got complicated the same way when the machine is behind a firewall or proxy, I am afraid. It's a pity Windows does not have a standard mailer...
MAPI? For HTTP wininet is the standard service provider.
At first reading, it does not help much with posting forms... Anyway, it has the same problem as the Shell API: it is not supported on NT3. But do we really care? On the other hand, I can imagine creating a Web form for file uploads, which could be used if everything else fails, and would also be easy to talk to through Winsock. Feri.
Ferenc Wagner wrote:
Jakob Eriksson <jakob(a)vmlinux.org> writes:
I think he did but... SMTP is a horrible protocol. HTTP is sweet. :-)
They got complicated the same way when the machine is behind a firewall or proxy, I am afraid. It's a pity Windows does not have a standard mailer...
In the approach I took, that is using IE (or other registered web browser) to send the data, proxies, dialups etc should be taken care of. If the standard web browser is not correctly configured, well tough luck. Maybe the system doesn't even have Internet access! regards, Jakob
participants (8)
-
Alexandre Julliard -
Dimitrie O. Paun -
Eric Pouech -
Ferenc Wagner -
Jakob Eriksson -
Jakob Eriksson -
Jean-Claude Gervais -
Mike Hearn