                                   WexT
                            Dos-Extender package
                                    by
                           Jonas Lund aka Whizzter
******************************************************************************
 Copyright (C) 1998 Jonas Lund, All Rights Reserved.
******************************************************************************

1.0-Table of Contents:
----------------------
1.0-Table of Contents
2.0-Information
 2.1-What is this?
 2.2-Legal
 2.3-Contact
 2.4-History
 2.5-What's new
 2.6-Something to say!
 2.7-Helpers so far
3.0-Usage Information
 3.1-Starting
 3.2-Getting started
 3.3-Serious pmode coding
 3.4-Using with Watcom C
 3.5-System calls and Dos32 compability
 3.6-Extended dos calls
4.0-Included Programs
 4.1-wextfix.exe
 4.2-50lines.com
 4.3-wextd.exe
 4.4-wextw.exe
5.0-About exepackers
 5.1-The real REASON for using WexT
 5.2-Various packers

2.0 - Information
----------------------
2.1 - What is this?
 Dos extenders gives you access to the whole memory on any 386+ computer.
 This extender will probably not be the best for beginners on Pmode coding,
 i suggest that you get the dos32 package if you want to LEARN Pmode!
 This extender has Dos32 compability but is not 100% compitable, because
 it has the things i wanted from Dos32 and not any other.
 dos32 is a GREAT extender, but has a few drawbacks for being usable for intros.

 in the last version of this doc i wrote that if there is enuff interest i
 might add extended filefunctions,dpmi/vcpi support and dos32 support,
 because of the big interest(and the fact that i prefer to code under windows)
 i added dpmi support, because i already had a dos32 loader i fixed it up
 and now it is included,then when i had the dos32 loader i just noticed how
 simply i could get my old demos running with wext(and they do work!) if i
 added extended filefunctions, then when i heard about STRANGE trouble using
 watcom(this is due to the fact that neither borland or watcom sticks to the
   standards!), i added a watcom loader and that wasn't even on the
 improvement list. the only thing left from that list is vcpi and it will
 be added soon due to the fact that dreamhack will use himem+emm386 so i am
 forced to add it due to the number of people doing intros to dh with wext.
 anyway, if you feel that i have been lazy because it was 2-4 months since the
 last release you should think over that a bit! i do ALOT for all of you! :)

 the newest/best version should always be available at the homepage.
 http://woorlic.home.ml.org

2.2 - Legal
------------------------------------------------------------------------------
 I (Jonas Lund) declare that i am in no way responsible for any damage
 caused by this software, when you use this software it is on your own
 risk.
 This software is also free for any non-commercial usage.
 But if you plan to make money on software using this you MUST contact me first.
------------------------------------------------------------------------------
 phew, the feared legal crap is over. :)

 (Mail me if you think i forgot something)

2.3 - Contact
 Email:    whizzter@usa.net         (this should not change)
           whizzter@enjoy.joint.net (this is my mailbox so if usa.net is down mail here)

 WWW:   http://woorlic.home.ml.org (as long as ml.org will keep up their work we'll be there)
 Mail:  Jonas Lund
        Kukkola 166
        95391 Haparanda
        SWEDEN
 Phone: (+46)-(0)922-31113

2.4 - History
 The WexT dos extender is something that i wrote because i wanted to do intros
 (For those who doesn't know what a intro or demo is i'll describe it later)
 anyway i found this great player called USMP (Hi FreddyV) and used it for
 some demos, in the same time i thought about a intro, but there was some
 things grabbing space inside those 64k's.
 1:My favourite extender Dos32 and most others, are overlayed and because
    of that i can't use any external packers, only the included, and those
    are NOT so good.
 2:there is 1 extender supported by USMP that is non-Overlayed, named
    EOS, but the source code is not included and the eos extender is quite
    big, TOO big, about 10k and that is valuable space for intro creators.
 I could have started mucking inside USMP and made it PMODE compitable
 (PMODE is an older extender) but i knew FreddyV would release new versions
 of USMP, also i was quite interested in writing my own extender.
 so i decided to a partly Dos32 compitable,NON-Overlayed extender.

 when i finished the extender i decided to do some Watcom C libs and a
 mxmplay example, these seems to work fine now so i'm releasing them along.

 ps:
  if you didn't already noticed i added optional stubloaders with version 1.1x

 btw. i started on the first code for the extender on the 31/12-1997 =)
      i'm gonna love the 2'nd birthday of it ;)

