Hi all,
I have placed on my site the slides for a presentation I gave at a local LUG about Wine. The slides are in English, in PDF format. You can get them at http://shemesh.biz/lectures.html
The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time.
Shachar
This is a pretty rocking presentation. I may steal it sometime (if I ever give a presentation on Wine), so I hope it's under a free license :) Some notes as I read:
* I say Wine is an emulator. I don't know how to read the official definition, it could go both ways, but I've found the whole "Wine Is Not an Emulator" thing just confuses newbies :)
* Slide 12 - s/Challange/Challenge/
* Slide 17 - 3rd file type is NE (win16 binary). PE = Portable Executable. NE = ?????, but the N is bound to stand for something stupid, like "new" or whatever....
* Slide 18 - s/relocate/mmap/ ??
* Slide 21 - s/contextes/contexts/. I'd also note that the wineserver does a lot of things the windows kernel does in the real mccoy - for instance the registry is available from inside kernel mode also...
* Slide 23 - I sent a patch ages ago to make Wine autodetect RH9 and add --with-nptl if needed
keep on truckin' -mike :)
----- Original Message ----- From: "Mike Hearn" [email protected] To: "Shachar Shemesh" [email protected]
- I say Wine is an emulator. I don't know how to read the official
definition, it could go both ways, but I've found the whole "Wine Is Not an Emulator" thing just confuses newbies :)
I taste to think that the "Wine is a simulator", because it simulates the Windows environment. Poverty not?
- Slide 17 - 3rd file type is NE (win16 binary). PE = Portable
Executable. NE = ?????, but the N is bound to stand for something stupid, like "new" or whatever....
Yes, NE = New Executable, as the opposite to format MZ, that was the predominant format until the new creation. Already MZ I do not remember what it means.
M.
Marcelo Duarte wrote:
----- Original Message ----- From: "Mike Hearn" [email protected] To: "Shachar Shemesh" [email protected]
- I say Wine is an emulator. I don't know how to read the official
definition, it could go both ways, but I've found the whole "Wine Is Not an Emulator" thing just confuses newbies :)
I taste to think that the "Wine is a simulator", because it simulates the Windows environment. Poverty not?
- Slide 17 - 3rd file type is NE (win16 binary). PE = Portable
Executable. NE = ?????, but the N is bound to stand for something stupid, like "new" or whatever....
Yes, NE = New Executable, as the opposite to format MZ, that was the predominant format until the new creation. Already MZ I do not remember what it means.
M.
MZ are the first two bytes of the file, identifying it as an executable. I'm not aware that they mean anything at all.
Shachar
Shachar Shemesh wrote:
Marcelo Duarte wrote:
----- Original Message ----- From: "Mike Hearn" [email protected] To: "Shachar Shemesh" [email protected]
- I say Wine is an emulator. I don't know how to read the official
definition, it could go both ways, but I've found the whole "Wine Is Not an Emulator" thing just confuses newbies :)
I taste to think that the "Wine is a simulator", because it simulates the Windows environment. Poverty not?
- Slide 17 - 3rd file type is NE (win16 binary). PE = Portable
Executable. NE = ?????, but the N is bound to stand for something stupid, like "new" or whatever....
Yes, NE = New Executable, as the opposite to format MZ, that was the predominant format until the new creation. Already MZ I do not remember what it means.
M.
MZ are the first two bytes of the file, identifying it as an executable. I'm not aware that they mean anything at all.
IIRC, they were the initial of the author(s) of the file format A+
søn, 21.09.2003 kl. 08.46 skrev Eric Pouech:
MZ are the first two bytes of the file, identifying it as an executable. I'm not aware that they mean anything at all.
IIRC, they were the initial of the author(s) of the file format
Mark Zbikowski. But that's just a theory, I haven't heard about anybody really knowing for sure what it stands for, I think (many books mention this theory, but never like it was a fact).
From: "Ove Kaaven" [email protected] To: "Eric Pouech" [email protected] Cc: "Shachar Shemesh" [email protected]; "Marcelo Duarte" [email protected]; "Wine Devel" [email protected] Sent: Sunday, September 21, 2003 2:25 PM Subject: Re: Wine lecture slides
søn, 21.09.2003 kl. 08.46 skrev Eric Pouech:
MZ are the first two bytes of the file, identifying it as an
executable.
I'm not aware that they mean anything at all.
IIRC, they were the initial of the author(s) of the file format
Mark Zbikowski. But that's just a theory, I haven't heard about anybody really knowing for sure what it stands for, I think (many books mention this theory, but never like it was a fact).
I also read this theory in a book, and perhaps either exactly this name. I find that he was in the book "The MSDOS Bible" of Ray Duncan.
Shachar Shemesh wrote:
Hi all,
I have placed on my site the slides for a presentation I gave at a local LUG about Wine. The slides are in English, in PDF format. You can get them at http://shemesh.biz/lectures.html
The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time.
Shachar
S6: what about Corel ??? S8: ReWind is not for TG. TG is not based on ReWind. ReWind serves as a X11-cross platform between Wine and WineX. There's also Odin (Win32 subsystem on OS/2), but the shared code based is less than with ReactOS. S17: I would complement "re-implementing" by the fact we translate Win calls into local OS calls (mostly) S18: in Win DLL terminology, EntryPoint is the main init function from a module. Exports/Imports would be better here. S20: I'm a bit confused with "all win32 Dlls are implemented as winelib apps". Firstly, a DLL is not an app. Secondly, from a pure technical point of view, we're talking here of two different things: - win32 builtin DLLs are implemented as specific ELF shared library. The PE loader, when loading DLL, is able to load either builtin DLL or windows native DLLs. - a winelib app, is an ELF executable (not shared library), which is able to execute as a Win32 application (loading DLLs, calling into (native/builtin) DLLs). The wording here is perhaps short enough for a generic presentation, but it's IMO rather confusing. S21: the first need of wineserver is that any wine application leaves in its own address space. So, all the interprocess communication/synchronisation has to be done somewhere => wineserver.
as a more generic comment, what about adding a couple of screen shots ? (just to complement on the alpha side of Wine => "it does work in lots of cases")
anyway, I think it would be good to share those slides (there are already a couple of them on WineHQ) if we want to keep on making this type of presentations to LUG and other events.
A+
"Eric Pouech" [email protected] wrote:
S8: ReWind is not for TG. TG is not based on ReWind. ReWind serves as a X11-cross platform between Wine and WineX.
I do not want to start a flame war, but you just repeat what TG wants ReWind to be looking like on public. That's simply not true. Right now it's an one directional way: Wine -> ReWind -> WineX. And in my opinion that's an exactly an idea behind that.
I do not want to start a flame war, but you just repeat what TG wants ReWind to be looking like on public. That's simply not true. Right now it's an one directional way: Wine -> ReWind -> WineX. And in my opinion that's an exactly an idea behind that.
As of today, If something happens, it's more Wine -> WineX than anything else. A+
søn, 21.09.2003 kl. 10.30 skrev Dmitry Timoshkov:
"Eric Pouech" [email protected] wrote:
S8: ReWind is not for TG. TG is not based on ReWind. ReWind serves as a X11-cross platform between Wine and WineX.
I do not want to start a flame war, but you just repeat what TG wants ReWind to be looking like on public. That's simply not true. Right now it's an one directional way: Wine -> ReWind -> WineX. And in my opinion that's an exactly an idea behind that.
Yes, that's the way ReWind currently work (and the ReWind maintenance tools are written for that). After all, new work from WineX preferably flows like this: WineX -> Wine -> ReWind. It's a unidirectional circle (and I don't think Alexandre will apply anything that's ReWind-only without permission (if he did, he'd probably have to add ReWind to Wine's copyright files anyway, which is probably not fun), so this unidirectional arrangement benefit Wine too).
Of course, the current laziness of the ReWind maintainers is another matter... it's a long time since "they" merged in any new patches from Wine and WineX... both have a few things which should be merged sooner or later...
On September 21, 2003 03:06 am, Eric Pouech wrote:
- a winelib app, is an ELF executable (not shared library), which is
able to execute as a Win32 application (loading DLLs, calling into (native/builtin) DLLs).
Well, not really -- that would be ideal, but at the moment a winelib app is an ELF shared library (.so file) which is loaded by wine. That's why we have that startup script for winelib apps...
Dimitrie O. Paun wrote:
On September 21, 2003 03:06 am, Eric Pouech wrote:
- a winelib app, is an ELF executable (not shared library), which is
able to execute as a Win32 application (loading DLLs, calling into (native/builtin) DLLs).
Well, not really -- that would be ideal, but at the moment a winelib app is an ELF shared library (.so file) which is loaded by wine. That's why we have that startup script for winelib apps...
ooops... did I really write that... looking for some brown paper bag... A+
Eric Pouech wrote:
S17: I would complement "re-implementing" by the fact we translate Win calls into local OS calls (mostly)
Please remeber these are slides that accompanied a two hours lecture. We are reimplementing Win32. We are using "backend" engines for the actual work (as Wine is not an OS). One such backend is Posix X11. Another is ncurses. A third is whatever you would call what ReactOs are using.
S20: I'm a bit confused with "all win32 Dlls are implemented as winelib apps". Firstly, a DLL is not an app. Secondly, from a pure technical point of view, we're talking here of two different things:
- win32 builtin DLLs are implemented as specific ELF shared library.
The PE loader, when loading DLL, is able to load either builtin DLL or windows native DLLs.
- a winelib app, is an ELF executable (not shared library), which is
able to execute as a Win32 application (loading DLLs, calling into (native/builtin) DLLs).
Like Dimi said, a winelib app is an ELF DLL that is capable of executing both Posix and Win32 functions. It cannot load itself, and needs Wine to load it. Wine's builtin DLLs are no different, except they usually don't have a wrapper.
The wording here is perhaps short enough for a generic presentation, but it's IMO rather confusing.
I rather think it's real life that is confusing :-)
as a more generic comment, what about adding a couple of screen shots ? (just to complement on the alpha side of Wine => "it does work in lots of cases")
These slides are part of a lecture. Screenshots pale in comparison to actually loading IE and Word.
anyway, I think it would be good to share those slides (there are already a couple of them on WineHQ) if we want to keep on making this type of presentations to LUG and other events.
That's why I posted them (I wrote them anyways, and someone may find the useful).
Shachar
On Sat, 20 Sep 2003, Shachar Shemesh wrote:
Hi all,
I have placed on my site the slides for a presentation I gave at a local LUG about Wine. The slides are in English, in PDF format. You can get them at http://shemesh.biz/lectures.html
The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time.
I think it would be nice to point to such presentations from WineHQ's 'How to contribute to Wine' page. Maybe something like this would do:
Index: templates/en/contributing.template =================================================================== RCS file: /home/wine/lostwages/templates/en/contributing.template,v retrieving revision 1.15 diff -u -r1.15 contributing.template --- templates/en/contributing.template 9 Sep 2003 14:34:58 -0000 1.15 +++ templates/en/contributing.template 22 Sep 2003 09:41:17 -0000 @@ -362,6 +362,17 @@ <blockquote>
+ <p class="project">Present Wine at your LUG + <p>You can get more people to know about Wine and understand why it is + important by presenting Wine at your LUG. You can use one of the + following presentations as a starting point: + <ul> + <li><a href="http://shemesh.biz/lectures/HaifuxWine.pdf">Wine</a> + by Shachar Shemesh (2003) + <li><a href="http://www.lugod.org/presentations/crossover/">CrossOver + and Wine</a> by Francois Gouget (2002/10/01) + </ul> + <a name="doc"></a> <h3>Documentation writing</h3> <p>Wine is in constant need of documentation updates.
I'm not sure I'd insist as much on how Wine started and the license changes. IMHO it's more important to explain why Wine is important in the global scheme of things because I feel this is often misunderstood. But maybe that's just me and in any case it certainly depends on the audience to some extent.
Some more comments:
* Slide 6
Wine did not start under the X11 license but under the GPL! See Alexandre's WineConf 2002 presentation (slide 8): http://www.codeweavers.com/about/news/talks/wineconf2002/wine-sandiego-mar20...
As was already pointed out, Corel was a big contributor to Wine and really helped it move forward.
s/Transgaming/TransGaming/ s/Cross Over/CrossOver/
* Slide 8
s/Winehq/WineHQ/
* Slide 17
s/dependndancies/dependencies/
* Slide 19
s/dependancies/dependencies/ s/noteable/notable/
* Slide 20
s/each Win32 DLL only depend/each Win32 DLL only depends/ s/seperation/separation/ s/Seperate/Separate/
* Slide 21
s/simulataniously/simultaneously/
* Slide 25
s/Tell sign:/Telltale sign:/ s/acessable/accessible/
* Slide 26
Actually it's the managed mode that tends to cause focus and Z-order problems, partly due to the difference in behavior between all the window managers out there.
* Slide 27
There's no need for a dll override for the MFC since there is no builtin implementation. A better example may be msvcrt or ole32.
s/Other need functions/Other needed functions/
On Mon, 22 Sep 2003, Francois Gouget wrote: [...]
The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time.
Maybe we could also announce such presentations on WineHQ's front page, in the 'news' section... We could start with the one you have next month. When/where is it?
Francois Gouget wrote:
On Mon, 22 Sep 2003, Francois Gouget wrote: [...]
The lecture was given several months ago, but I'm going to repeat it in about a month. If you have any comments, please send them over for inclusion for next time.
Maybe we could also announce such presentations on WineHQ's front page, in the 'news' section... We could start with the one you have next month. When/where is it?
Hi all,
I know i'm replying to a old mail but, Hey I do this sort of thing ;)
I plan to ask if I can do another presentation at our local LUG (wake forest university) on wine. And ive talked to people at the charlotte lug as well about a presentation. I think this kind of info would be usefull in our WWN as well. even if its a short blurb .... so & so will be doing a presentationthe date, time, place....
I made the suggestion some time back that we could use a page with presentation info... And on it add slides, info, facts, just good stuff to help people do "good presentations" Why try to re-invent the wheel 10 times? and as time goes on we can update the info and make sure it stays relatively current...
Any thoughts about this?
Tom
-
Dimitrie O. Paun -
Dmitry Timoshkov -
Eric Pouech -
Francois Gouget -
Marcelo Duarte -
Mike Hearn -
Ove Kaaven -
Shachar Shemesh -
Tom