Hi,
I have it half way done. Run the test program and you can see. Program works in
W2k, XP and Wine. mingw32-gcc -mwindows -Os GetGlyphOutline.c -o ggo.exe
I stopped messing with it two weeks ago, I needed to work on something else.
When testing you can select the alphanumeric character with the keyboard. The
original program had "a" but I changed it to "L" something simple to draw at
first. You will see the problem.
The test program from Dr. Dobb's Journal http://www.ddj.com/184409154?pgno=12
Thanks,
James
Runs and hides~
greatlrd(a)svn.reactos.org wrote:
>Author: greatlrd
>Date: Thu Aug 31 01:17:53 2006
>New Revision: 23826
>
>URL: http://svn.reactos.org/svn/reactos?rev=23826&view=rev
>Log:
>Wrote RtlUshotByteSwap RtlUlongByteSwap and RtlUlonglongByteSwap to asm code.
> but we need a C api for header to linking it right. Put the asm version to i386
>
>
sure there must be away to avoid this double-function-call overhead?
>+.globl _UlongByteSwap
>+
>+.intel_syntax noprefix
>+
>+/* FUNCTIONS ***************************************************************/
>+
>+_UlongByteSwap:
>+ push ebp // save base
>+ mov ebp,esp // move stack to base
>+ mov eax,[ebp+8] // load the ULONG
>+ bswap eax // swap the ULONG
>+ pop ebp // restore the base
>+ ret
>
>
this should work:
_UlongByteSwap:
mov eax,[esp+8] // load the ULONG
bswap eax // swap the ULONG
ret
>+.globl _UlonglongByteSwap
>+
>+.intel_syntax noprefix
>+
>+/* FUNCTIONS ***************************************************************/
>+
>+_UlonglongByteSwap:
>+ push ebp // save base
>+ mov ebp,esp // move stack to base
>+ mov edx,[ebp+8] // load the higher part of ULONGLONG
>+ mov eax,[ebp+12] // load the lower part of ULONGLONG
>+ bswap edx // swap the higher part
>+ bswap eax // swap the lower part
>+ pop ebp // restore the base
>+ ret
>
>
_UlonglongByteSwap:
mov edx,[esp+8] // load the higher part of ULONGLONG
mov eax,[esp+12] // load the lower part of ULONGLONG
bswap edx // swap the higher part
bswap eax // swap the lower part
ret
>+_UshortByteSwap:
>+ push ebp // save base
>+ mov ebp,esp // move stack to base
>+ mov eax,[ebp+8] // load the USHORT
>+ bswap eax // swap the USHORT, xchg is slow so we use bswap with rol
>+ rol eax,16 // make it USHORT
>+ pop ebp // restore the base
>+ ret
>
>
_UshortByteSwap:
mov eax,[esp+8] // load the USHORT
bswap eax // swap the USHORT, xchg is slow so we use bswap with rol
rol eax,16 // make it USHORT
ret
or to save a byte...
_UshortByteSwap:
mov ebx,[esp+8] // load the USHORT
mov al, bh
mov ah, bl
ret
Well, the reason I ask is that i am also maintaining a defrag utility.
It currently does FAT12, FAT16, FAT32. But it would most likely not be so difficult to change it so that it can use the reactos calls for manipulating the file system. So it also works with NTFS.
It has a lot more functionality then is available in windows defrag. Like sorting directories, which I think is not possible in windows. And 5 methods of defragmenting drives.
A new interface should also be easy to add. There have always been two interfaces. So the all the file system manipulation code is completely seperate.
The defragmentation code already works in windows xp, on image files, because that is how i debug it with visual C++ 7.1.
So, you can tell me wether this would be of interest to reactos.
Imre
>-----Original Message-----
>From: Imre Leber [mailto:imre.leber@telenet.be]
>Sent: Thursday, August 31, 2006 10:24 AM
>To: ros-dev(a)reactos.org
>Subject: [ros-dev] scope?
>
>What is actually the scope of the reactos project?
>
>Just being able to run windows drivers and apps, or "everything that was on the CD" (like FreeDOS)?
>
>Imre
>
>
>
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
What is actually the scope of the reactos project?
Just being able to run windows drivers and apps, or "everything that was on the CD" (like FreeDOS)?
Imre
>-----Original Message-----
>From: Myria [mailto:myriachan@cox.net]
>Sent: Tuesday, August 29, 2006 10:14 AM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] (Free)DOS subsystem
>
>I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever
>have time.
>
>Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top
>of Win32. It runs DOS programs as Windows processes, using v86 mode to run
>the programs. DPMI programs are supported by asking the kernel to allocate
>LDT segments and running directly. (If you write a DOS32 program and know
>the correct addresses, you can call MessageBoxW in user32.dll and it will
>work.)
>
>This differs significantly from DOSBox, which is effectively a machine
>emulator rather than an API translator. DOSEmu, in comparison, is
>essentially the same design as NTVDM but for Linux.
>
>FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal
>self and is unaware that it's inside a VM. However, this doesn't work for
>NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily
>modified, particularly because the NT kernel handles file I/O. Programs
>inside the virtual DOS environment use illegal opcodes to talk to NTVDM.
>
FreeDOS works just fine in DOSemu. Actually that is how it got debugged by the kernel maintainer who was also the DOSemu maintainer. But no code of FreeDOS is actually special for DOSemu.
The invalid opcode handler is probably similar to int e6 in DOSemu. It is an extra API by which DOS software can use services of DOSemu.
What probably is needed is an implementation of the int 21 interface, and maybe others, in the V86 monitor.
For what I understood from reading a litle on the web is that it more or less works like this:
You have v86 code in the kernel. This can be mapped using memory paging to point to a certain address, where a DOS program is loaded.
When an interupt occurs, the V86 mode is exited (the only way a V86 task can be exited) and the V86 monitor, in this case ntvdm takes over. This looks at the state of the interrupt and acts upon this. For example when calling an int 16 function it may return the status of a key. After the interrupt has been serviced the registers are loaded with the right values, or memory is filled correctly, or something like that and the v86 task is allowed to run until the next interrupt. Of course the software APIs can also be serviced by the V86 monitor and this is probably what is done in windows.
ntvdm is special in that, unlike DOSemu, it serves as the V86 monitor for all the V86 tasks running in the session.
Imre
>Melissa
>
>----- Original Message -----
>From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
>To: "ReactOS Development List" <ros-dev(a)reactos.org>
>Sent: Monday, August 28, 2006 14:19
>Subject: Re: [ros-dev] (Free)DOS subsystem
>
>
>> Imre Leber wrote:
>>> Hi,
>>>
>>> I guess i am new to this list.
>>>
>>> I have been a maintainer on the FreeDOS project for more then 7 years.
>>>
>>> I have also noticed that you are still looking into building a DOS
>>> subsystem in reactos.
>>>
>>> After the release of FreeDOS version 1, I would like to see wether I
>>> could not take up the task to having it running under reactos.
>>>
>>> My main idea involves using a port of DOSemu.
>>>
>>> Is there any documentation regarding the running of a DOS subsystem in
>>> windows that I should study beforehand?
>>>
>>> Imre
>>>
>>>
>> Hi Imre!
>> Welcome to ReactOS! 8^D
>>
>> The idea is still open.
>>
>> We've tested Qemu under ReactOS running FreeDOS at one time and it does
>> work. Another project that
>> was tested, DOSBox, it works like DOSemu, http://dosbox.sourceforge.net/
>>
>>
>> Running a dos-subsystem and docs? Maybe one of the other developers can
>> help here. You can look at
>> the OS2 subsystem at http://svn.reactos.ru/svn/reactos/trunk/os2/ , it's
>> incomplete, this would be
>> your best starting point. There is allot more to it. You need to dive into
>> the code and start
>> reading. I do not recall any docs or books dealing with rolling your own
>> subsystem. The best book
>> you can get for understanding Windows or ReactOS is, Windows Internals.
>> Understanding the Csrss
>> subsystem would help with the os2 one.
>>
>> Anyway, some projects that could be good examples on how to do this, Posix
>> subsystem,
>> http://sourceforge.net/projects/winntposix ,and running linux bins in
>> windows,
>> http://sourceforge.net/projects/keow . One of our developers is currently
>> working with CoLinux,
>> http://www.colinux.org/ .
>>
>> Sorry I couldn't help you more here.
>>
>> Thanks,
>> James
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
DOSemu has a 80386 emulator on board.
Or at least in the sources. It doesn't seem to be in the DOSemu documentation so it seems that it is non-functional.
But it is always easier to fix something then to restart from scratch.
Imre
>-----Original Message-----
>From: Nate DeSimone [mailto:desimn@rpi.edu]
>Sent: Wednesday, August 30, 2006 01:21 AM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] (Free)DOS subsystem
>
>Not that I'm trying to rain on anyones parade, but it would be really
>cool if for each program you could choose to run it in either an
>emulation environment or in a V86 mode (ala WinNT NTVDM.EXE,) that way
>older DOS games could be used.
>
>Imre Leber wrote:
>>> -----Original Message-----
>>> From: Myria [mailto:myriachan@cox.net]
>>> Sent: Tuesday, August 29, 2006 10:14 AM
>>> To: 'ReactOS Development List'
>>> Subject: Re: [ros-dev] (Free)DOS subsystem
>>>
>>> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever
>>> have time.
>>>
>>> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top
>>> of Win32. It runs DOS programs as Windows processes, using v86 mode to run
>>> the programs. DPMI programs are supported by asking the kernel to allocate
>>> LDT segments and running directly. (If you write a DOS32 program and know
>>> the correct addresses, you can call MessageBoxW in user32.dll and it will
>>> work.)
>>>
>>> This differs significantly from DOSBox, which is effectively a machine
>>> emulator rather than an API translator. DOSEmu, in comparison, is
>>> essentially the same design as NTVDM but for Linux.
>>>
>>> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal
>>> self and is unaware that it's inside a VM. However, this doesn't work for
>>> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily
>>> modified, particularly because the NT kernel handles file I/O. Programs
>>> inside the virtual DOS environment use illegal opcodes to talk to NTVDM.
>>>
>>>
>>
>> FreeDOS works just fine in DOSemu. Actually that is how it got debugged by the kernel maintainer who was also the DOSemu maintainer. But no code of FreeDOS is actually special for DOSemu.
>>
>> The invalid opcode handler is probably similar to int e6 in DOSemu. It is an extra API by which DOS software can use services of DOSemu.
>>
>> What probably is needed is an implementation of the int 21 interface, and maybe others, in the V86 monitor.
>>
>> For what I understood from reading a litle on the web is that it more or less works like this:
>>
>> You have v86 code in the kernel. This can be mapped using memory paging to point to a certain address, where a DOS program is loaded.
>>
>> When an interupt occurs, the V86 mode is exited (the only way a V86 task can be exited) and the V86 monitor, in this case ntvdm takes over. This looks at the state of the interrupt and acts upon this. For example when calling an int 16 function it may return the status of a key. After the interrupt has been serviced the registers are loaded with the right values, or memory is filled correctly, or something like that and the v86 task is allowed to run until the next interrupt. Of course the software APIs can also be serviced by the V86 monitor and this is probably what is done in windows.
>>
>> ntvdm is special in that, unlike DOSemu, it serves as the V86 monitor for all the V86 tasks running in the session.
>>
>> Imre
>>
>>
>>
>>
>>> Melissa
>>>
>>> ----- Original Message -----
>>> From: "James Tabor" <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
>>> To: "ReactOS Development List" <ros-dev(a)reactos.org>
>>> Sent: Monday, August 28, 2006 14:19
>>> Subject: Re: [ros-dev] (Free)DOS subsystem
>>>
>>>
>>>
>>>> Imre Leber wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I guess i am new to this list.
>>>>>
>>>>> I have been a maintainer on the FreeDOS project for more then 7 years.
>>>>>
>>>>> I have also noticed that you are still looking into building a DOS
>>>>> subsystem in reactos.
>>>>>
>>>>> After the release of FreeDOS version 1, I would like to see wether I
>>>>> could not take up the task to having it running under reactos.
>>>>>
>>>>> My main idea involves using a port of DOSemu.
>>>>>
>>>>> Is there any documentation regarding the running of a DOS subsystem in
>>>>> windows that I should study beforehand?
>>>>>
>>>>> Imre
>>>>>
>>>>>
>>>>>
>>>> Hi Imre!
>>>> Welcome to ReactOS! 8^D
>>>>
>>>> The idea is still open.
>>>>
>>>> We've tested Qemu under ReactOS running FreeDOS at one time and it does
>>>> work. Another project that
>>>> was tested, DOSBox, it works like DOSemu, http://dosbox.sourceforge.net/
>>>>
>>>>
>>>> Running a dos-subsystem and docs? Maybe one of the other developers can
>>>> help here. You can look at
>>>> the OS2 subsystem at http://svn.reactos.ru/svn/reactos/trunk/os2/ , it's
>>>> incomplete, this would be
>>>> your best starting point. There is allot more to it. You need to dive into
>>>> the code and start
>>>> reading. I do not recall any docs or books dealing with rolling your own
>>>> subsystem. The best book
>>>> you can get for understanding Windows or ReactOS is, Windows Internals.
>>>> Understanding the Csrss
>>>> subsystem would help with the os2 one.
>>>>
>>>> Anyway, some projects that could be good examples on how to do this, Posix
>>>> subsystem,
>>>> http://sourceforge.net/projects/winntposix ,and running linux bins in
>>>> windows,
>>>> http://sourceforge.net/projects/keow . One of our developers is currently
>>>> working with CoLinux,
>>>> http://www.colinux.org/ .
>>>>
>>>> Sorry I couldn't help you more here.
>>>>
>>>> Thanks,
>>>> James
>>>>
>>>> _______________________________________________
>>>> Ros-dev mailing list
>>>> Ros-dev(a)reactos.org
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>>
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev(a)reactos.org
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>>
>>
>
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
So, if nobody objects I guess i'll start porting DOSemu to reactos.
After all, we need to start somewhere. And when this is done, it would be easier to talk about why it is or it is not a good replacement for ntvdm.
Imre
>-----Original Message-----
>From: Sylvain Petreolle [mailto:spetreolle@yahoo.fr]
>Sent: Wednesday, August 30, 2006 10:54 AM
>To: 'ReactOS Development List'
>Subject: [ros-dev] RE : Re: (Free)DOS subsystem
>
>Hi,
>--- Imre Leber <imre.leber(a)telenet.be> a écrit :
>
>>
>> DOSemu has a 80386 emulator on board.
>>
>> Or at least in the sources. It doesn't seem to be in the DOSemu documentation so it seems that
>> it is non-functional.
>>
>> But it is always easier to fix something then to restart from scratch.
>>
>Like e.g. Windows ? Bad answer ;)
>
Windows??? Can you point me to the official download area?
Imre
>Kind regards,
>Sylvain Petreolle (aka Usurp)
>--- --- --- --- --- --- --- --- --- --- --- --- ---
>
> Run your favorite Windows apps with free ReactOS : http://www.reactos.org
>Listen to non-DRMised Music: http://www.jamendo.com
>
>
>Linux is not as well stable as it is told to. The proof is, mine has restarted two years ago, on the occasion of a power cut.
>- H. Eychenne
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
Hi,
I guess i am new to this list.
I have been a maintainer on the FreeDOS project for more then 7 years.
I have also noticed that you are still looking into building a DOS subsystem in reactos.
After the release of FreeDOS version 1, I would like to see wether I could not take up the task to having it running under reactos.
My main idea involves using a port of DOSemu.
Is there any documentation regarding the running of a DOS subsystem in windows that I should study beforehand?
Imre
>-----Original Message-----
>From: Imre Leber [mailto:imre.leber@telenet.be]
>Sent: Tuesday, August 29, 2006 02:57 PM
>To: 'ReactOS Development List'
>Subject: Re: [ros-dev] (Free)DOS subsystem
>
>
>>-----Original Message-----
>>From: Peter Dolding [mailto:oiaohm@bluebottle.com]
>>Sent: Tuesday, August 29, 2006 01:33 PM
>>To: 'ReactOS Development List'
>>Subject: Re: [ros-dev] (Free)DOS subsystem
>>
>>Myria wrote:
>>> I've wanted to write an NTVDM for ReactOS, but I'm not sure when I'd ever
>>> have time.
>>>
>>> Windows NT's DOS subsystem, NTVDM, is a user-mode program that runs on top
>>> of Win32. It runs DOS programs as Windows processes, using v86 mode to run
>>> the programs. DPMI programs are supported by asking the kernel to allocate
>>> LDT segments and running directly. (If you write a DOS32 program and know
>>> the correct addresses, you can call MessageBoxW in user32.dll and it will
>>> work.)
>>>
>>> This differs significantly from DOSBox, which is effectively a machine
>>> emulator rather than an API translator. DOSEmu, in comparison, is
>>> essentially the same design as NTVDM but for Linux.
>>>
>>> FreeDOS in DOSBox works very well, because the FreeDOS kernel is its normal
>>> self and is unaware that it's inside a VM. However, this doesn't work for
>>> NTVDM/DOSEmu. In these, the FreeDOS kernel will need to be heavily
>>> modified, particularly because the NT kernel handles file I/O. Programs
>>> inside the virtual DOS environment use illegal opcodes to talk to NTVDM.
>>>
>>> Melissa
>>>
>>True Closest Freedos to Windows NT NTVDM is
>>http://freedos-32.sourceforge.net/. Its was newer version under
>>development. It could be stalled from 2005.
>>
>
>Why?
>
>I never got it. It doesn't seem to add anything new. Nothing that can't be done in FreeDOS.
>
>FreeDOS is for all pratical purposes a capable 32 bit system. It can run 32 bit DOS and (some) windows programs and it has multithreading (eRTOS), TCP/IP (watt32), etc... .
>
Well. Maybe I should have said a 32 bit capable operating system.
>I think it would not be very difficult to write a multitasking DOS extender either (maybe as an extension to cwsdpr0).
>
But who's ever going to care?
>If it's because it is running in 32 bit, I am not all that convinced that DOS-C can not be ported to 32 bit. It was originally intended to run on apple macintosh.
>
>Imre
Imre
>
>>Peter Dolding
>>
>>_______________________________________________
>>Ros-dev mailing list
>>Ros-dev(a)reactos.org
>>http://www.reactos.org/mailman/listinfo/ros-dev
>>
>>
>
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.org
>http://www.reactos.org/mailman/listinfo/ros-dev
>
>
