I can and at those rates, I'm moving to NY tomorrow. :DQuote:
Originally Posted by TheCPUWizard
Printable View
I can and at those rates, I'm moving to NY tomorrow. :DQuote:
Originally Posted by TheCPUWizard
By the number of people Quoting this, I'd have to say no...Quote:
Originally Posted by javajawa
I'm also a firm beliver in making software run on a minimum spec system.
Although there are some projects, that have so many requirments, that simply will not run on a min spec system.
Long gone are the days of the 64K micro computer, that everything HAD to run in ~50k at 10khz. there was no option of faster proccessor, More ram, Acellerated Graphics, etc..
My biggest complaint about alot of today's applications, it that the min spec for each version is often more than is available on the entry level systems for sale..
It sometimes feels like the software developers and hardware manufacturers are working in kahoots... forcing the end user to upgrade the hardware in order to use the software.. (this i feel is almost true when it comes to games..)
Hahaha ..Quote:
Originally Posted by TheCPUWizard
here is something to think about, it can take a developer 3.32 microseconds to add 4 bytes to the application. It's that split second that the developer thinks about his variable declarations..
I debugged a Dll recently where the original developer used Int64 for all the integer variables, even in places where the max posible value was going to be 64 (bit manipulations)..
Now there may be a memory savings by using a byte for it, however i've read a few articles that have made it clear that using Int32 is more cost effective on a 32 bit proccessor, than using a byte..
I spent a few hours replacing the Int64's with the smaller footprint Int32's, and acctually reduced the compiled Dll by a few K, and reduced it's memory footprint considrably, and at the end reducd the execution time to about 75% of original..
During the original development, take the 3.32ms to decide if you REALY need to use Int64 or will Int32 work here...
I'm now in the habbit of only using Int64 and Byte when it's physically nessasary, like in a UDT that is used for data transfer or file formating..
Wait until 64Bit systems are the norm and we now have the added Int128 type.... :eek:
Actually 64 bit systems are the "norm" for systems that are currently shipping from manufacturers. I know of very few who are still producing 32 bit systems.Quote:
Originally Posted by GremlinSA
Regarding the software requirements vs. minimum hardware, there is some sanity to it. Lets assume it takes 1 year to get a program to market, and that the intended viable life (from a sales perspective) is 5 years.
If the program is designed to run on what constitutes a "entry level" system when the design is first started, it is likely to put burdens on the developers that will actually not apply by the time the product ships. This results in lower profits.
So the vendor starts to project (guess) what will be an entry level system in a year. Yet even these specifications may place a burden on the developers, so the intended target audience is looked at and it is determined that losing sales to people who one "entry level" new machines, or "older" machines (which may have once been "power" systems is acceptable to reduce the development cost.
Some of these initially lost sales will be recovered later in the product cycle as the metrics for an "Entry Level" system increase.
Finally, the vendor has to consider competition. If in 2-3 years (ie in the first two years they are shipping) another vendor makes a competitive product that requires the capabilities that are common at that point, will they be able to add features that will cause customers (potential and existing) to move to the competitors product.
There are all part of what has to go into any responsible commercial software development effort. When processes like this are not done at the very start (conceptualization) of the project, and periodically reviewed and updated, it typically where projects fail. My experience has been that over 75% of all failed (commercial) projects result from non-programming issuessuch as this.
I agree with this. And it also seems as if no sooner than a faster processor becomes available, there's a slower, more bloated OS to go with it, resulting in little if no actual gain for the end user.Quote:
Originally Posted by GremlinSA
This is partly why I always make sure my products will run properly on any win32 OS from win95 on up.
There are some win32 API functions not available on the earlier versions of windows, though I've yet to find it a burden to avoid using them. At some point I'm sure, but by then it will likely be much harder to find a system without them.Quote:
Originally Posted by TheCPUWizard
One major pain for the developers of the windows OS itself is backward compatibility. For instance, Vista still has to support all the win32 API functions of a number of earlier versions of windows, and not screw it up. I wonder if this is one reason for the creation of .net. If developers can be lulled into not calling directly on the API, ms could conceivably stop exporting functions, making it necessary to use the objects in .net. Then the runtime handles the execution according to the OS it is running on. If this happens, the framework becomes the new "API", and nobody write software for windows without using .net. That is unless they take on the totally impractical task of writing around it all.
The C++ developers would say VB wasn't true programming - that it made things too easy. They also didn't like the dependency on the runtime. Now many of them jump to .net, saying they like it because it's easy. And .net programs also require a runtime. :confused:
Is there a point at which this all goes too far? I mean, somebody still has to write the OS...
WizBang,
A great post. :wave: :thumb:
Some comments...
1) A "burden" can take many forms, from minimal to fatal. If you had to spend 5 minutes more coding to accomplish your goal, then that is a "burden" in that is incrementally raised your cost. Now if this happens a few thousnad time times over a five year life cycle....
2) I have repeatedly posted that target markets differ. If your products are actually selling to Win95 customers, then more power to you. However I maintain that for business applications, supporting older platforms rapidly reaches quickly diminishing returns.
3) More and more of the Windows components ARE using .NET. If you are running Win-2003, Vista, Win-2008 then it is basically impossible to use your machine without the .NET runtime executing.
4) The requirement for a "runtime" is really an interesting set of tradeoffs. If it is an additional item the person must have, and it is large, then it becomes an issue. On the otherhand, if it is shipping already installed and is being transparently maintained by the vendor, it realy results in savings all around. In this scenario, the richer the framework, the smaller the individual applications....
5) (Personal Prognostication....) While Win32 API will be around for a lonmg time, I predict two things.
5a) More and more code will be programmed against a higher level (probably .NET for Windows machines)
5b) Eventually the API will become an "inversion layer" which still supports the old interfaces, but is actually implemented in terms of the new framework.
Haha .. very true, however how many of these are shipping directly into the consumers home. I read/heard some where that 90% of the first 6 to 8 months of newly manufatured systems are shipped almost directly to developers.Quote:
Originally Posted by TheCPUWizard
Now here we get to another interesting facet of the question of WHY VB 6..... How much of 64bit is already integrated into VB6 ??
From my point of view .. 0 ... Zero .. Zip ... Nada ..
VB6 is not 64 bit, and now never will be, the runtimes were all writen when 32bit was in full swing and 64bit was something still in pre development..
And before anyone says , but the Pentium1 Proc was 64bit... NO it's not, It had a 64bit FSB and a few 64bit registers, however it only has a 32Bit primary register, and executed the 16 and 32Bit command set...
Only in the last few years has TRUE 64Bit proccessors been developed with true 64bit Registers and 64Bit instruction set..
Long after the last VB6 update was released..
VB6 is 64bit Stupid, Hell you need a hack in your application to use 64bit integers.. (and again before anyone else say "No VB6 has 64bits"), It does have variable types that use 64bits, however they are scaled types, where you cannot use the true 64bit's and some of the bits are used to store scaling info, in reality they were only accurate upto about 48bits, and there after the scalling could cause loss of the lesser digits..
Even Office Ultimate running on vista on a P4 calculates 2^64 as 18 446 744 073 709 600 000 , notice the loss of lesser digits, it's suposed to be 18 446 744 073 709 551 616....
Gremmy....
[QUOTE=GremlinSA]Haha .. very true, however how many of these are shipping directly into the consumers home. I read/heard some where that 90% of the first 6 to 8 months of newly manufatured systems are shipped almost directly to developers.
[quote]
Every Pentium Duo except the 2xxx series is 64 Bit. Also all of the AMD chips are. Asside from the super bargin basement (ie laptops under 400 dollars, desktops under 300), everything in the retail stores is 64bit, and has been for most of 2008.
And this is a "good" reason FOR using VB6.0? :confused: ;)Quote:
Now here we get to another interesting facet of the question of WHY VB 6..... How much of 64bit is already integrated into VB6 ??
From my point of view .. 0 ... Zero .. Zip ... Nada ..
VB6 is not 64 bit, and now never will be, the runtimes were all writen when 32bit was in full swing and 64bit was something still in pre development..
And before anyone says , but the Pentium1 Proc was 64bit... NO it's not, It had a 64bit FSB and a few 64bit registers, however it only has a 32Bit primary register, and executed the 16 and 32Bit command set...
Only in the last few years has TRUE 64Bit proccessors been developed with true 64bit Registers and 64Bit instruction set..
Long after the last VB6 update was released..
Okay i'll conceed this one... it's been a while since i've last browsed through the local PC warehouse, and checked what's on shelf..Quote:
Originally Posted by TheCPUWizard
how ever to my defence, New systems can take upward of six months to actually get onto the shelf here in S.A., after the initial release in the States, Software is a lot sooner..
I conbfess to oft forgetting the internalional arena... But I am very interested in what machines are currently selling there at the "low end".Quote:
Originally Posted by GremlinSA
I define "low end" as finding a baseline for the cheapest (new not refurbished) machines that you can find in a retail environment, then adding 20% to that. "Special Sale" prices typically should not be included.
If you could PM me some of the spec (Proc,Mem,HD,Ghz), I would really appreciate it.
Wait...If .net was written to use windows components, then windows turns around and uses .net which then uses windows components...LOL I'm not entirely sure I'm reading it exactly as you intended. That is unless .net has it's own components which windows is taking advantage of. However, what sort of components are we talking about here? Applets, dialogs, controls? Somewhere along the line, it still has to get down to a low enough level to make things happen. Perhaps you're saying that the framework has the sort of capability offered by the windows API, accept instead of exported functions, the developer would access them using .net objects? I don't know...sounds like the arguments made against VB - that it isolates developers from the lowest level we have - the API.Quote:
Originally Posted by TheCPUWizard
Well, then since the VB runtime is relatively small, and it's pretty much guaranteed to already be on the system, then why hasn't it been viewed (by developers) as "just another system dll"? Should a VB app be treated any differently than one which uses commdlg.dll for example?Quote:
Originally Posted by TheCPUWizard
The "richness" of the framework might also be viewed as the bloat :)
But does it really result in a smaller file size for the app? Smaller enough to make it worthwhile? I suppose we'll find out with the upcoming examples.
I also see something similar coming, though I have my doubts about where the API is going. I guess we'll have to see if the API continues to expand in future versions of windows, or if new functions/features are only available in .net. Thing is, a higher level implementation just pushes the programmer, and the code being written, farther from the true place where the work of the program really occurs. I do not see how that can be faster. Sure, you can argue again that the average PC will be fast enough to make up for it. But still, faster hardware gains the most ground when the software doesn't put extra drag on it.Quote:
Originally Posted by TheCPUWizard
Wizbang, (and others ;) )
1) Regarding theusage of .NET by the OS. public information is at best vague, and even contradictory. I am also bound by a number of different NDA's. So consider.
1a) Force a complete removal of .NET from Server-2003, Vista, or Server-2008 and your machine will crash. The only (supported) way to restore functionallity is a re-install of Windows.
1b) The Windows API is NOT the "lowest level available". You can write Kernal Mode drivers that directly talk to the hardware and expose nearly any API to what ever level.
1c) Consider the Windows Shell (Explorer.exe). Can you think of a technical (capabilities, not memory or performance) why this could not be completely written in .NET???
1d) Core components like SharPoint Services as well as higher levels (Speech Server, BizTalk, etc) are already primarily .NET based rather than native...
2) The contract that was supposed to finish last week has lingered on. But I am working on the samples. I hope to have some publiclly available (low level) benchmarks posted (with source available) late tonight. Then others can write their best implementation of equivilant functionallity (so I am not accused of writing biased benchmarks). This will be followed by a series of "common" C# samples that are in fact really BAD along with proper C# implementations [I think we can all agree that there is little difference btween VB.NET and C#, and anyone will be free to translate them]. Again people will be encouraged to replicate the samples in their favorite environment and share the results.
3) (Although I understand why), you keep coming back to "faster computers should mean faster programs". This differes from the bulk of actual uses (and where Microsoft has specifically stated their target audience is). The direction things are going is that "faster computers allow software to be more easily developed (ie Cheaper) and at the same speed as the older computers".
I heard of a few good points on why to use the .net and why not. For developers, it takes the hardness and burden from them learning how bad microsoft wrote their apis. I haven't got into linux to see how bad/easy their api list is, but it is unix like. I would only have to look at the kernel's apis because that is linux and not the xserver or the desktop envoriment which runs on the linux's kernel. I like using apis in both vb6 and c++. It gives me a solid understanding and helps me get more speed in vb6. People want to bash vb6 for not being 64-bit supported. I will tell you I don't even use any 64-bit apps or oses, unless it is linux, because there isn't enough support for 64-bit apps on windows. I don't want to run vista so that is another reason I don't use 64-bit apps.
Here is a funny story, I bought an amd athlon 3200+ with 64-bit support when they sold for 218 dollars. It was one of the top processors at the time. I bought it to to be ready for 64-bit support. I thought 64-bit would be around the corner(few years). Well I was wrong and I never really used it for 64-bit apps, but it was a great processor. I still have that computer. Now I recently bought a q6600 for quad coring. Where is the support for that? It may just be around that corner too, but I doubt it since all my apps currently doesn't care to support all 4 processors yet.
This can apply to using the .net. Businesses have the money to spend on computers. I just don't want to spend all my money like that. My power supply died because I was pulling too much power. I didn't buy one for months later. Why?? I just don't like spending money on things that shouldn't have failed. One of my 1 gb sticks of memory failed. It wasn't suppose to do that :(. The 2 gb wouldn't even work in a dual channel setup. The cas latency couldn't be dropped to the proper timings either.
What I am saying that my money gets used up by buying technology that just isn't worth what is goes for. Also it was high speed memory. Not the cheap kind.
The only thing right now in my computer that was worth the money I bought it for is my video card and my processor.
The memory was not good. The power supply wasn't good.
My q6600 and my ati radeon hd 2900 Pro video card lives on to surprise me.
I will be getting new memory this month. I am sure my computer can run the .net, but I don't think everyone has such a newer computer. I built mine and that is why I got such a fast computer. If you go buy a dell........ you just spent your money on medium technology that the .net can't run on or you spent way too much money on something you could have built yourself for much cheaper.
You might beable to rewrite explorer.exe, but you would have to scrap all the work they put in the exe since it uses alot of dlls and some classes for their controls I never heard of.
They used alot of apis to create that. I wonder if .net has all the tools to overlay all the apis they used to make it??
Try opening the exe in a hex editor and go down to where the functions names they import and read all the required apis and get back to me.
Actually I did one better. I done it myself. So now you can answer my question
Sorry for all the funny markings. I pulled that straight out of exe file :D make sure to scroll all the way to the rightHTML Code:RegSetValueW ÙRegEnumKeyExW $GetUserNameW áRegNotifyChangeKeyValue ÜRegEnumValueW îRegQueryValueExA äRegOpenKeyExA ÚRegEnumKeyW ÊRegCloseKey ÐRegCreateKeyW êRegQueryInfoKeyW åRegOpenKeyExW ïRegQueryValueExW ÏRegCreateKeyExW üRegSetValueExW ÔRegDeleteValueW ðRegQueryValueW ¦GetStockObject F CreatePatternBrush ÖOffsetViewportOrgEx ‹GetLayout ! CombineRgn 2 CreateDIBSection ¶GetTextExtentPoint32W JStretchBlt L CreateRectRgnIndirect K CreateRectRgn bGetClipRgn ÈIntersectClipRect ÁGetViewportOrgEx @SetViewportOrgEx
SelectClipRgn ÞPatBlt MGetBkColor - CreateCompatibleDC , CreateCompatibleBitmap ×OffsetWindowOrgEx Œ DeleteDC SetBkColor BitBlt Þ ExtTextOutW ¹GetTextExtentPointW aGetClipBox ˜GetObjectW =SetTextColor SetBkMode = CreateFontIndirectW DeleteObject ¾GetTextMetricsW SelectObject lGetDeviceCaps QTranslateCharsetInfo 9SetStretchBltMode ºGetSystemDirectoryW l CreateThread W CreateJobObjectW ¶ ExitProcess #SetProcessShutdownParameters ³ReleaseMutex ] CreateMutexW SetPriorityClass ;GetCurrentProcess ¯GetStartupInfoW
GetCommandLineW SetErrorMode CLeaveCriticalSection – EnterCriticalSection ¿ResetEvent ELoadLibraryExA 6 CompareFileTime ÀGetSystemTimeAsFileTime 1SetThreadPriority >GetCurrentThreadId ÐGetThreadPriority =GetCurrentThread ÙGetUserDefaultLangID BSleep û GetBinaryTypeW xGetModuleHandleExW GSystemTimeToFileTime jGetLocalTime <GetCurrentProcessId QGetEnvironmentVariableW `UnregisterWait öGlobalGetAtomNameW YGetFileAttributesW cMoveFileW ¬lstrcmpW FLoadLibraryExW Ì FindClose Ú FindNextFileW Ó FindFirstFileW ®lstrcmpiA SetEvent AssignProcessToJobObject @GetDateFormatW ÖGetTimeFormatW ç FlushInstructionCache µlstrcpynW ÃGetSystemWindowsDirectoryW SetLastError œGetProcessHeap HeapFree HeapReAlloc HeapSize HeapAlloc ØGetUserDefaultLCID ©ReadProcessMemory wOpenProcess InterlockedCompareExchange DLoadLibraryA ”QueryPerformanceCounter [UnhandledExceptionFilter 6SetUnhandledExceptionFilter qVirtualFree nVirtualAlloc ÂResumeThread JTerminateProcess KTerminateThread ¶GetSystemDefaultLCID lGetLocaleInfoW L CreateEventW hGetLastError oOpenEventW } DelayLoadFailureHook ~WaitForSingleObject ÔGetTickCount º ExpandEnvironmentStringsW uGetModuleFileNameW •GetPrivateProfileStringW ¯lstrcmpiW f CreateProcessW ð FreeLibrary éGetWindowsDirectoryW JLocalAlloc R CreateFileW ˆ DeviceIoControl NLocalFree «GetQueuedCompletionStatus U CreateIoCompletionPort SetInformationJobObject 1 CloseHandle GLoadLibraryW yGetModuleHandleW ActivateActCtx s DeactivateActCtx XGetFileAttributesExW ˜GetProcAddress DeleteCriticalSection K CreateEventA HeapDestroy InitializeCriticalSection fMulDiv InitializeCriticalSectionAndSpinCount ¸lstrlenW InterlockedDecrement InterlockedIncrement *GlobalAlloc InterlockedExchange vGetModuleHandleA ÞGetVersionExA ôGlobalFree ¢GetProcessTimes ²lstrcpyW rGetLongPathNameW ®RegisterWaitForSingleObject a_itow ¥free ßmemmove îrealloc * _except_handler3 Ømalloc _ftol _vsnwprintf ÍRtlNtStatusToDosError ë NtQueryInformationProcess CoFreeUnusedLibraries !RegisterDragDrop „ CreateBindCtx #RevokeDragDrop ; CoInitializeEx h CoUninitialize ü OleInitialize [ CoRevokeClassObject O CoRegisterClassObject E CoMarshalInterThreadInterfaceInStream CoCreateInstance OleUninitialize — DoDragDrop ² SHGetFolderPathW . ExtractIconExW Ã SHGetSpecialFolderLocation
ShellExecuteExW Å SHGetSpecialFolderPathW w SHBindToParent Ú SHParseDisplayName ~ SHChangeNotify § SHGetDesktopFolder s SHAddToRecentDocs & DuplicateIcon ï SHUpdateRecycleBinIcon ® SHGetFolderLocation ¼ SHGetPathFromIDListA ½ SHGetPathFromIDListW ð StrCpyNW StrRetToBufW StrRetToStrW * SHQueryValueExW I PathIsNetworkPathW AssocCreate Þ StrCatW ñ StrCpyW ¡ SHGetValueW * StrCmpNIW m PathRemoveBlanksW i PathRemoveArgsW 1 PathFindFileNameW StrStrIW 9 PathGetArgsW StrToIntW » SHRegGetBoolUSValueW Í SHRegWriteUSValueW ® SHRegCloseUSKey ° SHRegCreateUSKeyW ¿ SHRegGetUSValueW Ò SHSetValueW PathAppendW … PathUnquoteSpacesW e PathQuoteSpacesW Ð SHSetThreadRef SHCreateThreadRef # PathCombineW Õ SHStrDupW K PathIsPrefixW c PathParseIconLocationW AssocQueryKeyW AssocQueryStringW ï StrCmpW Ç SHRegQueryUSValueW Ã SHRegOpenUSKeyW Ë SHRegSetUSValueW C PathIsDirectoryW - PathFileExistsW = PathGetDriveNumberW ä StrChrW / PathFindExtensionW q PathRemoveFileSpecW } PathStripToRootW § SHOpenRegStream2W ó StrDupW ˜ SHDeleteValueW Ü StrCatBuffW ” SHDeleteKeyW é StrCmpIW 7wnsprintfW î StrCmpNW žTileWindows GetDoubleClickTime ]GetSystemMetrics [GetSysColorBrush AllowSetForegroundWindow ÆLoadMenuW YGetSubMenu +RemoveMenu fSetParent <GetMessagePos 8 CheckDlgButton Ä EnableWindow GetDlgItemInt RSetDlgItemInt H CopyIcon AdjustWindowRectEx ³ DrawFocusRect ² DrawEdge á ExitWindowsEx ÕWindowFromPoint lSetRect AppendMenuW ´LoadAcceleratorsW ¶LoadBitmapW BSendNotifyMessageW ‚SetWindowPlacement 9 CheckMenuItem Æ EndDialog 7SendDlgItemMessageW ÛMessageBeep ë GetActiveWindow PostQuitMessage éMoveWindow GetDlgItem -RemovePropW ý GetClassNameW
GetDCEx OSetCursorPos < ChildWindowFromPoint # ChangeDisplaySettingsW RegisterHotKey ¶UnregisterHotKey MSetCursor ?SendMessageTimeoutW sGetWindowPlacement ¾LoadImageW „SetWindowRgn ’IntersectRect òOffsetRect Ò EnumDisplayMonitors RedrawWindow •SubtractRect ¨TranslateAcceleratorW ÐWaitMessage *InflateRect CallWindowProcW GetDlgCtrlID DSetCapture ÊLockSetForegroundWindow šSystemParametersInfoW æ FindWindowW ^ CreatePopupMenu 0GetMenuDefaultItem — DestroyMenu XGetShellWindow Ë EnumChildWindows oGetWindowLongW @SendMessageW (RegisterWindowMessageW !GetKeyState J CopyRect çMonitorFromRect æMonitorFromPoint RegisterClassW kSetPropW nGetWindowLongA SetWindowLongW â FillRect GetCursorPos ãMessageBoxW ÉLoadStringW *ReleaseDC GetDC Õ EnumDisplaySettingsExW Ñ EnumDisplayDevicesW PostMessageW ¢ DispatchMessageW ªTranslateMessage >GetMessageW þPeekMessageW PtInRect
BeginPaint È EndPaint ‡SetWindowTextW ò GetAsyncKeyState “InvalidateRect jGetWindow “ShowWindowAsync ¥TrackPopupMenuEx »UpdateWindow – DestroyIcon ¨IsRectEmpty CSetActiveWindow ZGetSysColor ¿ DrawTextW ¥IsHungAppWindow zSetTimer 3GetMenuItemID ¤TrackPopupMenu É EndTask =SendMessageCallbackW û GetClassLongW ¼LoadIconW ÷OpenInputDesktop C CloseDesktop oSetScrollPos ’ShowWindow BringWindowToTop GetDesktopWindow CascadeWindows 6 CharUpperBuffW ˜SwitchToThisWindow ‘InternalGetWindowText UGetScrollInfo 2GetMenuItemCount a CreateWindowExW Ÿ DialogBoxParamW êMsgWaitForMultipleObjects * CharNextA RegisterClipboardFormatW Å EndDeferWindowPos DeferWindowPos BeginDeferWindowPos PrintWindow HSetClassLongW KGetPropW BGetNextDlgGroupItem CGetNextDlgTabItem = ChildWindowFromPointEx žIsChild ìNotifyWinEvent £TrackMouseEvent ó GetCapture ï GetAncestor 7 CharUpperW €SetWindowLongA ¯ DrawCaption åModifyMenuW InsertMenuW ¬IsWindowEnabled 7GetMenuState ºLoadCursorW EGetParent £IsDlgButtonChecked ™ DestroyWindow Þ EnumWindows ¯IsWindowVisible ÿ GetClientRect ¯UnionRect ß EqualRect {GetWindowThreadProcessId GetForegroundWindow ²KillTimer ø GetClassInfoExW DefWindowProcW RegisterClassExW GetIconInfo nSetScrollInfo (GetLastActivePopup WSetForegroundWindow «IsWindow \GetSystemMenu ¦IsIconic °IsZoomed  EnableMenuItem _SetMenuDefaultItem èMonitorFromWindow @GetMonitorInfoW mGetWindowInfo GetFocus VSetFocus ×MapWindowPoints 1ScreenToClient @ ClientToScreen tGetWindowRect ƒSetWindowPos ‘ DeleteMenu 5GetMenuItemInfoW cSetMenuItemInfoW , CharNextW GetThemeBackgroundContentRect GetThemeBool GetThemePartSize DrawThemeParentBackground - OpenThemeData DrawThemeBackground $ GetThemeTextExtent DrawThemeText CloseThemeData / SetWindowTheme
GetThemeBackgroundRegion GetThemeMargins GetThemeColor GetThemeFont GetThemeRect ( IsAppThemed 0\H % ä[ äO 0\H)8
*[ *O 8»RSDS Ö´ü|»G„i‹,Õ ùÞ explore
Also if you do compare vb6 and c# speed, you have to follow each language specifications. That means vb6 supports the use of apis and c# doesn't. Get over it. User in vb6 should have the right to use the apis in speed comparision because vb6 has the support needed to do that while c# may have the ability, that isn't how c# should be used since c# is suppose to have equivalent tools. If it doesn't, oh well.
Ever hear of un-managed code? VB.Net as well as C# both support it, and can both support API's
yeah, but not recommend because of the .net is your so called tool which replaces the apis.. sorry for the misunderstanding.
Check this out:
http://msdn.microsoft.com/en-us/magazine/cc163340.aspx
.net does not have huge requirements to run, though more power is always better it will run on a low end system.
For example right now I have it running on a 4 year old eMachine [shelf model $600 with monitor and OS] Only mod I made was to change the OS from XP home to Win2000 pro. VS loads slow but runs fine.
OK, I threw together a quick sample. I make little claims as to the optimization, but it looks pretty good to me. I used API calls for most of it, so hopefully the rewrite and thus comparison to .net should be fair. It tiles a bitmap over the form when you click on it, and gives the number of ticks in the TitleBar. So the larger the form, the longer it takes. Since it would normally not take long enough to really be meaningful, I just used a loop to multiply the number of calls to BitBlt. The number of redundant calls is determined by the value in a TextBox, so it can easily be adjusted for the machine it runs on.
Whomever wants to rewrite it in .net, go right ahead, and post the results. Obviously the same machine is going to need to run both versions to make a comparison.
Wiz, Can you upload the Image used, I dont have VB6 on this Dev system, and i'm busy with the .NET implimentation....
Thanks..
Sure. I've updated the zip file to include the image. Also, I noticed something in the code that shouldn't been there (left over from the project I used as a starting point), so I tweaked the code a bit.Quote:
Originally Posted by GremlinSA
OK, here's 'MY' Interpretation of the VB6 code..
There will be many other ways to interpret this, and some may be faster. I'm no VB.NET Graphics guru, however i have been looking up alot lately, for my articles, and this method was rated pretty high..
I've also left alot of the VB6 code in as comments, so that it can be easily compared..
BTW, the only API i left in was the GetTickCount, all the graphics work is done via the .NET framework, to give the comparason that we looking for..
I'm also going to build both and test run them, later..
Gremmy...
BTW. VB 2008 Framework 3.5..
--EDIT--
Updated File..
It would be interesting to see the same graphic representation in VB.Net using WPF.
Then someone should code the vb6 app in directx or even opengl since WPF uses directx.
Ouch.. is all i can say when you see the results..
Looks like I have a lot more to lookup...
Left is VB6 , right is .NET...
You need to recheck your facts with regard to WPF and DirectX.Quote:
Originally Posted by Joeman
No matter, you continue to miss the point. The point isn't about what underlying technology a framework uses (that is, if any underlying technologies are used at all) - it's about how the developer has to code against in the framework to get the work done.
Say I haven't heard too many comments from you on the other thread after it was shown that C# could be as fast (or faster) than C++ in the samples you provided.
100% agreement here. Using Extyernal GDI in VB6 or PInvoke in .Net really misses the whole point.Quote:
Originally Posted by Arjay
If you are going to have the work done by things that are not directly native to the language, then the tests become meaningless.
Consider. I can take the "Vb6" (quotes intentional) and make it a DLL rather than an EXE. This would not induce any difference in the benerated code. I could then load this DLL in a .Net application and PInvoke the identical code. Given that the tick measurement is inside the DLL, the results would be 100% identical.
I think that the different avenues being explored here have value. But they are NOT a measurement of the capabilities of what is provided by a specific evrinment.
How about the fastest possible VB6.0 application that contains NO "declare" statements what so ever....
Hmm, that whould be an interesting test..Quote:
Originally Posted by CPU
Try getting answers from a professional for c++ vs c#. To tell you the truth, I have only used c++ for little over a year. Maybe 1 1/2 at most. The little post we did was not a real test. You can't expect 20 lines of code to really compare for overall performance.. do you? Have you read this? http://en.wikipedia.org/wiki/Windows...ion_Foundation It clearly states directx in wpf.
As we found out about both test, c# either used more resources to wait for the object to be deleted which made it run faster or you didn't and got somewhat of a good memory range compared to c++ which was still peaking more resources than c++.
well I would use directx which comes with vb6 and not any declares.Quote:
Originally Posted by TheCpuWizard
This thread is getting bashed by now. I can't wait until microsoft pulls support for the .net 1.0, 1.1, 2.0, 3.0 ;) how many versions again? 4.. 5?? I think that cripples many things unless you stay current all the darn time.
I have to wonder what your motivation is regard to all this. By self admission you don't have any .Net experience, so how can you evaluate .Net? It seems to me that you just dislike MS.Quote:
Originally Posted by Joeman
lol you know nothing. when i said that c was faster than c++, I was referring to be used with opengl. My bad. Opengl interfaces with c better so it will run faster since you don't have much support for classes now do you? My experience is fine. If I was anti-microsoft, I wouldn't be in the c++ and winapi forum the most. Also I wouldn't be in vb6 thread stating it is just fine. I knew you would state about my experience with c++ and the time I have used it. You don't even know how the .net works, but I do. Sure I don't use it, but I know how it works. You didn't even know the wpf used directx. It took me 2-3 mins to find that out.. You sure you know the .net?
Considering that have been running a consulting firm in NewQuote:
Originally Posted by Joeman
York City for over 24 years. Have been developing in "C" since 1981. In Basic since 1974. In Visual Basic since 1.0. In C++ since 1985. Visual C++ since V1.52. In C# since 2000.
I have also been a Senior Field (Application Development) Consultant for Microsoft, and have worked closely with the product teams for both the C++ and .NET productlines.
I am wondering what your qualifications for "professional" are....
ps: Visual C++ is currently in CTP for Version 10.0......
One that is biased and not from someone that supports the .net or whatever microsoft approves of. Now you run as a consultant and you will give people what is in demand for their business and not what is in demand for people that aren't in the business side. Now when I say business, this usually applies mostly to servers... which is want you consult the most?
You wasn't there when c++ was in production because it was in production for unix. if it was when when microsoft made it compatible, that is a different story
Actually I was working in Unix as far back as the late 1970's and still do a fair amount. Also your assumptions about my work being largely server based is incorrect.Quote:
Originally Posted by Joeman
My current major client is developing a set of tools for students to use on their laptops while at university.
My previous major client was for a Service Tech application that ran on HandHelds.
On the other hand I have also worked on some of the largest financial databases (Oracle) in the world.
I also do alot of industrial automation (every Seagate hard drive built in the last 7 years has a "head" that was produced on an ION Beam Etch/Depo system I was the chief architect and lead developer on).
I am NOT a "shill" for Microsoft in any way. And have no problem speaking out when I disagree with their approach (just look at some of my posts on any of the 5 major Forums (CodeGuru + 4) I participate in).
Well, since part of the VB6 language supports calling the win API, it sure seems valid to me. It's not as if we're inserting machine code or something. I am interested in seeing the sample done using .net with and without API usage. I suspect the difference with API will be very little, perhaps even indiscernible. And sure, both languages done without any API too. I think I'll post a sample of that later.Quote:
Originally Posted by TheCPUWizard
Using the API is what I'd expect from accomplished programmers. That has of course been part of the discussion - well written code. In defending the speed of .net, various posts state (rightfully so) that bad coding techniques, or simply importing VB6 code into .net is not going to yield decent performance.
I'm sure most if not all of us know how slow Pset is compared to SetPixel, and would obviously use the faster method. If we see code using Pset, written by someone whom is supposed to be a professional...
I suppose I did assume since you never talked about the draw backs on the .net, you just picked up any technology that had microsoft's name on it. I see why the .net is used for servers, but I don't see any app built from the .net that is used for personal computers. This maybe just a time gap, but I don't see most of my major applications built in it. I have a hard time believing that it is ready for my needs. Also your badge from microsoft for major contributions for their product(s) told me you basically will do anything for them. :) Microsoft Very Important Person. This badge is giving to people who have shown much contributions to their product(s). That only got me more thinking that you would say everything for micosoft even if microsoft was wrong.
Yep and a professional in the .net learns the opposite way.. That is not to use apisQuote:
Originally Posted by WizBang
Have you ever seen this page?
http://mvp.support.microsoft.com/gp/mvpexecsumQuote:
Overview
Microsoft is pleased to recognize and award its Most Valuable Professionals (MVPs). We present the MVP Award to thank individuals for their exceptional contributions to technical communities worldwide. When a community participant sees an MVP in a technical community, whether in a newsgroup, as a user group host, a conference speaker, or a respondent in forums, that community participant can be confident that the information shared by the MVP will be of the highest caliber and will help every user make the most of the technology.
Microsoft also benefits from engaging with MVPs through conferences, user groups, code camps, the MVP Global Summit, and other events. MVPs share their independent, real-world feedback with us, thereby helping Microsoft better understand users' needs, improve current products, and develop future technology.
Customers and technology users who work with Microsoft technologies are encouraged to visit user groups, conferences, and training sessions that are led by MVPs. MVPs are objective technology experts who are eager to share their knowledge. They have no obligation to Microsoft and freely share their expert opinions and experience, earning users' respect and trust.
Doesn't say anything about supporting ANYTHING, just about helping people.
You just explained my point very well... :D :D :DQuote:
Originally Posted by WizBang
An experienced VB6.0 programmer will know that what is instrinically build into the VB6.0 language is going to be slow, and will use some external functionallity (either API calls as above, or a third party control/library). This means that a person who "just knows VB6.0" even if they know it perfectly, and can write the best possible code, is going to be in trouble.
The same logic applies to C++. To use it for most "real world" applications there will be calls which are part of a library that is not included in the ISO standard (STL is included).
When you get to .NET, the need to go with something outside of what is provided with the framework is greatly reduced, and in many cases totally eliminated. When there is a compelling reason for performance, native code can be tightly integrated. Although a single assembly is written in a single language, these assemblies can be combined (NetModules) so that a given .EXE or DLL can include VB.NET, C#, C++/CLI, native C++ (heck, even Fortran, Cobol, Algol, APL, PL/1.... if you add third party .NET compilers).
In conclusion, there is a big difference between.
1) Implementations using language/platform xxx + available externally accessable items.
2) Implementations that are written 100% using the inherent abilities of a single language/platform without any external linkage.
It is in scenario #2 where .NET clearly shines. Scenraio #1 is much more vague because you are not really measuring a single entity.
Would you consider a C# program that consisted of just "Main" and a single PInvoke to non-DotNet code a ".Net Program"?
Of course not. Well how about some thing that is 10%/90% or 20%/80% or 30%/70%. It is a judgement call when you can truely saw that "Program xxx is written yyy" for scenario #1...
Additionally if you work for Microsoft or have any direct professional (ie paid) relationship with them you are ineligible for MVP status.Quote:
Originally Posted by dglienna
My two biggest areas that qualify me for MVP are participating in on-line forums, and running a summer "code-camp" (unfortunately it had to be canceled this year...it really is my favorite activity) for kids through high-school students [3 two week sessions for different age groups].
Just to make one point clear. Apis aren't just for speed. vb6 supports them because it is how you typically communicate with the os in that language .. if you needed to. Even if it was to gather certain information.. like the dlls injected in your app. Apis are not just for speed. Anyone can tell you that. Although, they do provide better performance and I am pretty certain that holds true with the .net.. You have overhead calls. A function that does a function which returns that fuction.... and so forth ;)
How can you contribute to something you don't support? that is just dumbQuote:
Originally Posted by dglienna
Quote:
Originally Posted by Joeman
As opposed to who? You? :) I've been programming since I was 14, right along when MS was just a new kid on the block. A lot has happened since then, and 2006, when I first received my MVP. I didn't ask for it, and got it for helping people with something that I enjoy.
I've worked on IBM Mainframes, Honeywell MiniSystems, an IBM System/1 (a loong time back), Apples, and PC clones of every type. I had to learn something about each system along the way. Not too many ran MS software.
Is that an insult? so what you can code. whoopy due and my point is still valid. you make some dumb assumptions. Did i ever say i was anti-microsoft. You're lucky i don't want to get banned again!
Quote:
Originally Posted by Joeman
Proabably...
you bet. i just don't know when to stop. i love pushing things until they break
It seems to me like saying that one can not use API calls in VB but can use net framework references in dot net makes for an unfair test, highly slanted toward dot net.
Make if fair, no added references in either platform or any available reference in either platform.
The bottom line is use a newer framework if you find some benefit to it.
If you think the old way is better, stick to it.
That being said, how about a couple of questions...
Do you have problems currently finding VB6 work?
How long more do you all think VB6 will be in demand?
I don't have any problem getting work in VB though most of my current projects use a mixture of VB and dot net and will likely be going more toward dot net as time marches on.
I think VB6 is a fine langauge for many projects and will continue to be as long as it can run on the current OS and hardware being used.
Lately I have been writing quite a few apps for mobile devices in Dot Net. It works fine but there has been need for quite a few lines of code to do the work here. After writing many apps I decided to dive into the designer source files in one of my projects and see if I could speed it up a bit.
I ended up writing a program in VB6 that actually writes a good bit of the dot net code for me based on the controls that have been added to the designer. In general I would say this little VB utility saves me any where from 1-4 hours per project by inserting code for common tasks based on control names.
WillAtWell,
VB6.0 was probably the "best" language when it came out. But you say you are still developing commercial applications in it. Given that it is out of support, what would your customers (how hopefully have paid you LOTS of money) do if all of your products just stopped working the next time they did a "Windows Update", and there was no way to make them work again...
I doubt they would be happy.
Granted this is very slim possibility, but "officially" it can happen. And some recent updates HAVE broken aspects of VB6.0 with the official answer being "sorry, that is no longer supported...change your application".
To me providing commercial applications on a platform that is no longer supported is bad business.
As to the comparisions, it seems I am having trouble getting my point across. If I was a programmer who had never seen windows or any language that can be used to program windows and I read JUST the VB 6.0 documentation, there are certain things I can do. To go beyond this I have to learn "more" than just VB6.0.
On the other hand, if I read all of the .NET documentation, then I can do many more things using just .NET provided information.
This is the difference between:
VB6.0 (only) vs. .NET (only)
and
VB6.0 (plust other things you can use) vs. .NET (also plus other things).
If you choose the latter (which IS the real-world case for development), then you are NOT comparing VB6.0 to .NET...you are doing something different.
THe very initial draft of my performance comparisions are discussed @
http://www.codeguru.com/forum/showth...93#post1739193
I guess the point I was trying to make is that the Dot Net framework is not the dot net language. It is an API that works with the dot net languages. Just because it has the same dot net in the name does not mean it is part of any of the languages.
As for the language being supported by MS. I have never had any support issue rasied with MS on any program I have written supported or not. If a customer installs software on thier machine that causes something I wrote to stop working then they will be calling me for support and we will work through it.
It is very possible that I will begin to get support calls on Vista machines soon but it really does not matter if MS supports VB or not. The customer is going to look to me for the solution and I will provide it.
Believe it or not I may even write an occasional VBDos program or heaven forbid an old dos style batch file.