: Words :
Demo  - A show of effects with Music and Graphics, Described as a Music Video
         by some peoples.

Intro - Like a demo but can't be bigger than 64k on the disk.

2.5 - What's new
  in v1.10b is a MAJOR update
   - DPMI support, yep.. nearly as small and now works in windows
   - largely rewritten C/C++ libs..
      - no more stack calling!
      - new and delete support included
      - now wlink is used so there is no more borlandVSwatcom hassle
   - Removed dos32 support in the clibs because:
      - dlink does some really stupid stuff
      - dos32 is not needed now when wext works under dpmi
          (win and emm386 with cwsdpmi or some other dpmi provider installed)
   - added 2 stubloaders
  in v1.03 has fixes+examples
   - HUGE bugfix, i accidently set SP instead of ESP at one place
     so if the esp(stack pointer) was > 64k then it'll hang
   - highcolor lib, works with wext/dos32 and asm/watcom C
     i included it because people had problems using vesa
  in v1.02 i fixed/added the following things (unofficial)
   - Fixed the header files so now compiling with wpp386 is ok
   - Fixed the stdlibs, the BSS did not group with the others earlier but
     now they do. (caused crashes with un-initalized data)
   - Fixed so that the watcom STDLIBS works with dos32
   - Added usmplay examples
   - more examples!
  1.01b was just a tiny service release
   - some minor doc changes
   - added .startup to the krnl file so that newer tlink versions will
      know where to start
  1.0b initial release

2.6 - Something to say!
 There is a few things i want to get public that is irritating me,i would be
 grateful if you read this because i belive most coders that has knowledge
 enough in different areas to be contacted for help is irritated by some of
 these things, and i KNOW.
 I like comments on this if you feel like giving them!

 Note: (i don't think that i am the best coder ever or something so i don't
        want any angry mail complaining on that)

 1: WHY does some peoples say 32bit-POWER in their extender descriptions?
     I personally find it very irritating, because of the fact that you can
     have 32bit opcodes in realmode and it is possible to gain 32-bit
     addressing in Real-Flat mode, so saying 32bit-POWER is very stupid
     don't make the same misstake yourself someday, OK?
     IF you find this statement wrong then contact me and we'll discuss,OK?
 2: WHY is people asking for source code? sure you can learn from it, IF it is
     well written but when it is not, it is just confusing. so if you ask
     someone for the source and he says he that it is crap, then you can most
     of the time belive him. AND you SHOULD stop buggering the person for it
     because you will probably not learn anything from it, Ask nicely from
     where he learn't it and how, that will probably help you more!
 3: One thing that is buggering me is that some people when wanting something
     is always trying to hurrying you up, i mean i am doing them a FAVOUR so
     they should be grateful and wait, but NO, some peoples still just bug you
     to do it for them directly, CALM down! i am doing it for you and WAIT.
     and if you cannot wait then let it be, you don't need my code, you will
     probably not even have time to use the things i gave, so why give?
     well i am a kind person. and i like to stay that way, and i hope that i
     will not become to bothered by these peoples to become any other type!
     1 person that i know for sure has been changed is Pulse
     (The impulse tracker coder..), he wrote in a letter that he will just
     turn his back on MOST Impulse Tracker related things because,
     He is sick of it!
 4: I suck so badly at coding, ok now that is dealt with! :)
 5: this stuff applies to real life a bit also...!

