Jump to content

  • Log In with Google      Sign In   
  • Create Account


Nypyren

Member Since 19 Aug 2002
Offline Last Active Yesterday, 10:27 PM
*****

#5170208 Just Lost Intellisense in VS2012

Posted by Nypyren on 29 July 2014 - 07:41 PM

Are you using any plugins for Visual Studio, especially ones which are Intellisense or Unity related?

Things to try:

- Delete your project/obj folder (and project/bin, if it exists). These folders are where VS puts its Intellisense databases and should be deleted in addition to the SUO file. Since you're using Unity, it's unlikely that the folders contain any other important data, but on a normal VS project, you may have other files in these folders that you DON'T want to delete. The important ones to delete are the .idb, .pdb, and .cache files.

- If using source control, sync to an older revision that you remember working.

- If you have any VS plugins installed (especially Intellisense related), try temporarily uninstalling them.

- Make sure Unity doesn't detect any compile errors, then delete the .sln and .vcproj files and regenerate them by double clicking a source code file from inside Unity.

- Unity creates two different SLN files. Try both of them to see if the problem is the same on both.

- If all else fails, you can also delete your project/Library and project/Temp folders. These usually don't cause Intellisense problems, though.


#5170151 Streaming .COM objects

Posted by Nypyren on 29 July 2014 - 01:42 PM

Short answer: If you ever save/load a memory address, you're doing it wrong (with some extremely rare exceptions that I won't go into detail about because they won't help you).

Long answer: Instead of saving a pointer, save information that lets you recreate the desired data structure or find the existing data structure if you expect it to already be somewhere in RAM. For example, you might give each type a unique ID followed by data which lets you call a particular constructor, factory method, search through an existing object list, etc. This process is called serialization/deserialization and can be easy or complicated, depending on how flexible your format needs to be - you should do some Google investigation about what serialization is to get some ideas on how you could apply it to your situation.

I'm not intimately familiar with DX11, so I'm just going off of what I googled just now. Here's what I would do:

Saving:
- Write information that lets you create or find the ID3D11Resource* that you will need for the first parameter to CreateShaderResourceView. I am not familiar with DX11 so you'll have to figure out how you want to do this on your own.
- Write the SRV's D3D11_SHADER_RESOURCE_VIEW_DESC contents to the stream. This struct appears to be a POD (plain old data - in other words, a single contiguous block of data with no pointers to anything else), so this should work. You can save this in the manner you're using above.

Loading:
- Load the information that lets you create or find the ID3D11Resource* you need.
- Load the D3D11_SHADER_RESOURCE_VIEW_DESC from the stream.
- Call ID3D11Device::CreateShaderResourceView using those two pieces of information. This will give you the interface pointer to the newly constructed resource.


Alternatively, if your code works by creating a bunch of ShaderResourceViews in memory and you aren't using the stream itself to construct them, you can simply save/load a unique ID which allows you to find the existing ShaderResourceView object which already exists in memory. Though you can't use a pointer, you may be able to use an array index, GUID, or string for this.


#5169627 [SOLVED] What is a browser?

Posted by Nypyren on 27 July 2014 - 05:37 PM

(random flailing)


The entire first page answered every possible interpretation of your question, EVEN AFTER YOU CHANGED IT. At this point, perhaps you're just trolling?


#5168792 DLL Import Failure

Posted by Nypyren on 23 July 2014 - 08:48 PM

Here's another possible issue: DLLs can rely on even MORE DLLs. Perhaps it's not the DLL that you're putting everywhere that's the problem; perhaps it's one that it depends on.

There are tools like DependencyWalker ( http://www.dependencywalker.com/ ) which can analyze the dependencies. Try investigating that to see if there's anything else unexpectedly missing.


#5167213 DLL Import Failure

Posted by Nypyren on 16 July 2014 - 02:03 PM

B)  From what SmkViper says, it sounds like I can't make a 64 bit program recognize a 32 bit DLL.  That can't be right though, because what if I need a program to be 64 bit, but use a 32 bit DLL?  Or what if I need a program to use 2 different DLLs and one is 64 bit and the other is 32 bit and I can't recompile them because I don't have the source?  There would have to be a way to do this.


64-bit processes can't load 32-bit DLLs, and vice versa. All EXEs/DLLs loaded into the process must match.

The exception is that .Net's "Any CPU" DLLs can be loaded into 64-bit or 32-bit processes because the JIT can generate the appropriate code either way.

.Net's "Any CPU" EXEs, on the other hand, will start a 64-bit process if your OS is 64-bit, or a 32-bit process if the OS is 32-bit, but any DLLs loaded thereafter have to match the bit size the EXE picked.


If you don't have proper versions of all DLLs and don't have the source code, you have to go with the bitness that you have available (32-bit, in most cases). When making a .Net EXE which loads 32-bit DLLs, you have to make sure to change the .Net projects to target x86 instead of "Any CPU".


#5166335 memory map questions

Posted by Nypyren on 11 July 2014 - 07:16 PM

Wonder if all privs here are just some mallocks 1-1


