PassingBy
Content Type
Profiles
Forums
Events
Posts posted by PassingBy
-
-
Hmmm .....
Without the Intel Triton chipset, EDO does not appear to be doing anything, so I'm buttoned up again with the same old 20MB. Still don't understand why DOS 7.0 works but W95 doesn't. The problem seems to be mixing FP and EDO rather than anything magic about 32MB, but it isn't worth buying more old RAM to prove it. SP1 appears to have removed the 3 X 8MB option, but maybe it was just a fluke that it seemed to work during the initial messing about.As I mentioned earlier, FP and EDO does not play well together ... If I recall correctly (my memory is a wee bit hazy here ... it's been quite a long while ...), it's due to different bus cycle/signal timings between the EDO and FP ... While they share the same pin counts but mixing FP with EDO makes the FP goes 'huh?' as the EDO are able to retrieve more bits within the same cycle and the FP says 'what !? where !? when !?' ...
Again, this is not something BIOS memory timings can help much ... It's like trying to make an unbuffered DDR module work with a registered DDR module (well, something like that) ... They just don't play nicely ... My last socket 3 was a generic SiS496 pci that also does not work with mixed FP+EDO ...
Memory region errors usually does not appear under DOS as DOS kernel is loaded and stays within the first 1 MB ... All the rest will become XMS/EMS ... If the defective region(s) is above 1MB then DOS never crash, the later loaded apps will kindly do that when they use the defective regions ...
Win9x is different as the kernel loads high up in memory and if this is where the defective region is located then it usually throws up BSODs very very early .....
On another note, Intel triton was intended for the socket 7 pentiums (p75-p233mmx) ..... The UMC8881 were socket 3 for the much more earlier i486 family ... The AMD X5-133 is not anywhere near the same as the AMD K5/K6, it's really just a turbo-boosted 486 .....
Rgds
0 -
Hmmm .....
Me sorry for missing on this .... my bad ...
well then, this issue does crops up when the dos environment space is almost used up ... kindly refer to this for a solution :
http://support.microsoft.com/kb/q230205/
Rgds
0 -
Hmmm .....
Ahhh ... nostalgic issues ... pcchips M919 (socket 3) ... please have a look here to see if this will help you :
http://th2chips.freeservers.com/m919/
-and-
http://th2chips.freeservers.com/m919/unoff/m919.html
I assume the M919 is a 72pin SIMMs versions ... please check that you're not mixing FP ram and EDO ram ... they don't play well together ...
Last but not least is the possibility that one of the SIMM may be having a defective region ... try the free memory tester from simmtester.com ...
If I recall correctly, unbranded (or unknown manufacturer) SIMMs back then were prone to stability and mixing issues ...
Rgds
0 -
Hmmm .....
Yes, it was working well with the previous Ati 9800pro (now expired) and a spare Gf4200ti I keep for emergencies. On the same system with XP the 6800GS works well (I change only the boxed HD).I've checked my notes and asked someone to double check for me ..... and we had a 6600gt and a 6800xt that requires agp voltage increased to 1.6v to make it work stable ...
...you will need to add PCI\VEN_10DE&DEV_00F6&SUBSYS_040110B0&REV_A2 to your INF if required...and that's enough?? It seems to easy; I already tried forcing detection but you know the result...
Yes, put this in the [Mfg] section :
%NVIDIA&DEV_00F6.DeviceDesc% = NV30, PCI\VEN_10DE&DEV_00F6&SUBSYS_040110B0&REV_A2
-or-
%NVIDIA&DEV_00F6.DeviceDesc% = NV30, PCI\VEN_10DE&DEV_00F6
and this into the [strings] section :
NVIDIA&DEV_00F6.DeviceDesc="NVIDIA GeForce 6800 GS AGP"
I've looked at 8198 and 8216 driver set and the above needs to be added ... It is already included in 8269 set ...
While you're at it, try reducing ram to 512mb to see it's not win98 memory management issue ...
Rgds
0 -
Hmmm .....
Nobody can help me with my unlucky 6800GS ?I hope MDGx can update once more his drivers with this AGP card support.
Or someone can give me indications on how to tweak them by myself.
This topic isn't dead, is it?
Bye
There's another part of equation that you need to look at. Is the motherboard agp chipset driver working ?
Is the gf68gs an upgrade for an older agp card ? Or built on a new system ? Does the gf68gs have enough power ? etc etc etc .....
..... as I change to higher res or colors and reboot I get a blue corrupted screen that soon becomes a BSOD.I believe this indicates that the motherboard agp driver support is not working (happens on clean installs) ..... The steps required (driver must be last installed) to have a functional agp subsystem :
1. Install agp driver support for win98 (ie. Intel, VIA, SiS, NF2, Ali etc etc)
2. Install DX (6.1 and above, if my mind is not hazy. Some cards requires specific DX)
3. Install driver (you will need to add PCI\VEN_10DE&DEV_00F6&SUBSYS_040110B0&REV_A2 to your INF if required)
If all the above is correctly installed but you still have non-functional gf6800gs then you may need to inspect other h/w
(card itself, motherboard caps, PSU, etc etc) .....
Rgds
Edit: Edit last paragraph
0 -
Hmmm .....
Thanks awergh ! much appreciated ..... Will give it a go soon ...
I'm wondering about daedalus, is it a non released stuff by alexanrs ? My apologies if I'm off topic but does daedalus implement only 32bit icon support or will it be able to integrate some other stuff in NT4VU (perhaps icon text bk) ?
Rgds
0 -
Hmmm .....
UberWOW !
Tihiy's done it again ....
Rgds
0 -
Hmmm .....
Is it possible to get Gnumeric running with UberKern???http://www.gnome.org/projects/gnumeric/
My understanding was the it was GTK+ that prevented it from working with Win98.
I see libcairo-2.dll is included.
Tested about a week ago with v1.7.x and v1.9.x ... yes, they both will work but the toolbar icon gives solid red background on my tests ...
Last to work out-of-the-box with no problems is v1.6.3 ...
Rgds
0 -
Hmmm .....
@awergh
Can you kindly post nt4vu packs on multiple hosts please ? divshare wants premiums for downloads in certain geos ... That's not gonna help ...
Rgds
0 -
Hmmm .....
I've looked for a copy of the driver and found one ... A quick look at the INF suggests that this driver will allow the phone to be used as a modem ... If that's what you intend to do with the phone then I believe it may be possible (but not gonna be easy) to whip up something for win98 ...
If you hope to transfer "data files" with this driver then its no go ... The driver uses usb CDC not MSD ... The only way to transfer "data files" thru CDC requires 2 level :
1. USB to UART bridge (that's where you see unimodem, vcomm, modemui etc etc)
2. Application to read/write using additional commands (defined by manufacturer)
This reminds me of an old IXLA digital camera I used a long time ago that uses similar methods ...
Rgds
0 -
Hmmm .....
I'm back with time to spare now ... unfortunately WLL is still on hold as my VMware testbed system needs rebuilding, again ...
The last I tinkered with WLL, I planned for a new "animation routine" ... time will tell if it'll be implemented ...
I'll be looking into some usb related stuff for a while and will resume here once that's done ...
Rgds
0 -
Hmmm .....
@jmsallo
Could you please make a zip/rar of the HP P1006 w9x folder driver for me ? ... I'd like to have a look at it and see if I can add some "stuff" to make it work ...
I have looked through some HP models (1010, 1022, 2014, 2015) recent drivers and I believe I've found the the reason for the "inability" for HP to provide full w9x driver support. It seems that HP rights (read: license) to redistribute the usb printing support expired last June 2007 ... (Of course I believe that they could have just written their own usb support like what they did for their D640 series but that's not what I'm here for) ...
I'm in the process of modifying some HP P2015 drivers to see the level of usb printing support required ... basically I wanted to know if basic printing can be done with basic drivers (stripped down) ...
Rgds
0 -
Hmmm .....
Thanks for the heads up ... went for a search and found 'em ... It's not officially posted yet on videolan site, so get your copy of 0.8.6f here and let's see if they rocks ...
http://download.videolan.org/pub/videolan/vlc/0.8.6f/win32/
Rgds
0 -
Hmmm .....
Sorry guys, I'm in a wee bit of a tight schedule right now ... WLL/WBL have to take a back seat for another week ...
What's being done so far :
1. I've made tests on VMWare ... and while I don't experience any hanging yet, the animation does not seem to work properly ..... I'm also experiencing system restarts whenever I mount vmdisk to copy over some files (not related to WLL/WBL) ... I may need to rebuild the XP again ...
2. On my Nvidia test system, somehow the dirty bit got 'stuck' ... I'm (will be) trying to retrace what I did or why it got stuck ... but the thing is, scandisk seems to display correctly without any blue-screen/distortion each and everytime it starts ... WBL is currently in use for the test without scandisk.alt and autoscan=2 (auto) ... will see if WLL produce the same ...
3. Using scandisk.alt method as with RP7 still gives 50-50 result ... I going to take a step back (and take a breather) to see if there's anything that I missed ...
I implemented a 4byte watermark in the bitmap, to distinguish an ordinary (or old version of) LOGO.SYS from an embedded coords oneFine with me, as long as you're happy ...
Rgds
0 -
Hmmm .....
Do these unofficial drivers work with Windows 95? Has anyone tried?Not yet and no plans either ... If my mind is not too hazy, I believe the last that works on w95 out-of-the-box would be 61.76 but that was many moons ago the last I tested ... If I'm not mistaken above 66.94 has cpl api issues ...
The last 9x NVidia release supports AGP cards in Win95, apparently:http://www.nvidia.com/object/win9x_81.98.html
Is there any reason to think that Win95 support is broken by 82.69?
Apparently ..... but highly probable only the driver sub-system will still work if at all ...
The highest that I got to work properly on w95 was 77.72 ... driver sub-system (VxDs) will work fine but certain modules like control panel uses win98 api and those need patching ... However, I do believe 82.69 will also work if we remove cpl modules ...
Rgds
0 -
Hmmm .....
... Glad you enjoyed 'reading' it ... To be honest, its for the fun and pleasure of doing some asm after such a long time ... Its the rush in the brain thing ... I've almost forgotten how asm can drive people either nuts or to bliss ... Now, tell me please about what have you achievedDoes it work better with some cards? What about VMWare?
It does seems to work better (that's subjective I must say) on my test systems (gf2/fx, ati rage, i810, s3) ... the brick doesn't jump out of the shaft anymore on my test PCs especially on i810gfx ... I believe the timer will be (logically) unhook correctly ... I did the re-entrant code much earlier but you posted updated WLL before me though (really, ask Drugwash) ...
As for VMw, I'm prep'ing an amd with enough juice to run vmw ... It will be ready very soon for me to make test runs with vmw ...
Well, are you sure it is bad? Ideally, some Windows structures or undocumented interrupts should be checked.While doing TSRs and int wrapper way back then we knew we shouldn't do int in another int (unless we positively 100% know what to expect)... just that I believe there must be a better way to know when to stop that timer ... a pre-windows handshake/talkbalk flag or something hopefully simple yet bulletproof ...
As for scandisk issue, i think that video state/palette save/restore will work, if it does not hang system. I must build a real system with nVidia card to test that.I agree ... saving and restore state/palette will have to be done earlier in WLL/WBL ... i'll see if it can be done with int 10h or needs port access ... but if WBL gets fat then it'll be just code options ... maybe can be done in scandisk.alt ... (oh boy, more stuff to read up ...)
BTW, there's a bug in the source code within bankswitch function ... I've accidentally erased 2 pop lines ... You can d/l the fixed source & binaries or add the 2 lines yourself ...
Rgds
0 -
Hmmm .....
As announced earlier, the source code is now released for all to see ... It shows the current state of WBL ... the hardest part was to say something in the readme.txt .....
I am still looking for a better and better and better way to safely trigger the timer int unhook ... if anyone have any idea what I'm talking about, pls advise something useful (to the codes) ...
I am now looking over the scandisk issue ... Enabling the dirty bit is not difficult but to simulate it (without actually writing it) for win.com to detect it is too much hassle (possible but takes away time)... I made a quick-n-dirty patch to turn on dirty bit for my test runs ...
I'm following WLL method by using scandisk.alt for now and it seems there's some housekeeping to do before scandisk.alt will work correctly ... out of ten test runs, five works and another five hangs ... I must figure that out first ...
There's another approach that I'll be working on and that is to detect dirty bit before logo displays ... I know this will work better than scandisk.alt .... need to read up a bit more on that too ...
Any comments/feedback, pls leave it here ...
Rgds
0 -
Hmm .....
.....Edit: oh, simulate dirty bit? That's awesome if you can, since i was unable to
Work on the scandisk issue just started ... have successfully triggered scandisk using 'dirty bit' ... it wasn't that difficult after all ...
Let's see if my approach works ...
He-he... wrong guess. The colors come up fine, but the fading I came up with has only 5-6 steps and the effect is too choppy and fast. I'm using a refresh sync .....Then you'll need a 1 or 2 tick timer in between fades ...
Rgds
0 -
Hmmm .....
The original SVGACOM code I've been performing test with contains:;call CheckSVGA
;je completelyfail; if textmode;THIS CHECK IS DISABLED FOR VMWARE!:(That's probably why I missed it ... I didn't use svgacom style for test runs ... I embed my debug routines into WBL for certain debugging purposes ... switch them off for final binaries ... makes life more enjoyable ....
I've stumbled into a fading code myself, while playing with some color shifting routine. The effect however looks incomplete and I miss a timer.Let me guess, the image doesn't show the proper color palette once you're done with the fade-in ? ..... That's because the palette register expects those values as RGB but BMP stores them in reverse as BGR ...
There's so many timer routines that we can use ... My favourite two were and still are [a] hook timer int 8/1c (with increased resolution) BIOS timer calls depending on requirement ... for simple ones, BIOS timer calls is usually sufficient ... You can find the code floating around and here's the code in its simplest form (remember, its not refined code, a more refined version will have more checks in it) ...
Delay proc near
; bx contains no of ticks. Each tick is 1/18th of a second.
push ax
push dx
mov ah,0 ; Get system timer tick
int 1Ah ; Call ROM BIOS time-of-day services
add dx,bx ; add our delay value to dx
mov bx,dx
pause:
int 1Ah
cmp dx,bx ; Delay duration passed ?
jl pause ; nope, wait sum more
pop dx
pop ax
ret
Delay endpI've been thinking about watermarking the new logo versions with our own 'magic number' so the code would recognize them at once and instantly reject any other file, be it 640x480 8bpp bitmap or whatever. Would it be OK to use the 'Reserved' space or should we grab another 2-3 palette bytes, for safety?That's for you to decide ... If you meant the header reserved fields then your watermark is limited to 4 or maybe 6 bytes ... There's 246 bytes still unused in the palette table after embedding the coordinates ... 'watermark / magic number' just adds 'complexity' to something that should be simple to use ...
Quote from Albert Einsten:
"Everything should be made as simple as possible, but not simpler."
I now believe that while the embedded coordinates makes 'brick/progressbar' positioning easier, it also 'locks out' other valid bmps ..... I will make minor adjustments to WBL to display a valid BMP even if the coordinates are invalid ...
I did add zero-palette code to a test version but the image still briefly flashes when pixels are loaded, before going to a complete blank, on my nVidia GeForce4 Ti4200 card.If you were making changes to WLL then you'll have to replace the original palette setup routine with the zero-palette routine ... Once the bmp have been loaded, start the fade-in cycle ...
Can't focus too much on the code these days, as I have some health issues to attend to, but still trying to keep up with the news.
Take care and get well .....
Rgds
0 -
Hmmm .....
Right, I'm back .....
..... When i've tried it in VMWare, if was kinda catastrophic .....I should say that in VMWare video register manipulation often produces unexpected results .....
Uh-oh, will do VMWare test runs later ... perhaps in the next 2-3 days (my underpowered PC no longer have the turbo button) ... Yeah, that kinda sucks ... I have a feeling its not the vga registers, probably something else ... i'll look into it soon ... well, worse case scenario is I put some checks for VMw environment and skip whatever that bugs VMw ...
Also, i've noticed that you're fade-in before actually starting win.com?Yes, that is correct. Fade-in happens before win.com. I had fade-in done using three different methods :
1. integrated into Timer (lazy messy work, off to recycle bin)
2. chained to Timer (I like this one, its so smooth but it's fat)
3. moved to Loadbmp (I prefer this one coz I can dump it)
All three have pros and cons. I chose no. 3 to minimize final memory usage. Two tables are used to skip palette register read/compare. If I use only one reference table, I'll have to read/compare palette registers and I'll lose some speed. Method ex-1 & 2 will animate, fade AND run win.com seemingly all at once ... but this makes it fat ...
Fade-in code squeezed to less than 200 bytes. Plus two table and after win.com, WBL ate 3.5KB (that's 4KB locked out) which is not acceptable to me ... I want slim WBL not fat cellulite eye candy ... 2048 bytes is the most WBL will eat and no more ...
I don't want to be too creative and save table in offscreen vga ram ... I'll keep it simple and still have the impression of fade-in, so method 3 works best for me ... method 2 is also available for anyone to make test runs ...
Yeah, the zero palette code was missing ... on i810 I didn't notice it but on the ati it was glaring at me ... That's already fixed ... Method 3 fade-in delay is about 1 tick (55 ms, 1/18th sec) apart (on my slow machine it looks like 2 ticks)and it allows for a delay anywhere between 1 to 65535 ticks apart using BIOS timer unless it overflows (that's only theoretically, but I'm lazy to actually measure it ...)
For fade-in to work nicely across the board, I now wait for retrace. Without it, logo flickers badly ...
And uh... you're already 3KB, are you shrinking memory on loading procedures? ... WBL can be a truckload feature full ~64KB in filesize but must use no more than 2048 bytes "resident" before win.com ... Currently WBL (fade-in method 3) is about 1.8KB "resident" ... Codes are split into retained/expendable sections ... And I would like to see source, and help you ...Sure, let me put more lame comments and a nice readme first ..... It'll be ready for release this weekend ... yeah, definitely coming soon to a computer near you ...
The way you're moving the bullet is wrong .....There's no right or wrong here ..... (I did mentioned to you before that it was supposed to be my "major re-arranged version") ... I've given it some thought before I replaced it. I want something easy to use and lame easy to code ... The brick is working to my minimum specs and everyone's invited to do whatever to it (once released) ... its a limitation but definitely not a bug ....
The debug versions would not run if the bmp is not present in C:\ - I see this as a flaw, because as a debug version it should run from whatever path and recognize the bmp in the same folder .....Ok, as you wish ... it's now added to the source and I no longer will post debug binaries since the source will be available soon ...
In your case : "Use the source, Luke" ...
There may be problems in VMWare because of the VESA check. I noticed in the original code from Tihiy, that the respective check was disabled, exactly because of VMWare .....I must have missed that original code or the original code have missed me ... was it checks for mode change or something else ? I've just implemented a different way (better way? maybe) to check for mode change and drop that int 10h vesa mode check ... I believe that when win.com loads it disables VESA extension and VESA function AL=03 becomes text mode function AL=03 ... That's probably why text mode appears before windows loads .....
To everyone, I have made many small changes to WBL codes ... The new WBL archive will have both fade-in methods for test runs ... also contains new unhook trigger, fixed off-shaft-brick draws and missed-erase-brick draws (I do hope so and I need feedback on this), flicker free fade-in and some other minor fixes ... The target/objective for this current exercise is deemed to be fulfilled if no related bugs is reported ...
New target/objective that will be looked into :
- VMw erratic/hang issue; -and-
- scandisk screen display issue
Oh boy, this will take a while .....
Rgds
0 -
Hmmm .....
If you are be able to fix scandisk bugs (blue screen without anything) on nVidia cards, that'll be super nice!I may have an idea or two ..... I have a plate full to chew right now; will be back in a couple of days to whack scandisk issue ... (I'll read up a bit and simulate dirty bit ... then I'll see how to add it into a nice cocktail)
- does not work with my logos (wrong size), and with svgacom logos- system reboots when text is displayed from behind
- text from backround overlays the original screen
1. Logo validation routine:
a. splash.sys must exist
b. Filesize 308,278 bytes (301K)
c. Must have BMP signature
d. Must be bmp ver 3 (40bytes header)
e. Must be 256 color.
f. Must be 640px width
g. brick size width & height must be non-zero
I will stick to embedded data in palette table as no random color dots will appear at the top left of screen as with recent svgacom versions. It's the current best solution for variable brick position & size. However, there is a limit to the brick/progressbar size. It is fixed to 512 bytes ... This is not a bug but a feature ...
(Note to meself: check for bricksize out of range)
Enlarging the brick size will eat up dos low memory ... wbl has a very humble target of not eating more than 2KB before win.com ... moving to higher memory is not in the pipeline ...
2. Text in background means message outputs are sent after wbl changed gfx mode ... probably some error msgs from memory manager or something that caused the reboot ... (There's a dos console-output-redirect-to-file TSR utility somewhere that may help you get those msgs ... it'll eat up memory though ...)
3. This is an 'inheritance' from wll.com ... Gfx/text mode changing/swapping is the issue ... I'll see if I can make them play nice and still stay within 2KB limit ... A working solution to this is also linked to scandisk issue above and may take a while to get properly cooked (nope, it's not fastfood) ...
Anyone who made test runs, kindly leave a note whether its working or otheriwse ... Inputs (pros & cons) are appreciated ...
Rgds
0 -
Hmmm .....
I've added a nice touch to WBL today ... A simple fade-in routine for the bootsplash logo ... WBL will now fade-in the logo and animate brick/progressbar simultaneously ... Get it from below, make test runs and let me know how it goes ...
http://www.msfn.org/board/Fixes-and-enhanc...745#entry746745
Rgds
0 -
Hmmm .....
I've been wanting to give wll.com a good whack since some time last year ... Finally, Drugwash took up the challenge of doing something to wll.com ...
I have been helping Drugwash with his attempt and I promised him that I'll look at some of the more annoying issues with wll.com last weekend ... Drugwash is currently doing some stuff with io.sys patcher and I will temporarily oversee bugs squashing until I quit or someone better takes over .... (yeah, I sucks) ...
A week has passed mixing this 'cokctail' and the result is a clone based on wll.com and renamed to wbl.com .....
I hope those who were having issues (or not) with wll.com could spend a few minutes making some test runs with wbl.com ... No installation is necessary to test it out ... If you find bugs with it, please report. If it works good, you can just copy it over wll.com ...
Wbl.com have been tested on Nvidia, Ati & i810 gfx ... I have made major changes and re-arrangements. Source code will be released within a week if no annoying issues are brought up ... Anyone who wishes for the source code now, please pm me (as I may make/add more changes to it) ...
There are now 6 files in the archive:
1. readme.txt - some notes & description of progressbar creation
2. splash.sys - bmp logo file with embeddedd coordinates data
3. wbl.asm - the source code
4. wbl1.com - brick animation without fade-in
5. wbl2.com - brick animation with fade-in (mehotd 2 - more memory usage)
6. wbl3.com - brick animation with fade-in (method 3 - less memory usage)
Important: these must should be run in pure dos ... running in dos box may crash it as it will make direct memory access here and there ... update: wbl1.com and wbl2.com can be run within windows ... wbl.com will not ...
To make test runs, copy splash.sys to root folder C:\ and run wbl1.com ... See if any visual smear/glitches occurs ... I'm interested to know if there's any issues here ... (my test runs shows no issues)
wbl2.com is usefull when you want to see each brick/bullet/progressbar movement on screen ...
If you have RP7 logo applet installed and willing to make test runs, copy splash.sys to root folder C:\ and copy wbl.com as wll.com (Don't forget to make backup copy of wll.com) ... Reboot, see result and please report any issues ... (This is the real test)
Alternatively, boot to dos ... copy splash.sys and wbl.com to root directory and run wbl at prompt ...
Changes to the bmp logo file:
Basically still a bmp file with coordinates embedded in the 4th byte palette table. It is unused for 256 color bmps and deemed safe for use ... Offset are listed below, two bytes required for each ...
Offset for embedded val (from BOF)
topHor : offset 57 & 61
topVer : offset 65 & 69
width : offset 73 & 77
height : offset 81 & 85
shaftw : offset 89 & 93
Changes to wll.com and reborn as wbl.com
1. Timer chain/re-entrant/safe unhook
2. Internal stack allocation
3. Code re-arrangements & comments
4. Replaced brick animation routine
5. VESA checks
6. BMP file/header checks
7. Banks calc'ed using vesa wingranularity
8. Various cleanups
Target of this exercise:
1. Resolve intermittent brick glitches (drawn way off shaft)
2. Resolve ati screen bubu ..
Thank you & rgds
p/s: Before I forget again, thank you Tihiy for the source codes .....
WBL archive with source codes
Edit/Added:
Added WBL (fade-in) archive
Removed older versions
WBL source code & binaries
0 -
Hmmm .....
ntkern, msmouse, configmgm were listed as a part of driver in device manager. when i removed it it was replaced with vmm32.dll - instantly.VMM32.VXD = all compiled Vxds required by windows during setup or after certain windows updates (ex: win95 osr2 usb update). All unnecessary data in VxDs are removed when it is compiled into vmm32.vxd ... Most of the time updated Vxds are placed in the VMM32 folder without being re-compiled into VMM32.VXD .....
but the question is if it is older or newer version...Generally, the latest versions will be in VMM32 folder. Removing them will force windows to load the "older" ones in vmm32.vxd .....
it is written there that first are loaded vxds from directory, and later the vmm32.vxd. if the driver from directory is loaded first, vmm32.vxd section for this file is ignored...This is correct ...
To manually compile vmm32.vxd, go here :
http://www.helpwithwindows.com/techfiles/vmm32.html
I have made my own batch file ... It's in one of my archived storage, if you want it then let me know and I'll look for it ... There's also sample batch archive at http://rosecitydownloads.com/vmm32.zip that can-be/was used with the guide ... mine automated the whole process ...
Rgds
0
... Glad you enjoyed 'reading' it ... To be honest, its for the fun and pleasure of doing some asm after such a long time ... Its the rush in the brain thing ... I've almost forgotten how asm can drive people either nuts or to bliss ... 
Maximus-Decim Native USB Drivers
in Windows 9x Member Projects
Posted
Hmmm .....
Hey there erpdude8
,
I'm in a bit of a tight schedule right now ... and away from my dev systems ...
If you could hold out just for another couple of days or so, I'll post an updated pack to match the latest NUSB by Maximum-Decim ... It's already been tested for months now on several W98FE systems but I haven't gotten round to include an un-install routine yet ... That's on the to-do-list ...
I apologise for being lame and not having the updated pack posted much earlier ...
@barbarien:
The explorer is the pretty much the same used in nusb33e (maybe some resource is different here and there but definitely no code patches were done). So, no major differences there. It's there to handle usb insertion messages correctly ...
Rgds