2.7 - Helpers so far

 ??/8-1998 - After the new and delete orgies i gave brainpow the new libs to
             try, now we found out some STRANGE stuff that watcom does.
             we simplified hopefully without doing any damage to the operation
             of code the things done. mostly by dummying.
             so i will have to hand !BIIG! thanks to brainpow for helping me
             to root out all evil watcom stuff.
 ??/8-1998 - Brainpow,HB and dictoon gave some headfiles that overloaded
             new[] and delete[] to use malloc/free, but including headers
             for something essential is not my idea of good support.
             i looked thru and stubled on some standard c++ libs from borland
             that was just sitting on my programmers heaven cd, after i looked
             there i noticed that you can put the operator stuff into a separate
             file and it will work.
 20/5-1998 - Euler discovered that krnl.obj doesn't link to well with some
             tlink version, after a peek i figured out what to do about it
             now it should work. thanks!
 25/5-1998 - i got a mail from Sagacity/Quad and he described the problems
             when linking to programs generated with wpp386, i quickly could
             trace it down to the Header files where i had totally forgot
             to define the functions as "C" functions, now fixed in v1.02
             another thing sagacity mailed about was a really STUPID miss
             i made in the startup headers, i grouped in a stupid way so
             the BSS segment (uninitialized data) was not aligned, and that
             crashed it all, now fixed.
 08/6-1998 - when i was at abduction(5-7/6) i was going to show a watcom
             example with usmplay to droid^haujobb and i noticed the killer
             bug, thanks for getting me the chance to show off :)
             (this bug must have gone thru when i did the dos32 compability)
 08/6-1998 - Shock^xtatic complained about the symbol __CHP not being there,
             i remeber that i somehow didn't need to add it but i didn't
             remeber how to disable it so i added a dumb function called __CHP


3.0 - Usage Information
-----------------------
3.1 - Starting
 First of all you need to WEXT environment variable to be set for wlink to
 find the libs.
 just set wext to point to the rootdir(the one containing /doc,/bin etc.)
 of wext, for example:
 set wext=c:\code\dosextenders\wext  (remember, no trailing slash)
 (if you use wext alot put this into autoexec.bat)

 If you are starting on Pmode coding then i suggest that you get the
 Dos32 package, it is simple and there is many things simplified in it.
 (as of v1.1x i included a stubloader that can be used instead of dos32 but
  you still link with dos32)
 This extender is linked into the EXE file in a "normal"  way so it has
 many things that is harder, and is not so well suited for beginners.
 When you have some Experience with Dos32 you can look at this package,
 Although you will probably not care because this extender is aimed for
 Intros (Explanation futher down).
 If you know pmode coding then the next parts will get you started in notime
 (i HOPE :)
 If you are doing a intro,like dos32 and know why Overlayed exe's suck,then
 i hope you will LOVE mine, because it is aimed at you(and myself:).

3.2 - Getting started
 First it is a BIG adventage if you have TASM and TLINK, otherwise you will have to
 do some pretty heavy porting job on your hands. :)
 (If some1 wants to move the extender to some other
 assembler/compiler/linker then contact me, but i will try to do that myself)
 Well first do a program file that has a Public, CODE32 segment that has
 wordsize set to 32bit and a starting label called START32
 (make sure it is public or else the linking will fail)
 here is a example how to do that.
----- Cut -----------------------------------------------------------------
 .386p

 public START32      ; This is made so that the extender will find the label

 CODE32 segment PUBLIC USE32 'CODE'
 assume CS:CODE32,DS:CODE32,ES:CODE32,FS:CODE32,GS:CODE32

 START32:            ; Starting point of program
  mov ax,4c00h       ; Dos Exit code (Yes it works in pmode :)
  int 21h            ; Call to interrupt 21h
                     ; Partly handled by the extender but mostly redirected
                     ; to realmode!

 CODE32 ends
 END
----- Cut -----------------------------------------------------------------
 Assemble this into test.obj...

  C:\Tasm test.asm

 Then you only link it with the extender...

  C:\Tlink /3 krnl.obj test.obj,test.exe

 And there we have test.exe, but before we run it we must fix so that
  there is no useless allocation so we run wextfix.exe.

  C:\wextfix test.exe

 Now we have a executable that is ready to run!

