Re: RFC: Windows NT VDD
admiral coeyman wrote: > David Elliott, > > > > Actually, no. I figured it would be an added bonus assuming there weren't any >other > > major obstacles. The main reason is that it would appear to be the right thing to > > do. There is no reason to continue to use an interface that is almost identical > > when there is a perfectly good interface already defined. I am looking to allow > > interrupts to be implemented as a VDD (.DLL basically) so we can seperate out the > > DOS stuff properly. Also, it would have added benefits like allowing you to right > > an ANSI.VDD (or something like that) much like OS/2 did. That might be another >good > > place to check for documentation. I did grab the OS/2 VDD kit as well for some >more > > background info, it's a tougher read though because IBM tried to do everything > > object oriented (sort of) and even though I like OO programming, I sometimes get > > caught up trying to read descriptions that would just be a lot simpler if they'd go > > out and say it a normal way! > > > Does this change the way that I'll have to write the code for the interrupts > I'm working on? Somebody wanted INT 0x13 and I'm going to do some of 0x10 as > soon as I figure out 8-bit directx. It's meaningless until somebody who knows > how reenables the DOS loader, but I wouldn't like to have people with less free > time than I do wasting effort in this area if we have changes to make. > Doubtful. I don't like doing major work and then releasing it in one huge patch. Especially on a component that will be used by several other modules. I still haven't heard back from Ove in a while though, I want to see what he's done. Supposedly he did fix the dos loader and get it working again, which is the first step towards doing this. > > > Anyway, about implementing this. It would seem that the correct way to do it would > > be to have a program (a modified version of dosmod would probably be the way to > > go) that is a Win32 app that starts a DOS session. We could do away with having to > > pass a CONTEXT86 around everywhere, and instead use a global context. That makes > > implementing all of the get and set register functions pretty trivial. And since > > DOS isn't multithreaded, I don't see any reason for not using a global CONTEXT86 > > structure, I mean, it's kind of global on the processor anyway. > > > This seems to be what we're working towards, anyway. Modularity may allow us > to write plug-in modules for single user OS other than DOS. > Hmmm.. I never even thought about that. How many other single-user x86 OSes are out there though??? Along that lines, one interesting thought I did have was that once Wine gets to a release quality, it would provide a great foundation for "emulating" other operating systems on top of UNIX. For instance, it would be a great foundation for an OS/2 on top of UNIX thing. Of course there are not really that many great OS/2 programs out there (other than Presentation Manager, which I think is the ultimate UI ever made). > > > I am not planning on all of a sudden writing this whole thing in a day and >releasing > > it. The plan is to gradually move to this interface. Any functions that we don't > > need to implement won't be implemented until someone needs the functionality either > > to write a VDD module specifically for Wine, or to use a native one. > > > I'm only getting involved in this discussion to make sure that the new code >I, > and others, write will not need rewrites once DOS support is restored. Absolutely, like I said, no big changes. Nothing should need a big rewrite either, just some small changes, mostly of the search and replace type as things get changed around. -Dave
Re: RFC: Windows NT VDD
David Elliott, > > Actually, no. I figured it would be an added bonus assuming there weren't any other > major obstacles. The main reason is that it would appear to be the right thing to > do. There is no reason to continue to use an interface that is almost identical > when there is a perfectly good interface already defined. I am looking to allow > interrupts to be implemented as a VDD (.DLL basically) so we can seperate out the > DOS stuff properly. Also, it would have added benefits like allowing you to right > an ANSI.VDD (or something like that) much like OS/2 did. That might be another good > place to check for documentation. I did grab the OS/2 VDD kit as well for some more > background info, it's a tougher read though because IBM tried to do everything > object oriented (sort of) and even though I like OO programming, I sometimes get > caught up trying to read descriptions that would just be a lot simpler if they'd go > out and say it a normal way! > Does this change the way that I'll have to write the code for the interrupts I'm working on? Somebody wanted INT 0x13 and I'm going to do some of 0x10 as soon as I figure out 8-bit directx. It's meaningless until somebody who knows how reenables the DOS loader, but I wouldn't like to have people with less free time than I do wasting effort in this area if we have changes to make. > Anyway, about implementing this. It would seem that the correct way to do it would > be to have a program (a modified version of dosmod would probably be the way to > go) that is a Win32 app that starts a DOS session. We could do away with having to > pass a CONTEXT86 around everywhere, and instead use a global context. That makes > implementing all of the get and set register functions pretty trivial. And since > DOS isn't multithreaded, I don't see any reason for not using a global CONTEXT86 > structure, I mean, it's kind of global on the processor anyway. > This seems to be what we're working towards, anyway. Modularity may allow us to write plug-in modules for single user OS other than DOS. > I am not planning on all of a sudden writing this whole thing in a day and releasing > it. The plan is to gradually move to this interface. Any functions that we don't > need to implement won't be implemented until someone needs the functionality either > to write a VDD module specifically for Wine, or to use a native one. > I'm only getting involved in this discussion to make sure that the new code I, and others, write will not need rewrites once DOS support is restored. -Robert 'Admiral' Coeyman -- http://www.corner.net/admiral/ May you live as long as you wish and age but a single day. [Telnet to telnet.corner.net]
Re: modification for supporting DBCS text
Hello. > Actually, Internet Explorer 4 does convert through codepages; it installs > its own Internet-specific codepages, I think. Go into your registry, find > HKEY_CLASSES_ROOT\MIME\Database\Charset\iso-2022 or whatever. The value > "InternetEncoding" is the number of the Windows codepage Internet > Explorer, MS Outlook, MS Exchange, or whatever, uses for that encoding. > Implement that codepage, use it in the X11 driver, and then there'll be no > more hacks. I didn't know about this. Thank you. And implementing these codepages(5) seems to be a good idea for compatibility. But, hacks seem to be required even if implementing these. The ISO-2022 has many state and some escape sequences are used for changing its state. (Since ISO-2022 is a 7bit code, both SBCS and DBCS use the range of 0x20-0x7f.) The X fonts are not considered about this. So, we require hacks even if we implement ISO-2022-JP, ISO-2022-KR, etc. (The hack may be simpler if we use EUC, but converting from EUC to native X codepages is still required.) And, if we implement InternetEncodings, implementing ISO-2022 codepage is another problem... For example(encoding from Shift JIS to ISO-2022-JP), In Shift JIS(codepage932): 41 82 60 42 <- A (Janpanese character A) B In ISO-2022-JP(rfc1468, rfc1554): 41 / 1B 24 42 / 23 41 / 1B 28 42 / 42 <- A (escape sequence) (Japanese character A) (escape sequence) B If we implement this codepage, we requires hack for wine/unicode since ISO-2022 (especially decoding) is too complex and we cannot use a simple table. (UTFs have same problem.) NOTE: If we want to draw this 3 characters in X, we should do following steps. Step 1: set english font and draw 41. Step 2: set JISX0208 font and draw 23 41. Step 3: set english font and draw 42. --- Hidenori Takeshima
Re: RFC: Windows NT VDD
Vassilis Virvilis wrote: > David Elliott wrote: > > > > The page is a little flaky in Netscape, moving the bar between the frames > > usually fixes the problem. > > > > Maybe try going to http://www.microsoft.com/ddk/ddkdocs/win2k/vdd_24px.htm > > instead. Then you can use the back and forward buttons on the page instead of > > the Java crap. Although I'll have to admit, I cheated and am using IE in > > Win4Lin. > > Interesting trick. Last time I checked I was not able to avoid the java > beast. With this starting address you can use wget to download all the > ddkdocs directory in simple grepable HTML. > > > > > Yes actually, that's why I wanted to get some comments before I started. I'd > > like to look at it before it goes in CVS. I am hoping that whatever you did is > > probably just a step closer to going to Windows NT style interface. > > > > Well if you want comments here is one. It doesn't look easy. Seriously > though, AFAIU the difficult part is the VMM and not the VDD stuff. The > VDD stuff looks useful if you want to support native vdds. Do you want > something like that? > > Actually, no. I figured it would be an added bonus assuming there weren't any other major obstacles. The main reason is that it would appear to be the right thing to do. There is no reason to continue to use an interface that is almost identical when there is a perfectly good interface already defined. I am looking to allow interrupts to be implemented as a VDD (.DLL basically) so we can seperate out the DOS stuff properly. Also, it would have added benefits like allowing you to right an ANSI.VDD (or something like that) much like OS/2 did. That might be another good place to check for documentation. I did grab the OS/2 VDD kit as well for some more background info, it's a tougher read though because IBM tried to do everything object oriented (sort of) and even though I like OO programming, I sometimes get caught up trying to read descriptions that would just be a lot simpler if they'd go out and say it a normal way! Anyway, about implementing this. It would seem that the correct way to do it would be to have a program (a modified version of dosmod would probably be the way to go) that is a Win32 app that starts a DOS session. We could do away with having to pass a CONTEXT86 around everywhere, and instead use a global context. That makes implementing all of the get and set register functions pretty trivial. And since DOS isn't multithreaded, I don't see any reason for not using a global CONTEXT86 structure, I mean, it's kind of global on the processor anyway. I am not planning on all of a sudden writing this whole thing in a day and releasing it. The plan is to gradually move to this interface. Any functions that we don't need to implement won't be implemented until someone needs the functionality either to write a VDD module specifically for Wine, or to use a native one. Like I said though, I am not looking to support native VDDs, just to fix the DOS support the right way. -Dave
Re: did anyone else get this?
I think he may have grabbed our emails from comp.emulator.mswindows.wine Dwayne
Re: did anyone else get this?
I got one too. I thought he had just sent one to each author, but I see now we don't include email addresses in AUTHORS. Probably a good thing. Maybe he strained us out of some other list[s] or news. Who knows where people get email addresses for what purpose? I had a letter once from a windows programmer who wanted me to tell him how to work CallProcEx in windose. Lawson On Fri, 30 Jun 2000, Frank Ramsay wrote: > > I'm not sure why I get a copy (and I didn't see wine-devel in the full > headers) > as I only use wine and report bugs when I find them. > > Anyway, someone 'highter up' in the scheme of all things wine should > probably > answer this guy. > > -fjr > > -- Forwarded Message -- > Subject: Wine interview > Date: Fri, 30 Jun 2000 09:54:33 -0400 > From: Peter Wayner <[EMAIL PROTECTED]> > > > Hi-- > > ComputerWorld asked me to do a piece on the Wine project for an > upcoming issue. Would you have a few minutes to spend on the phone? I > would like to ask a few simple questions. > > Thanks > > Peter Wayner > -- > -- > Tune to http://www.wayner.org/books/ffa/ for information on my book > on Free Software. It launches in July 2000. > --- > > -- > Frank J. Ramsay > [EMAIL PROTECTED] > YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
did anyone else get this?
I'm not sure why I get a copy (and I didn't see wine-devel in the full headers) as I only use wine and report bugs when I find them. Anyway, someone 'highter up' in the scheme of all things wine should probably answer this guy. -fjr -- Forwarded Message -- Subject: Wine interview Date: Fri, 30 Jun 2000 09:54:33 -0400 From: Peter Wayner <[EMAIL PROTECTED]> Hi-- ComputerWorld asked me to do a piece on the Wine project for an upcoming issue. Would you have a few minutes to spend on the phone? I would like to ask a few simple questions. Thanks Peter Wayner -- -- Tune to http://www.wayner.org/books/ffa/ for information on my book on Free Software. It launches in July 2000. --- -- Frank J. Ramsay [EMAIL PROTECTED]
builtin control, no windows
Good day! I am trying to use the wine builtin control panel with an essentilly no-windows system. So far, I have worked out I need rundll32.exe and the native shell/shell32. No worry, if I can make it work, I will work on builtins, but now I get the dread message box: trace:text:X11DRV_ExtTextOut hdc=0fd8 df=0002 0,0 L"This file does not have a program associated"..., 44 flags=0 lpDx=(nil) trace:text:X11DRV_ExtTextOut hdc=0fd8 df=0002 0,14 L"with it for performing this action. Create an", 45 flags=0 lpDx=(nil) trace:text:X11DRV_ExtTextOut hdc=0fd8 df=0002 0,28 L"association in My Computer by clicking View"..., 43 flags=0 lpDx=(nil) trace:text:X11DRV_ExtTextOut hdc=0fd8 df=0002 0,42 L"and then clicking Options."..., 26 flags=0 lpDx=(nil) cut to be readible, that is, This file does not have a program associated with it for performing this action. Create an association in My Computer by clicking View and then clicking Options. Can anybody tell me how I can tell what file it is referring to, or how to do what it demands (or trick it into thinking I have) with a no-windows system? The only file it seems interested it is /(None). I don't know what to put in it, so it is empty. For that matter, what action does it think I have asked it to perform? Regards, Lawson ---cut here YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
Re: modification for supporting DBCS text
On Fri, 30 Jun 2000, TAKESHIMA Hidenori wrote: > Hello. > > > Is it really needed to introduce new hacks for DBCS support? > > Wine now have support for code pages including DBCS. > Unfortunately, we should add many hacks, and this hack is > not enough to display DBCS text. > We must handle two fonts for displaying DBCS text. > - SBCS font(ASCII etc. native SBCS in Japanese and Korean. Sorry, I don't know about >Chinese codepages.) > - DBCS font(must be converted to ISO 2022, not the native codepages in Windows but >the codepage used in mail, hypertext, etc.) Actually, Internet Explorer 4 does convert through codepages; it installs its own Internet-specific codepages, I think. Go into your registry, find HKEY_CLASSES_ROOT\MIME\Database\Charset\iso-2022 or whatever. The value "InternetEncoding" is the number of the Windows codepage Internet Explorer, MS Outlook, MS Exchange, or whatever, uses for that encoding. Implement that codepage, use it in the X11 driver, and then there'll be no more hacks.
Wine jobs
If anyone is potentially interested in Wine-related jobs, please let me know. Please specify your location, and, if relocation is an option, any restrictions on location. Or, if you're interested in hiring, feel free to drop me a line. I'll try to put you in touch with people who might be appropriate. There are also wonderful volunteer positions available: * Run the Wine bug database A valuable, important job! And because it's volunteer, you have complete freedom as to how you do it. * Graphic redesign for WineHQ Make pretty stuff which will be seen by hundreds of thousands of people. High profile. * Run the party fund Requires an ongoing committment to partying. If anyone is interested in taking one of these on, let me know. Thank you! doug. [EMAIL PROTECTED]
Re: modification for supporting DBCS text
Hello.
> Is it really needed to introduce new hacks for DBCS support?
> Wine now have support for code pages including DBCS.
Unfortunately, we should add many hacks, and this hack is
not enough to display DBCS text.
We must handle two fonts for displaying DBCS text.
- SBCS font(ASCII etc. native SBCS in Japanese and Korean. Sorry, I don't know about
Chinese codepages.)
- DBCS font(must be converted to ISO 2022, not the native codepages in Windows but the
codepage used in mail, hypertext, etc.)
> > - str2b_dst->byte2 = str[i];
> > - if (IsDBCSLeadByteEx( codepage, str[i] ))
> > + if ( IsDBCSLeadByteEx( codepage, str[i] ) && (str[i+1] != 0) )
> >{
> > - str2b_dst->byte1 = str[i + 1];
> > + str2b_dst->byte1 = str[i];
> > + str2b_dst->byte2 = str[i+1];
> >i++;
> >}
> >else
> > + {
> >str2b_dst->byte1 = 0;
> > + str2b_dst->byte2 = str[i];
> > + }
>
> Is that part of patch is right? If order of bytes for DBCS fonts in X
> is really reverse, then it should be fixed.
This should be right. 'byte1' is the lead byte.
For example, in Japanese application
(NOTE: since this program is for UNIX, the codepage is EUC that is different from
Shift JIS):
if ( is_kanji )
{
char buf[2];
XSetFont(d,gc,fid_kanji); /* JISX0208 (font should be changed) */
buf[0] = p[0] & 0x7f; /* EUC-JP to ISO-2022(JISX0208) */
buf[1] = p[1] & 0x7f;
XDrawString16(d,pxm,gc,x,y,(XChar2b*)buf,1); /* display one char */
}
else
{
XSetFont(d,gc,fid_kana); /* compatible with ASCII (font should be changed) */
XDrawString(d,pxm,gc,x,y,p,1); /* display one char */
}
The codepage EUC(maybe Extended Unix Code?) is same with ISO-2022 except that the bit
of 0x80 is set.(ISO-2022 must be cleared).
---
Hidenori Takeshima