They're not 1-to-1, otherwise you'd have very inefficient use of RAM. For example if you allocated two blocks of 16 bytes apiece, they will probably go in the same Priv page. You wouldn't want to have a separate 4K priv page for each one.

Can you say yet what you mean by many heaps? each such heap is in different wirtual space or those heaps lays in one wirtual space but are defined over some distinct blocks, or what? tnx for info, if i find some more info i cand extend this picture yet in some details, very interesting things, much usefull for some kind of things (like taking care whats going on)


It's implementation dependent (it's up to the memory manager). For example, the .Net Large Object Heap probably puts its pages in a different area than the generational heap(s) to avoid fragmentation on the LOH from impacting the generational heap. The MSVCRT heap can also do the same kind of thing. You'll likely see completely different memory management schemes between different vendors.


#5166098 memory map questions

Posted by Nypyren on 10 July 2014 - 05:39 PM

system dlls seem to not have .bss sections (it seemed strange for me but maybe they are written such way - mallocs instead bss)


If the uninitialized data is small, the compiler might decide to include it in the initialized data section instead.
 

stack seem to have 16 kb only but there is adress space for potential 2 MB


The stack overflow handling behavior can expand the stack on the fly (if it's set up to do so) and resume execution gracefully if the stack was expanded safely.
 

1. those "Map" blocks still confuse me, there ara about 20 of them mostly small, most seem to be data (some read some radwrite) but some are executable (and mysterious - not described)
 
do  such memory mapped meand more like real disk file that is mapped or this is more like shared physical ram blocks ? are those really disk files? this is confucing - maybe someone is able to clear it a bit


I haven't personally used memory mapped files more than once. I believe you can use them to share data between two processes with or without "real" disk files, but I've never actually tried that.
 

2. thise privs also confuse me yet - i wonder if those are just mallocked buffers - sad there is no description (if so) which module mallocked them 
(i mean if loaded dll's if some loader external to those dlls (like stack was probably allocked by some loader or what) or my prog

I could probably make same experiment by logging my mallocks adresses and comparing them to such blocks.
 
maybe those privs together make juz a mallocked heap? if someone could add something to this picture it would be fine 
 
ps. some privs here are marked executable but as this is moderately simple winapi app there should be no jitted or injected code.. so i dont know how to explain this


"Priv" probably stands for "Private bytes" (which is what a few process memory reporting tools on Windows call a process' memory usage).

As far as I know, here's how it works:

- VirtualAlloc is what allocates the pages you see in your screenshot, and VirtualProtect sets their flags. However, a heap implementation is free to make as many different page allocations as it wants to, even if they are not all in one block of contiguous address space. Since page sizes are a fixed size (usually 4096 bytes for a typical 32-bit Windows process), there may be some unused space in them that the runtime library's memory manager hasn't specifically made part of its heap yet.

The different DLLs in your process are free to share a heap, or use multiple separate heaps as well. They avoid overlapping with each other because VirtualAlloc won't let you allocate pages which are already allocated.

As far as your unknown Priv+execute pages go, any third-party applications on your computer may install system hooks which cause DLLs to be loaded into your processes even if they aren't normally part of your program. Mice and keyboard vendors, for example, may with software that will load various DLLs into (nearly) every process in order to handle special shortcut keys or gestures. It might also be something Olly is doing (I haven't used Olly - I have my own tool to show the same kinds of information, except I know for certain that it does not inject anything).


#5166054 memory map questions

Posted by Nypyren on 10 July 2014 - 12:07 PM

I guess .reloc could probably be reclaimed - I don't think an image (exe/dll) will be moved again after it's loaded.  Though I've never seen a process reclaim .reloc pages for other purposes yet.

 

As far as I can tell from the picture, "Map" stands for memory-mapped-file.  Memory mapped files are an operating system feature that let you map a file or a portion of a file directly to memory - reads and writes to the memory will impact the file without having to fread/fwrite/etc.

 

All of the other stuff (marked as "Priv") are anything the process has allocated dynamically.  These could be heaps, stacks, JITted code (if you see any pages outside of the image regions that are marked as execute, it's JITted or injected code), or whatever else the program was written to allocate.  It depends on the program (which language, runtime library, manual memory management, etc it uses).

 

The BSS pages in your picture are expanded in the middle of the image pages by the loader.  They are fixed in that position because the executable was built to expect them at that location.

 

The pages marked as "RW Guard" are guard pages used to detect stack overflows by triggering a special exception if they are accessed.




#5165704 some assembly unknowns

Posted by Nypyren on 08 July 2014 - 06:58 PM

alright, could you answer me if the code generated in raw bin (seen as this jpeg picture) is 16 bit code or what? or is this 32 bit code to run in 16 bit mode? why nasm generated it such way? it would be strange if it would generate code that purpose is tu crash anywhere.. and if not crashing would it be able to really run sse code in 16bit mode or something ? (sorry if the questions is a bit indepth, but maybe someone will know this)
 
ps when disasembly it was bring
 
 
c:\asm>ndisasm -b32 -o40001000h -a tezt.bin
 
40001000  66678B5424        mov dx,[si+0x24]
40001005  0466              add al,0x66
40001007  678B4C24          mov ecx,[si+0x24]
4000100B  080F              or [edi],cl
4000100D  57                push edi
4000100E  C067F30F          shl byte [edi-0xd],byte 0xf
40001012  7F02              jg 0x40001016
40001014  6683C210          add dx,byte +0x10
40001018  6683E910          sub cx,byte +0x10
4000101C  7FF1              jg 0x4000100f
4000101E  C3                ret
 
extremally wrong maybe i should try -b16
 
here
 

c:\asm>ndisasm -b16 -o40001000h -a tezt.bin
 
40001000  66678B542404      mov edx,[dword esp+0x4]
40001006  66678B4C2408      mov ecx,[dword esp+0x8]
4000100C  0F57C0            xorps xmm0,xmm0
4000100F  67F30F7F02        movdqu [edx],xmm0
40001014  6683C210          add edx,byte +0x10
40001018  6683E910          sub ecx,byte +0x10
4000101C  7FF1              jg 0x100f
4000101E  C3                ret
 

seem okay but do such hex is able to run on 32 windows?
some flag i think must be setted somewhere to treat this as
some 32-16 mode (as i suspect this is 32 bit code but with some
16 bit args by default)
 
probably this explains most of the think - i need to find some flag
to denay this 16 bit default


Exactly - the behavior depends on BOTH the CPU's mode for the process (16-bit, 32-bit, or 64-bit are the ones that x86-64 processors support currently) AND the prefix of the instruction. Your encodings were built to be executed in 16-bit mode (this is why the 32-bit operands got assembled with 66 and 67 prefixes). Microsoft PE files (EXEs and DLLs) have field(s) in the headers which specifies which processor and mode the code should be executed in.

Current Windows programs should always target either 32-bit or 64-bit modes, since 16-bit executables are no longer supported on 64-bit editions of Windows.


#5165622 some assembly unknowns

Posted by Nypyren on 08 July 2014 - 01:36 PM

The 66 prefix is used in some SIMD encodings.  MOVDQA and XORPD use it though, not MOVDQU or XORPS.

 

It is also used with other general purpose instructions to override the operand size (on 32-bit and 64-bit mode, it switches to 16-bit operand size, and in 16-bit mode it switches to 32-bit operand size)

 

67, on the other hand, when used in a 64-bit process, allows you to select 32-bit address size in certain situations which may be useful.

 

 

Encoding 8B:  MOV Gv, Ev;  both Gv and Ev respect the operandSize override.  Since you're using a memory form of Ev, it also respects addressSize override.  In this case you must remove the prefixes since it will cause the encoding 66 67 8B 54 24 to become "mov dx, word [Si+0x24]" instead, causing another catastrophic problem:  your 04 will no longer be part of the instruction, and will be decoded as its own instruction.  At that point your program will likely catastrophically fail since you've "derailed" the instruction pointer.

 

They are not obsolete, but if you use them wrong, it will cause undesirable results like Spiro said.




#5162800 Unworkable project

Posted by Nypyren on 25 June 2014 - 11:07 AM

If people in general knew how web applications are often written, nobody would dare use the internet.


If people could see all of the code I've seen in the past 20 years, nobody would dare use desktop apps, mobile devices, or consoles, either ;)

(But yeah, web applications are by far the worst)


#5160449 Unworkable project

Posted by Nypyren on 14 June 2014 - 01:32 AM

Just don't let anyone at your current job know you're searching. They aren't too happy if they find out.

Also, if you quit, make sure to give a couple week's notice (or whatever's required by law, if you have a law which covers this). I quit one of my summer jobs at a grocery chain once without notice and they blacklisted me from ever working there again.


#5160445 Unworkable project

Posted by Nypyren on 14 June 2014 - 01:23 AM

- Incompetent database architecture: check.
- Shell scripts doing ANYTHING mission critical: check.
- Functions more than a page long: check.
- Codebase existing more than 10 years: check.

"I'm sorry, I'm afraid the cancer has spread throughout its entire body. There's nothing we can do for it anymore." - Doctor Nypyren


Why not look for a new job while you're still employed and bail out the moment you find one?


#5160177 Checking if a bit is set in a byte

Posted by Nypyren on 12 June 2014 - 06:10 PM

Binary literals will be more useful for multiple bits, I suspect.




#5153925 VS 2013 Express Update 2

Posted by Nypyren on 16 May 2014 - 12:32 AM

I attempted to reproduce this just now and could not. I'm using VS2013 Express for Windows Desktop with Update 2 installed.

I tried both the OtherContextMenus.SmartTag.Rename command (the one you used in your screenshot) and the Refactor.Rename command (Ctrl+R+R or right-click -> refactor -> rename) and both worked.


Is your file read-only? Does it have any lingering compile errors? Is your project using source control? Are you currently debugging the program? Are you currently editing a file which is not actually part of your project?




PARTNERS