3.3 - Serious pmode coding
 I will not go into Protected mode coding in this document, if i choose to
 write anything about it you will find a document in this directory.
 update at 1.1x: i asked till gerken and he might do a new version
                  of his CLASSIC pmode tutor just for little me and you!

3.4 - Using with Watcom C
 All information regarding usage with Watcom C is moved into watcomc.txt

3.5 - System calls and Dos32 compability
 As i wrote in the history this extender is Dos32 compitable so i can use
 my own old code and others Dos32 based code/libs.
 Although i want Dos32 compability i also need a small extender, so the
 Dos32 compability is not 100%, i am considering making a 100% compitable
 "Fullsize" version and have a smaller version also available. but that is a
 later issue. Live and see. :)

 Note: All non-dos32 specific functions are redirected to realmode,
       for 2 reasons, it is the simplest way and dos32 does this also.
       Except for the ones in Int 31h at the moment, the non used are just
       ignored, Might change when i start in DPMI.

 Calls that are Dos32 compitable at this moment:
 ---------------------------------------------------------------------------
 Int 31h - Function EE42h - Allocate memory
  In:
   AX=EE42h
   EDX=Size of block to allocate
  Out:
   EAX=Actual size allocated
   EDX=Offset to block

   If the actual memory allocated is less than the size requested then
    the carry flag is set, if not then carry is not set. Like dos32 does!
    another thing is that the memory to be allocated is always rounded up
    to the nearest 4k boundary. so if you request 64000 bytes then you
    will get 65536 bytes.
 ---------------------------------------------------------------------------
 Int 31h - Function EE41h - Allocate 16kb DMA block
  In:
   AX=EE41h
  Out:
   EBX=Pointer in Physical memory
   EDX=Near Pointer in program segment

   Carryflag is always clear, Sucessfull or not.
 ---------------------------------------------------------------------------
 Int 31h - Function EE40h - Free last allocated memory
  In:
   AX=EE40h
  Out:
   Carry Flag=Clear, Function successful in dos32 emulated..

  Note: i don't expect this function to generate TOO many errors so i don't
          report errors! :)
 ---------------------------------------------------------------------------
 Int 31h - Function EE00h - Get version and segment information
  In:
   AX=EE00h
  Out:
   DL=1                   Telling that the system is rawDOS
   BX=Zero base selector  4gb segment starting at the absolute 0
   AX=0301h               version 3.1 or sumthing, dunno but this should
                          satisfy most ppl's :>
 ---------------------------------------------------------------------------
 Int 31h - Function EE02h - Get various addresses
  In:
   AX=EE02h
  Out:
   EBX=Linear address of program segment
   ESI=Offset of PSP
   EDI=Offset of Environment block
   ECX=ignore (This SHOULD for dos32 compability be a offset to the exe name
              but i didn't feel like i would need it so i didn't implement it)
   EDX=ignore (This SHOULD be the EXE size.. not implemented either)
   AX =The segment of the realmode transfer buffer
 ---------------------------------------------------------------------------
 Int 31h - Function 204h - Get interrupt address
  In:
   AX=204h
   BL=Interrupt number
  Out:
   CX:EDX=Pointer to interrupt handler (Selector:Offset)
 ---------------------------------------------------------------------------
 Int 31h - Function 205h - Set interrupt address
  In:
   AX=205h
   BL=Interrupt number
   CX:EDX=Pointer to interrupt handler (Selector:Offset)
  Out:
   (Nothing)
 ---------------------------------------------------------------------------
 Int 31h - Function 300h - Simulate Realmode Interrupt
  In:
   AX=300h
   BL=Interrupt number
   BH=0   (Dos32 has a flag in this so we better just keep this 0)
   CX=0   (Also used in dos32 but not here)
   ES:EDI=Pointer to realmode call struct
  Out:
   ES:EDI=Pointer to the same structure (modified)
   Carryflag clear

 Realmode Call structure:

   Offset:      Value:
     00h         Edi
     04h         Esi
     08h         Ebp
     0Ch         Esp (Although Ignored)
     10h         Ebx
     14h         Edx
     18h         Ecx
     1Ch         Eax
     20h         Flags (I cannot remeber if these are ignored any more :)
     22h         ES
     24h         DS
     26h         FS
     28h         GS
     2Ah         IP (Ignored)
     2Ch         CS (Ignored)
     2Eh         SP (Ignored)
     30h         SS (Ignored)
 ---------------------------------------------------------------------------
 Int 31h - Function 800h - Map physical memory
  In:
   AX=800h
   BX:CX=Physical address
   SI:DI=Size of area to map
  Out:
   BX:CX=Linear address

 Note:
  only use this for memory that lies > 1 meg, all mem < 1 meg will always
  be in place anyway.
 ---------------------------------------------------------------------------
 Int 21h - Function 09h - Write '$' Terminated string.
  In:
   AH=09h
   DS:EDX=Pointer to string
  Out:
   (Nothing)

  Note:
   max lenght of the string is 8k, but it should be enuff because one 80x50
   screen is 4k!
 ---------------------------------------------------------------------------
 Int 21h - Function 4Ch - Exit program
  In:
   AH=4Ch
   AL=Exit code (ignored at the moment)
  Out:
   (as you can guess, NOTHING :)

3.6 - Extended dos calls

 many dosextenders(among them dos32,pmode/w,dos4gw) usually extends the old
 dos calls to be used in a easy way from protected mode.
 wext does not support these by standard but when i added loaders i got the
 chance to add functions because the size of the loaders is not anything that
 matters.
 note that i did not add all functions, but if you need any more functions
 then you can modify the file that holds the extended dos calls.
 (%wext%\src\load\general\extdos.asm)

 ---------------------------------------------------------------------------
 Int 21h - Function 39h - Create dir
  In:
   AH=39h
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=destroyed
   CF=Set on error
    AX=Error code
 
 ---------------------------------------------------------------------------
 Int 21h - Function 3Ah - Remove dir
  In:
   AH=3Ah
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=destroyed
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 3Bh - Change dir
  In:
   AH=3Bh
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=destroyed
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 3Ch - Create file
  In:
   AH=3Ch
   CX=file attribs
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=destroyed
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 3Dh - Create file
  In:
   AH=3Dh
   AL=Sharing modes
   CL=file attribs for server call
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=destroyed
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 3Fh - Read from file
  In:
   AH=3Fh
   BX=file handle
   ECX=bytes to read
   DS:EDX=Pointer to data
  Out:
   CF=Clear on success
    EAX=bytes read
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 40h - Write to file
  In:
   AH=40h
   BX=file handle
   ECX=bytes to write
   DS:EDX=Pointer to data
  Out:
   CF=Clear on success
    EAX=bytes written
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 41h - Delete file
  In:
   AH=41h
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=destroyed
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 42h - Seek in open file
  In:
   AH=42h
   AL=Start of seek
       0 = start of file
       1 = from current position
       2 = from end of file
   BX=file handle
   EDX=offset of seek(seen from the start of the seek)
  Out:
   CF=Clear on success
    EAX=new position in file
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 4300h - Get file attribs
  In:
   AX=4300h
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    CX=File attribs
    AX=destroyed
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 4301h - Set file attribs
  In:
   AX=4301h
   CX=new file attribs
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=destroyed
    CX=destroyed
   CF=Set on error
    AX=Error code

 ---------------------------------------------------------------------------
 Int 21h - Function 5Bh - Create new file
  In:
   AH=5Bh
   CX=file attribs
   DS:EDX=Pointer to name
  Out:
   CF=Clear on success
    AX=Filehandle
   CF=Set on error
    AX=Error code


4.0 - Included programs
-----------------------

4.1 - wextfix.exe
-----------------------
 This program is a rude way to solve a problem i couldn't fix any other way.
 If you know how to fix this problem then i would appreciate a mail from YOU!
 Technichal Info:
  The problem lies in the fact that linkers usually set the Max allocation to
  FFFFh so dos allocates ALL free memory for your program.. this is fine but
  this way we can't alloc all free memory ourselves. and for DMA buffers it is
  needed to do this.
  this simple program modifies the exeheader to allocate minalloc+1 Paragraphs
  of memory, this way the stack will be ok and we can still get that bloody dma
  buffer.

 Usage:
  wextfix execname.exe

 Example:
  wextfix heythere.exe
 NOTE: you MUST include the WHOLE filename, this is because the program is really
        simple.(yes i am a lazy bum :)
 Second NOTE: this programs uses dos32 v3.3 by Adam Seychell
               (because of the fact that my extender doesn't have filefuncs)
               All the Proper greets etc should go to him for his great extender.

4.2 - 50lines.com
-----------------------
 I personally LOVE using 80x50 modes when coding, just because you can see
  SOOO much more than with 80x25, so i included this little program that sets
  80x50 mode, put in your autoexec.bat or whatever you want to.

 Usage:
  50lines

4.3 - wextd.exe
-----------------------
 Because wext has so many functions that are identical to dos32
 (it is easier to count the functions that are not implemented) i decided to
 create a loader that replaces dos32.
 Note: this loader only works with the dos32 v3.5 linker and not v3.3, but
       it behaves more like 3.3

 to link in wextd.exe instead of dos32 when linking just link in the
 following way.

 dlink -Swextd.exe myobject1 myobject2,execfile,mapfile,mylibs1 mylibs2

4.4 - wextw.exe
-----------------------
 This is also a loader but this one is for executables created with wlink,
 the execformat is the REX format defined by Pharlap but with 32bit extensions
 (i do not know if the extensions are made by watcom or pharlap but wlink
  supports them anyway :)

 read about it in watcomc.txt
 
5.0-About exepackers
-----------------------

5.1-The real REASON for using WexT
-----------------------
 As stated before this extender was made for intros, in this part i will explain
 why this way is "better".
 dos32,pmode/w and dos4gw all uses overlays for the actual program.
 this has both drawbacks and adventages.
 the adventage is the unlimited size of the executable.
 a 2 meg program cannot go into the 640k of conventional memory, but still you
 see alot of MUCH bigger executables. the reason is overlaying.
 the loader can be pretty much anything but mostly it is pmode/w,dos4gw or dos32
 these are from 8k to 200k and fits well into the convetional memory.
 what they do after that is that they allocate the memory for the rest of the
 executable and load them there, not the conventional memory but extended or
 something like that. so the biggest + is the unlimited size.
 the name overlayed is because the exec resides ABOVE the loader.
 the disadventage is that you cannot use every exepacker,normally only the
 internal and those aren't all that good.
 well why can't we use any exepacker then? well the exepacker doesn't know
 how the extender works so packing would make the overlayed part unreadable
 to the loader, it UNUSABLE. but with a non-overlayed extender all goes into
 the "real" exec so then we can use any exepacker.

5.2-Various packers
-----------------------
 now when we are working with a non-overlayed extender we can use about
 every exepacker available.
 the most "known"/"best" packers to my knowledge are these

 apack   - this packer is my choise atm because it packs best and i have not
           seen any incompability problems at all.
 wwpack  - this is was favourite, for all tests i have done this is the second
           best.
 pklite  - hey PKware.. that mean's quality?, well sure it is. but the packing
           isn't the best (wwpack is about 5-10% better)
 diet    - very "famous" packer but i have not personally tested it so much!
 propack - not that known but seems to be somewhere between wwpack and pklite
 upx     - this one supports more than normal execs, it can handle for example
           both djgpp and watcom applications.
           i was at the beginning worried that people would start using this
           one in conjunction with stubs and make wext "obsolete" because the
           possiblity to pack overlayed watcom execs... but after i did some
           tests i noticed that the packing wasn't that good at all

 unfortunalety i do not know where to get all of these, pklite SHOULD be at
 the pkware website (www.pkware.com) and apack can be found at
 apack.home.ml.org, the hornet archive (www.hornet.org) will also have it
 but for the others i would recommend a ftp search. (ftpsearch.ntno.no)

Did i mention my english sucks?
                                  / Jonas Lund aka Whizzter of woorlic
